OWASP Top Ten in Practice

3/24/2011

OWASP Top Ten
in Practice

Jason Taylor Dinis Cruz
CTO Security Consultant
Security Innovation 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

1

3/24/2011

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
into your SDLC
• Conclusion

2

3/24/2011

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 Recreational Equipment, Inc. (REI)
o British Telecom o Samsung SDS (Korea)
o Bureau of Alcohol, Tobacco, and Firearms o Sprint
o Citibank o Sun Microsystems
o HP o Symantec
o IBM Global Services o The Hartford
o Price Waterhouse Coopers 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

3/24/2011

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

4

3/24/2011

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


• 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

5

3/24/2011

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

6

3/24/2011

A7 – Failure to Restrict URL Access

• How do you protect access to URLs (pages)?
– This is part of enforcing proper “authorization”, along with

• 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=

7

3/24/2011

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

8

3/24/2011

Agenda

How to Integrate the OWASP Top Ten
into your SDLC
• Conclusion

Integrating OWASP Top Ten into your SDLC

• Requirements
How to determine your security objectives
• Design
How to design mitigations with OWASP threats in mind
• Implementation
How to code defensively and implement mitigations for key threats
• Test
How to devise test plans and attacks against OWASP threats
• Deploy
How to deploy and configuration your application with OWASP in mind
• Maintenance
How to scan for the OWASP threats in production

9

3/24/2011

Determining 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
Objective Category Questions to ask
Tangible assets to  Are there user accounts, passwords, confidential information, intellectual
protect property, etc to protect?
 Can this system be used as a conduit to access other corporate assets?
Intangible assets to  Is there potential for an attack that may be embarrassing, although not
protect otherwise damaging?
Compliance  Are there corporate security policies or standards that must be adhered to?
requirements  Are there security or privacy legislations you must comply with?
Quality of service  Are there specific availability or performance requirements you must
requirements meet?

Threat 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

10

3/24/2011

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

Mitigation

Attacker

Threat

Vulnerability

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

11

3/24/2011

Best Practices for Secure Design

Category Guidelines
Input / Data Do not trust input; consider centralized input validation. Do not rely on client-side
Validation 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 Use least privileged process and service accounts. Don‟t store credentials in clear
Management 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 Use structured exception handling. Do not reveal sensitive application
Management implementation details. Consider a centralized exception management framework.

Auditing and Identify malicious behavior. Know what good traffic looks like. Audit and log activity
Logging through all application tiers. Secure access to log files

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

12

3/24/2011

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

13

3/24/2011

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_Tabl
e_of_Contents

Static 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 TECHNICIANS
use to discover more sophisticated bugs at code integration time
– TESTERS
use 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

14

3/24/2011

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

Web 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

15

3/24/2011

Best practices for using tools

• 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

Deployment Reviews

• 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
- Patches & Updates - Files/Directories - Registry
- Accounts - Ports - Services
- Auditing and logging - Protocols - Shares

• 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

16

3/24/2011

Agenda

into your SDLC
How the OWASP Top Ten maps to
• Conclusion

The Corporate Application Compliance Framework
aligning development with management policies

17

3/24/2011

OWASP Adopters & Users

• 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

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

18

3/24/2011

Mapping OWASP Top Ten to PCI DSS v2.0

Mapping OWASP Top Ten to PA DSS

19

3/24/2011

HIPAA - Health Insurance Portability and
Accountability Act

• 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

Other standards are also a vague on Application
Security

• 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....

20

3/24/2011

ISO 27000 Series

• 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

PCI DSS mapped to ISO 27001 (and OWASP)

21

3/24/2011

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

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

Open SAMM

• New SDL from
OWASP
• OWASP Top 10
is relevant
in all 12 Security
Practices

22

3/24/2011

OWASP ESAPI

• 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

ESAPI and OWASP Top 10

23

3/24/2011

EASPI and OWASP Top 10

• 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/

Agenda

into your SDLC
• How the OWASP Top 10 maps to
Conclusion

24

3/24/2011

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

25

3/24/2011

Free OWASP eLearning Course
http://www.teamprofessor.com

Free OWASP TeamMentor
http://owasp.securityinnovation.com

Copy of Presentation
getsecure@securityinnovation.com

Upcoming/Past Webinars
www.securityinnovation.com/securitylab/elearning.shtml

Technical Contacts
Jason Taylor Dinis Cruz
jtaylor@securityinnovation.com dcruz@owasp.org

26

OWASP Top Ten in Practice

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to OWASP Top Ten in Practice

Similar to OWASP Top Ten in Practice (20)

Recently uploaded

Recently uploaded (20)

OWASP Top Ten in Practice