3/24/2011

1

OWASP Top Ten

in Practice

Jason Taylor

CTO

Security Innovation

Dinis Cruz

Security Consultant

OWASP Leader

Agenda

• Intro to the OWASP Top Ten

• How to Integrate the OWASP Top Ten into your SDLC

• How the OWASP Top Ten maps to compliance, standards and other drivers

• Conclusion

3/24/2011

2

About Security Innovation

• Application & Crypto Security Experts

– 10+ years research on vulnerabilities and cryptography

– Hundreds of assessments on world‟s most dominant

software applications

• Products, Services and Training

– Application & Process Assessments

– Training. Industry‟s largest eLearning library

– Encryption. Fastest, most secure available

• Helping organizations:

– Ensure applications are secure and in compliance

– Build internal software security competency

– Roll out a secure, repeatable SDLC

Agenda

Intro to the OWASP Top Ten

• How to Integrate the OWASP Top Ten into your SDLC

• How the OWASP Top Ten maps to compliance, standards and other drivers

• Conclusion

3/24/2011

3

What is the OWASP Top 10

• Consensus of most critical web application security flaws

• Aim:– Educate all security stakeholders: developers,

designers, architects and organizations

– Reinforce that a secure software initiative must address security at each phase of the development lifecycle

– Educate, not standardize

• Used by many companies, referenced in standards and regulations such as PCI-DSS

o A.G. Edwards

o British Telecom

o Bureau of Alcohol, Tobacco, and Firearms

o Citibank

o HP

o IBM Global Services

o Price Waterhouse Coopers

o Recreational Equipment, Inc. (REI)

o Samsung SDS (Korea)

o Sprint

o Sun Microsystems

o Symantec

o The Hartford

o ...many others

OWASP Top Ten: Summary

A1 – Injection

A2 – Cross Site Scripting (XSS)

A3 – Broken Authentication and Session Management

A4 – Insecure Direct Object References

A5 – Cross Site Request Forgery (CSRF)

A6 – Security Misconfiguration (NEW)

A7 – Failure to Restrict URL Access

A8 – Unvalidated Redirects and Forwards (NEW)

A9 – Insecure Cryptographic Storage

A10 – Insufficient Transport Layer Protection

3/24/2011

4

A1 – Injection

• Injection means…

– ricking an application into including unintended

commands in the data sent to an interpreter

• Interpreters…

– Take strings and interpret them as commands

– SQL, OS Shell, LDAP, XPath, Hibernate, etc…

• SQL injection is still quite common

– Many applications still susceptible (really don‟t know why)

– Even though it‟s usually very simple to avoid

• Typical Impact

– Usually severe. Entire database can usually be read or modified

– May also allow full database schema, or account access, or even OS level access

A2 – Cross-Site Scripting (XSS)

• Occurs any time…– Raw data from attacker is sent to an innocent user‟s browser

• Raw data…– Stored in database

– Reflected from web input (form field, hidden field, URL, etc…)

– Sent directly into rich JavaScript client

• Virtually every web app has this problem– Try this in your browser:

• javascript:alert(document.cookie)

• <script>alert(document.cookie)</script>

• Typical Impact– Steal user‟s session, steal sensitive data, rewrite web page, redirect user to

phishing or malware site

– Most Severe: Install XSS proxy which allows attacker to observe and direct all user‟s behavior on vulnerable site and force user to other sites

3/24/2011

5

A3 – Broken Authentication and Session Management

• HTTP is a “stateless” protocol– Means credentials have to go with every request

– Should use SSL for everything requiring authentication

• Session management flaws

– SESSION ID used to track state since HTTP doesn‟t

• and it is just as good as credentials to an attacker

– SESSION ID is typically exposed on the network, in browser, in logs, …

• Beware the side-doors

– Change my password, remember my password, forgot my password,

secret question, logout, email address, etc…

• Typical Impact– User accounts compromised or user sessions hijacked

A4 – Insecure Direct Object References

• How do you protect access to your data?

– This is part of enforcing proper “Authorization”,

along with A7 – Failure to Restrict URL Access

• A common mistake …

– Only listing the „authorized‟ objects for the current user; or

– Hiding the object references in hidden fields… and then not enforcing these restrictions on the server side

– This is called presentation layer access control, and doesn‟t work

– Attacker simply tampers with parameter value

• Typical Impact

– Users are able to access unauthorized files or data

3/24/2011

6

A5 – Cross Site Request Forgery (CSRF)

• Cross Site Request Forgery

– An attack where the victim‟s browser is tricked into issuing a command to a

vulnerable web application

– Vulnerability is caused by browsers automatically including user

authentication data (session ID, IP address, Windows domain credentials, …)

with each request

• Imagine…

– What if a hacker could steer your mouse and get you to click on links in your

online banking application?

– What could they make you do?

• Typical Impact

– Initiate transactions (transfer funds, logout user, close account)

– Access sensitive data

– Change account details

A6 – Security Misconfiguration

• Web applications rely on a secure foundation

– All through the network and platform

– Don‟t forget the development environment

• Is your source code a secret?

– Think of all the places your source code goes

– Security should not require secret source code

• CM must extend to all parts of the application

– All credentials should change in production

• Typical Impact

– Install backdoor through missing network or server patch

– XSS flaw exploits due to missing application framework patches

– Unauthorized access to default accounts, application functionality or data, or

unused but accessible functionality due to poor server configuration

3/24/2011

7

A7 – Failure to Restrict URL Access

• How do you protect access to URLs (pages)?

– This is part of enforcing proper “authorization”, along with

A4 – Insecure Direct Object References

• A common mistake …

– Displaying only authorized links and menu choices

– This is called presentation layer access control, and doesn‟t work

– Attacker simply forges direct access to „unauthorized‟ pages

• Typical Impact

– Attackers invoke functions and services they‟re not authorized for

– Access other user‟s accounts and data

– Perform privileged actions

A8 – Unvalidated Redirects and Forwards

• Web application redirects are very common– And frequently include user supplied parameters in the destination URL

– If they aren‟t validated, attacker can send victim to a site of their choice

• Forwards (aka Transfer in .NET) are common too– They internally send the request to a new page in the same application

– Sometimes parameters define the target page

– If not validated, attacker may be able to use unvalidated forward to bypass

authentication or authorization checks

• Typical Impact– Redirect victim to phishing or malware site

– Attacker‟s request is forwarded past security checks, allowing unauthorized

function or data access

• Live Example– http://www.youtube.com/redirect?username=digitalhook&

q=http%3A%2F%2Fsecuritytube.net%2FSocial-Engineering-Attacks-using-Simple-Redirections-video.aspx&video_id=Vgc3NVVpb8c&event=url_redirect&url_redirect=True&usg=UE0DOmwjBRK-mgheFtW1hMTEvh4=

3/24/2011

8

A9 – Insecure Cryptographic Storage

• Storing sensitive data insecurely

– Failure to identify all sensitive data

– Failure to identify all the places that this sensitive data gets stored

• Databases, files, directories, log files, backups, etc.

– Failure to properly protect this data in every location

• Typical Impact

– Attackers access or modify confidential or private information

• e.g, credit cards, health care records, financial data (yours or your customers)

– Attackers extract secrets to use in additional attacks

– Company embarrassment, customer dissatisfaction, and loss of trust

– Expense of clean up: forensics, apology letters, reissuing credit cards, etc.

– Business gets sued and/or fined

A10 – Insufficient Transport Layer Protection

• Transmitting sensitive data insecurely– Failure to identify all sensitive data

– Failure to identify all the places that this sensitive data is sent

• On the web, to backend databases, to business partners, internal communications

– Failure to properly protect this data in every location

• Typical Impact– Attackers access or modify confidential or private information

• e.g, credit cards, health care records, financial data (yours or your customers)

– Attackers extract secrets to use in additional attacks

– Company embarrassment, customer dissatisfaction, and loss of trust

– Expense of cleaning up the incident

– Business gets sued and/or fined

3/24/2011

9

Agenda

• Intro to the OWASP Top Ten

How to Integrate the OWASP Top Ten into your SDLC

• How the OWASP Top Ten maps to compliance, standards and other drivers

• Conclusion

Integrating OWASP Top Ten into your SDLC

• RequirementsHow to determine your security objectives

• DesignHow to design mitigations with OWASP threats in mind

• ImplementationHow to code defensively and implement mitigations for key threats

• TestHow to devise test plans and attacks against OWASP threats

• DeployHow to deploy and configuration your application with OWASP in mind

• MaintenanceHow to scan for the OWASP threats in production

3/24/2011

10

Objective Category Questions to ask

Tangible assets to

protect

Are there user accounts, passwords, confidential information, intellectual

property, etc to protect?

Can this system be used as a conduit to access other corporate assets?

Intangible assets to

protect

Is there potential for an attack that may be embarrassing, although not

otherwise damaging?

Compliance

requirements

Are there corporate security policies or standards that must be adhered to?

Are there security or privacy legislations you must comply with?

Quality of service

requirements

Are there specific availability or performance requirements you must

meet?

Integrating OWASP Top Ten into your SDLCDetermining Security Requirements & Objectives

• Identify goals and constraints that affect the confidentiality, integrity, and availability of your data and application

• Are used to:– Filter the Design Guidelines that are applicable

– Scope and guide Architecture and Design reviews

– Help set Code Review objectives

– Guide Threat Modeling, Security Test Planning, Deployment Reviews

Integrating OWASP Top Ten into your SDLCThreat Modeling with Top Ten threats in mind

• Identify threats and vulnerabilities relevant for your application

– What are the potential threats that could impact each asset.

– For each threat, what attacks could realize the threat?

– Use the OWASP Top 10 as a guide to potential attacks.

– Determine countermeasures to mitigate vulnerabilities

• Perform in the architecture and design phase, as soon as:– You understand your security objectives and application architecture

• Update and improve iteratively:– When your security objectives and design changes

– During implementation, testing and deployment

• Some specific considerations– Legal, safety or contractual/customer requirements

3/24/2011

11

Integrating OWASP Top Ten into your SDLC Threat Modeling with OWASP threats in mind

• Secure software starts with understanding the threats– Threats are not vulnerabilities

• Threats live forever; they are the attacker's goal

Threat

Mitigation

Vulnerability

Attacker

Integrating OWASP Top Ten into your SDLC How to design mitigations with OWASP threats in mind

• Adopt a set of design guidelines that are:

– Actionable. A vulnerability that can be mitigated through the guideline

– Relevant. Associated with a vulnerability that could impact your application

– Impactful. Represents a key engineering decision that will have wide-ranging impact

• Categorize your guidelines based on areas of highest risk– Describes the areas in which poor design can lead to security vulnerabilities

– Allows the inclusion of additional guidelines or the refinement of existing guidelines based on newly discovered vulnerabilities

3/24/2011

12

Integrating OWASP Top Ten into your SDLCBest Practices for Secure Design

Category Guidelines

Input / Data

Validation

Do not trust input; consider centralized input validation. Do not rely on client-side

validation. Be careful with canonicalization issues.

Authentication Use strong passwords. Support password expiration periods and account

disablement. Do not store credentials (use one-way hashes with salt).

Authorization Use least privileged accounts. Consider authorization granularity. Enforce

separation of privileges. Restrict user access to system-level resources.

Configuration

Management

Use least privileged process and service accounts. Don‟t store credentials in clear

text. Don‟t use Local Security Authority (LSA).

Sensitive Data Avoid storing secrets. Secure the communication channel. Provide strong access

controls for sensitive data stores.

Cryptography Do not develop your own. Use proven and tested platform features. Keep

unencrypted data close to the algorithm. Cycle your keys periodically. Avoid key

management (use DPAPI).

Exception

Management

Use structured exception handling. Do not reveal sensitive application

implementation details. Consider a centralized exception management framework.

Auditing and

Logging

Identify malicious behavior. Know what good traffic looks like. Audit and log activity

through all application tiers. Secure access to log files

Integrating OWASP Top Ten into your SDLC How to code defensively and implement mitigations for key threats

• Goal: Reduce your risk by addressing OWASP Top 10 vulnerabilities in your implementation…

– by using a set of implementation best-practices organized directly around the OWASP Top 10

• Now let’s see what this looks like for a few of the Top 10

3/24/2011

13

A1 – Avoid Injection Flaws

• Recommendations

1. Use an interface that supports bind variables (e.g., prepared statements, or stored procedures),

• Bind variables allow the interpreter to distinguish between code and data

2. Encode all user input before passing it to an interpreter

– Always perform „white list‟ input validation on all user supplied input

– Always minimize database privileges to reduce the impact of a flaw

A2 – Avoiding XSS Flaws

• Recommendations

– Eliminate Flaw

• Don‟t include user supplied input in the output page

– Defend Against the Flaw• Primary Recommendation: Output encode all user supplied input

(Use OWASP‟s ESAPI to output encode:

http://www.owasp.org/index.php/ESAPI

• Perform „white list‟ input validation on all user input to be included in page

• For large chunks of user supplied HTML, use OWASP‟s AntiSamy to sanitize this HTML to make it safe

See: http://www.owasp.org/index.php/AntiSamy

3/24/2011

14

Integrating OWASP Top Ten into your SDLC Performing Security Code Reviews

• Code Review

– Critical leverage point to reduce the number of implementation errors

– Can be performed on every check-in, every build, or some other interval that works for your development process

– One of the most impactful steps you can take toward more secure code

– While design bugs are the most expensive to fix, implementation bugs are the most common

• OWASP Code Review Guide

– http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents

Integrating OWASP Top Ten into your SDLCStatic analysis tools for a code review

• Should be used throughout the product cycle– DEVELOPERS

use light weight version to check for simple bugs missed during development

– BUILD MANAGERS or LAB TECHNICIANSuse to discover more sophisticated bugs at code integration time

– TESTERSuse to ensure code coverage and discover complex sections of the product that should be tested more thoroughly

– Example: IBM Rational Appscan Source Edition

• Find a lot of the common coding errors, faster than humans– Can drastically reduce a number of bugs which may be difficult to find in

black box testing

– But same applies to hackers, who often use static analysis tools to find exploits

• Beware of False Positives and Negatives– False positives can result in wasted effort and drain on security resources

3/24/2011

15

Integrating OWASP Top Ten into your SDLC How to devise test plans and attacks to test against OWASP threats

• Leverage your Threat Model for more focused and effective testing

• Security Testing

– Functional test techniques cannot uncover security bugs

– Designed to understand what is the application NOT supposed to do

– Specific attacks should be applied to uncover vulnerabilities

• Many flaws are caused by environment interaction

– what if a resource is not available?

– will we page that to disk? If so, when?

• Many flaws are only discoverable after analyzing application’s environment

– discover sensitive information by sniffing the network

– uncover temporary files

Integrating OWASP Top Ten into your SDLCWeb scanners

• PROS. Automates testing; Finds common vulnerabilities– Rely on a database of constantly growing known vulnerabilities

– Identify common vulnerabilities faster than manual efforts

– Can discover a large amount of information about a device

• Misconfigurations, exposed usernames/passwords, vulnerable scripts

• Directory/file structure, helper files, Java applets, Flash/ActiveX controls

• Forms, query strings, hidden fields, input validation, header information

– Example: IBM Rational AppScan Enterprise Edition

• CONS. Scanners are just that – scanners

– Limited to known vulnerabilities

• Can‟t detect business logic attacks

• Difficult to find flaws caused by environment interaction

– No prioritization of vulnerabilities

– False positives are time consuming to validate

3/24/2011

16

• Sequencing of tools introduction critical . When?” is just as important as “Which?”

• Adopt when you have the ability to:

– Interpret false positives

– Fix the problems you are finding

– Compliment with manual test efforts

• Compliment with sound process– What good are tools if not required and/or used at critical security gates?

• Compliment with Training

– Tools don‟t make your organization more mature

– Tools are more productive when you know what you are looking for and can

use them to prevent problems down the road

Integrating OWASP Top Ten into your SDLCBest practices for using tools

• Ensures application security is not compromised by poor configuration of NETWORK and/or HOST

– even the most securely designed and implemented application can be

compromised by an error during deployment

• Use server security categories

• Break down your deployment review – use categories to break down your application deployment for further

analysis and to help identify vulnerabilities

• Review systematically– you can go through the deployment review process from start to finish or

pick a particular category for further analysis

Integrating OWASP Top Ten into your SDLC Deployment Reviews

- Files/Directories

- Ports

- Protocols

- Patches & Updates

- Accounts

- Auditing and logging

- Registry

- Services

- Shares

3/24/2011

17

Agenda

• Intro to the OWASP Top Ten

• How to Integrate the OWASP Top Ten into your SDLC

How the OWASP Top Ten maps to compliance, standards and other drivers

• Conclusion

The Corporate Application Compliance Frameworkaligning development with management policies

3/24/2011

18

• OWASP Top 10 in standards and frameworks

– U.S. Federal Trade Commission (FTC)

– U.S. Defense Information Systems Agency (DISA)

– PCI-DSS

• How organizations use the OWASP Top 10

– Microsoft: Top 10 threats are handled by security design and test procedures

– NSA: in their developer guidance on web application security

– Oracle: for developer awareness

– IBM AppScan: maps source code findings to OWASP Top 10

OWASP Adopters & Users

Mapping OWASP Top Ten to PCI DSS v2.0

• OWASP and PCI

• Previous version of PCI had explicit mapping to OWASP Top 10

• Current version has direct references to OWASP and mappings to OWASP Top 10 entries

3/24/2011

19

Mapping OWASP Top Ten to PCI DSS v2.0

Mapping OWASP Top Ten to PA DSS

3/24/2011

20

• Addresses the security and privacy of health data ...

• But Web application security or OWASP are not specifically called out in the HIPAA Security Rule

• That said, HIPAA requires:

– A risk analysis and risk assessment

– Depending on the risk rating, entities may need to ensure proper security controls are in place for web applications associated with electronic protected health information (ePHI)

• Which means that compliant apps must not have security vulnerabilities likes the one in OWASP Top 10 issues

HIPAA - Health Insurance Portability and

Accountability Act

• But an application can’t be compliant if vulnerable to an OWASP Top 10 risk:

– SOX (US): seeks to protect investors by improving the accuracy and reliability of corporate disclosure.

– GBLA (US): seeks to protect the personal information of consumers stored in financial institutions.

– PIPED (Canada): The Personal Information Protection and Electronic Document Act mandates that appropriate security measures be applied to personal data obtained on the course of commercial transactions.

– 95/46/EC (Europe): European Union Directive 95/46/EC is a sweeping European Parliament directive designed to protect individuals from unregulated personal data access or transfer.

– DPA (UK): The Data Protection Act mandates that the processing of sensitive personal data should be carried out with appropriate security in the interests of protecting the individual rights and privacy.

– .... and there are many more....

Other standards are also a vague on Application

Security

3/24/2011

21

• New ISO Standards (most are under development)

– ISO 27000 : Information Security techniques, fundamentals and vocabulary

– ISO 27001 : Information Security Management System Requirements (the standard to which an organization can certify)

– ISO 27002 : Code of Practice (ISO 17799:2005, guidance for interpretation and implementation of controls)

– ISO 27003 : ISMS Implementation (proposed)

– ISO 27004 : Guide for Information Security Metrics and Measures (proposed)

– ISO 27005 : Guide for Risk Management (currently BS 7799-3:2006)

– ISO 27006 : International Accreditation Guidelines

• With a key one standard still on early stages

– ISO27034 : Guidelines for application security

ISO 27000 Series

PCI DSS mapped to ISO 27001 (and OWASP)

3/24/2011

22

• Another big mapping can be found at: http://projects.webappsec.org/w/page/13246975/Threat-Classification-Taxonomy-Cross-Reference-View

OWASP Top 10(s) vs WASC vs CWE vs CAPEC vs

SANS

Open SAMM

• New SDL fromOWASP

• OWASP Top 10 is relevant in all 12 Security Practices

3/24/2011

23

• The OWASP Enterprise Security API:

– “....is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. http://www.owasp.org/index.php/ESAPI

OWASP ESAPI

ESAPI and OWASP Top 10

3/24/2011

24

• For an in depth coverage see John Melton’s blog post at:http://www.jtmelton.com/2009/01/03/the-owasp-top-ten-and-esapi/

EASPI and OWASP Top 10

Agenda

• Intro to the OWASP Top Ten

• How to Integrate the OWASP Top Ten into your SDLC

• How the OWASP Top 10 maps to compliance, standards and other drivers

Conclusion

3/24/2011

25

Conclusion

• The OWASP Top 10 was designed as a way to publicize the top threats on the web

• You can use it for:

– Education

– Organization of best practices and SDLC initiatives

– As a call to action for your development organization

• The Top 10 maps well to a variety of industry and regulatory compliance standards

– Protection against the Top 10 will help you fulfill your application security compliance requirements

How Security Innovation can Help

• TeamProfessor eLearning

– OWASP Courses:

• OWASP Top Ten: Threats & Mitigations

• How to Test for the OWASP Top Ten

– Many popular technologies

• ASP.Net, Java, C/C++,.Net, Windows, C#, JRE

• TeamMentor: Secure Development Knowledgebase

– Free OWASP Version: http://owasp.teammentor.com

• Secure SDLC Consulting– SDLC Assessment & Optimization

– Code Review

– Security Testing

3/24/2011

26

Free OWASP eLearning Coursehttp://www.teamprofessor.com

Free OWASP TeamMentorhttp://owasp.securityinnovation.com

Copy of Presentationgetsecure@securityinnovation.com

Upcoming/Past Webinars

www.securityinnovation.com/securitylab/elearning.shtml

Technical Contacts

Jason Taylorjtaylor@securityinnovation.com

Dinis Cruz

dcruz@owasp.org