1. Getting Started with OWASP The Top 10, ASVS, and the Guides Dave Wichers COO, Aspect Security OWASP Board Member OWASP Top 10 and ASVS Projects Lead OWASP Conferences Chair

2. The OWASP Documentation Projects
Top 10
ASVS
Prevention Cheat Sheet Series
Building Guide
Code Review Guide
Testing Guide
ASDR Defines all the issues and provides basic guidance. Each of the guides then provides detailed info on how to deal with that issue from the respective of that guide.
Application Security Desk Reference (ASDR)

3. Managing Application Security Risk Using OWASP Resources
Understand Risks
OWASP Top 10
Avoiding Risks
OWASP Prevention Cheat Sheet Series
OWASP Developer’s Guide
OWASP Enterprise Security API Project
Measuring Risk
OWASP Application Security Verification Standard
OWASP Code Review Guide
OWASP Testing Guide
Managing Risk
OWASP Software Assurance Maturity Model

4. OWASP Top 10 Purpose History 24 Pages
“Educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security vulnerabilities.”
History
First version in 2003
Updated in 2004, 2007, 2010
24 Pages

5. OWASP Top 10 (2010 Edition) 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
A7: Failure to Restrict URL Access
A8: Insecure Cryptographic Storage
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards
The red ones are the new ones.

6. What’s Changed from 2007? It’s About Risks, Not Just Vulnerabilities
New title is: “The Top 10 Most Critical Web Application Security Risks”
It’s About Risks, Not Just Vulnerabilities
Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
OWASP Top 10 Risk Rating Methodology
Added: A6 – Security Misconfiguration
Was A10 in 2004 Top 10: Insecure Configuration Management
Added: A10 – Unvalidated Redirects and Forwards
Relatively common and VERY dangerous flaw that is not well known
Removed: A3 – Malicious File Execution
Primarily a PHP flaw that is dropping in prevalence
Removed: A6 – Information Leakage and Improper Error Handling
A very prevalent flaw, that does not introduce much risk (normally)
2 Risks Added, 2 Dropped

7. OWASP Top 10 Risk Rating Methodology
Threat
Agent
Attack
Vector
Weakness Prevalence
Weakness Detectability
Technical Impact
Business Impact ?
Easy
Widespread
Severe
Average
Common
Moderate
Difficult
Uncommon
Minor 1 2
1.66 * 1 2 3
Injection Example
1.66 weighted risk rating

8. OWASP Prevention Cheat Sheet Series
How to avoid the most common web security problems
XSS Prevention Cheat Sheet
SQL Injection Prevention Cheat Sheet
CSRF Prevention Cheat Sheet
Transport Layer Protection Cheat Sheet
Cryptographic Storage Cheat Sheet
Authentication Cheat Sheet

9. XSS Prevention Cheat Sheet
#1: &, <, >, "  &entity; ', /  &#xHH;
HTML Element Content
(e.g., <div> some text to display </div> )
#2: All non-alphanumeric > 256  &#xHH
HTML Attribute Values
(e.g., <input name='person' type='TEXT' value='defaultValue'> )
#3: All non-alphanumeric > 256  \xHH
JavaScript Data
(e.g., <script> some javascript </script> )
#4: All non-alphanumeric > 256  \HH
HTML Style Property Values
(e.g., .pdiv a:hover {color: red; text-decoration: underline} )
Main Point
There are many escaping schemes supported in different elements of the browser.
Teaching Points
In order to defend against XSS, you need to escape all user supplied input using the proper escaping scheme before you include that input in that part of the page.
Each HTML execution context needs its own escaping scheme based on how the spec for that context defines how it handles character escaping.
ESAPI has an encoder for each of these contexts. They are:
encodeForHTML()
encodeForHTMLAttribute()
encodeForJavaScript()
encodeForCSS()
encodeForURL()
In each context you need to prevent certain dangerous characters if you can’t eliminate all user input to that context
HTML Elements – [This is simply the text on the page] – Defense against this is the big 5, because that prevents the introduction of close tags to break out of the Element (e.g., </div> or </span> or the introduction of script tags (<script) )
HTML Attributes – Content inside the quotes is inert, so preventing the introduction of single or double quotes is key. Typically encoding the big 5 ( &, ', ", <, >) is strongly recommended. Also encoding # is usually a good idea.
JavaScript Data – This context is executable in its own right, and therefore inherently dangerous. Ideally, you would not include user supplied input here ever. Otherwise, only input validation can really do anything to help you as output encoding is not sufficient.
HTML Style Properties (CSS) – This is very dangerous as it will execute content supplied – to prevent a breakout, you need to dissallow '}', but that may not be sufficient since content inside the brace can execute as well. Ideally, you would not include user supplied input here ever. Otherwise, only input validation can really do anything to help you as output encoding is not sufficient.
URI Attributes - This is very dangerous as it will (decode and) execute content supplied – to prevent a breakout, you need to dissallow ' " ', but that may not be sufficient since content inside the quotes can execute as well.
Examples, Demonstrations, Stories, Notes
See the page at OWASP for the full and latest details!!
#5: All non-alphanumeric > 256  %HH
URI Attribute Values
(e.g., <a href="javascript:toggle('lesson')" )
ALL other contexts CANNOT include Untrusted Data
Recommendation: Only allow #1 and #2 and disallow all others
See: for more details

10. OWASP Application Security Verification Standard (ASVS)
OWASP’s 1st Standard
Requires Positive Reporting!
Defines 4 Verification Levels
Level 1: Automated Verification
Level 1A: Dynamic Scan
Level 1B: Source Code Scan
Level 2: Manual Verification
Level 2A: Penetration Test
Level 2B: Code Review
Level 3: Design Verification
Level 4: Internal Verification
42 Pages

11. What Questions Does ASVS Answer?
How can I compare verification efforts?
What security features should be built into the required set of security controls?
What are reasonable increases in coverage and level of rigor when verifying the security of a web application?
How much trust can be placed in a web application?
Also a GREAT source of web application security requirements
DISA’s Application Security and Development (ASD) STIG is also a decent source of web application security requirements.

12. How OWASP is using the ASVS
ASVS provides a strong structure for organizing the web application security problem space
Using this structure to create the OWASP Common Numbering Scheme
Working on aligning all three guides to this common numbering scheme

13. OWASP Developers Guide v2.0
Describes how to develop secure web applications
Covers
Secure Coding
Threat Modeling
New Technologies (Web Services, AJAX)
16 Security Areas
293 Pages

14. Developers Guide Past and Future
v1.0 done in 2003, v2.0 released in 2005
3.0 plans
Align with OWASP Common Numbering / ASVS
Update existing sections to reflect current best practices
Add new sections to address new topics, including:
CSRF
Clickjacking
Update entire guide to cross reference relevant OWASP projects, such as ASVS, Prevention Cheat Sheets, and particularly, ESAPI.

15. OWASP Enterprise Security API (ESAPI)
Custom Enterprise Web Application
OWASP Enterprise Security API
Authenticator
User
AccessController
AccessReferenceMap
Validator
Encoder
HTTPUtilities
Encryptor
EncryptedProperties
Randomizer
Exception Handling
Logger
IntrusionDetector
SecurityConfiguration
ESAPI Goals – to provide
developers the security controls they need to produce secure web applications.
Implementations in many popular languages
Java (flagship), .NET, PHP, Python, Cold Fusion, Classic ASP
JavaScript, Ruby, Force.com (Salesforce)
Example Application (Swingset) – Available for Java
Strong worked examples they can use to
Define their own security APIs
Implement their own security controls
Your Existing Enterprise Services or Libraries
ESAPI Homepage:

16. OWASP Code Review Guide v1.1
World’s first open source security code review guide
Discusses approaches to code review, reporting, metrics, risk
Approach is "by example". (Examples of good and bad code)
Covers: Java, ASP, php, XML, C/C++
By vulnerability and (more useful) by technical control
216 Pages

17. Code Review Guide Past and Future
Version 1.1 done in 2008, 2.0 update underway
2.0 plans
Align with OWASP Common Numbering / ASVS
Approach to code review (Risk based approach) to be re-written
How to perform a code review without reviewing every line
Examples by Vulnerability and Technical control to be expanded and refined
Expand technology specific sections
Web Services section to be refined
PCI section rewritten with more x-references to other guides
New sections on
Code Analysis Tools
Rich Internet Applications
Malware and Root Kits

18. OWASP Testing Approach
OWASP Testing Guide V3.0
Massive document
Over 100 contributors
OWASP Testing Approach
Covers 10 Categories
66 Specific Controls
347 Pages

19. Testing Guide Past and Future
Version 3.0 released in 2008, 4.0 update underway
v1.0 released in 2003, v2.0 in 2006
4.0 plans
Align with OWASP Common Numbering / ASVS
Review and update all existing sections
Eliminate some sections that aren’t very useful
Insert new testing techniques
HTTP Verb tampering
HTTP Parameter Pollution
Clickjacking
New sections
Client side security
Firefox extensions testing

20. Summary: How do you address these problems?
Develop Secure Code
Follow the best practices in OWASP’s Guide to Building Secure Web Applications
Use OWASP’s Application Security Verification Standard as a guide to what an application needs to be secure
Use standard security components that are a fit for your organization
Use OWASP’s ESAPI as a basis for your standard components
Review Your Applications
Have an expert team review your applications
Review your applications yourselves following OWASP Guidelines
OWASP Code Review Guide:
OWASP Testing Guide:

21. Join, Support, and Take Advantage of the Resources Supplied by OWASP
Ireland
Sept 08-09
June 2011
Sweden
June 2010
Minnesota
Oct 08-11
New York
Nov 2008 Oct 2012
Brussels
May 2008
Germany
Oct 08-10
Poland
May 2009
China
Oct 2010
Denver
Spring 08-10
Greece
June 2012 DC
Sep 2009 Nov 2010
Portugal
Nov 2008
Israel
Sep 07-08
Taiwan
Oct 07-08
India
Aug 2008
Nov 2009
Australia
Feb 08-09
OWASP Worldwide
5,000 chapter and project members around the world
Brazil
Oct 09-10
New Zealand
July 09-10
Sampling of OWASP Conferences around the World!