1. OWASP - Where we are… where we are going
Tom Brennan
Dave Wichers
Dinis Cruz
OWASP Board Members
Today I’m going to tell you about an exciting open source project that we are leading at OWASP.

2. Why was the OWASP Project started?
The Open Web Application Security Project was setup in 2001 to build an industry standard framework for testing the security of web applications. We have several main objectives including to:
define the security requirements for secure web applications
develop an industry standard web application security testing framework
build quality open source tools to support the testing framework
define a standard data exchange format to allow commercial, open source and research tools to communicate and interoperate
We will be developing the website into a place where;
people can learn about the common security problems that occur with web applications and web services
developers and system architects can learn about security requirements to build secure web applications and web services
security professionals and developers can learn how to effectively test the security of web applications and web services
system owners can learn what to expect of a security company or tool testing their applications
security professionals can understand if tools are appropriate and doing what they should be doing
<WAYBACK MACHINE OWASP.ORG>

3. The Open Web Application Security Project (OWASP Foundation Inc.)
Participation in OWASP is free and open to all
The vision is a software market that produces code that’s secure enough to rely on.  The mission (to achieve that vision) is to make security visible (or transparent) so that software buyers and sellers are on equal footing and market forces can work. 
International not-for-profit charitable organization funded primarily by volunteers time, OWASP Memberships ($50 Individuals, $5k Supporters), and OWASP Conference fees
Website: 6,464 registered users, 21,552,771 page views, and 55,941 page edits , 10k members on mailing lists 3 3

4. Principles Free & Open Governed by rough consensus & running code
Governance
Principles
Free & Open
Governed by rough consensus & running code
Abide by a code of ethics (see ethics)
Not-for-profit
Not driven by commercial interests
Risk based approach 4 4

5. Code of Ethics
Perform all professional activities and duties in accordance with all applicable laws and the highest ethical principles;
Promote the implementation of and promote compliance with standards, procedures, controls for application security; Maintain appropriate confidentiality of proprietary or otherwise sensitive information encountered in the course of professional activities;
Discharge professional responsibilities with diligence and honesty; Refrain from any activities which might constitute a conflict of interest or otherwise damage the reputation of employers, the information security profession, or the Association; and
Not intentionally injure or impugn the professional reputation of practice of colleagues, clients, or employers.
Governance 5

6. OWASP FOUNDATION INC. Governance (6) Volunteer Board
(Jeff, Dinis, Tom, Dave, Sebastian, <insert>)
(27) Volunteer Global Committee Members
(see next slide)
OWASP Employees (3)
(140) Local Chapters
(50) Projects

7. Voice for 7 Regions, 140 chapters and its members and users
Global Committee
Governance
(27) Global Leaders
Voice for 7 Regions, 140 chapters and its members and users

8. 2009 Organization Supporters (5000k usd)
                                                                                                                                                                                                

9. 2009 Educational Supporters (Free)

10. OWASP Projects

11. The Ten Most Critical Web Application Security Vulnerabilities
OWASP Top 10
The Ten Most Critical Web Application Security Vulnerabilities
2007 Release
A great start, but not a standard
4th version of the Top coming soon (Target Nov 2009)
The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities – a great start to your secure coding security program.
Security is not a one-time event. It is insufficient to secure your code just once. By 2008, this Top 10 will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in Where to go from here for more information.
A secure coding initiative must deal with all stages of a program’s lifecycle. Secure web applications are only possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the OWASP Guide, which is essential reading for anyone developing web applications today.
This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress.

12. OWASP Top Ten (2007 Edition)
A1: Cross Site Scripting (XSS)
A2: Injection Flaws
A3: Malicious File Execution
A4: Insecure Direct Object Reference
A5: Cross Site Request Forgery (CSRF)
A6: Information Leakage and Improper Error Handling
A7: Broken Authentication and Session Management
A8: Insecure Cryptographic Storage
A9: Insecure Communications
A10: Failure to Restrict URL Access
Main Point
The OWASP Top Ten identifies the 10 most critical flaws in Web Applications today.
Teaching Points
We cover all these topics, plus many more, in this course (so we don’t go over these topics now).
Most developers are not aware of the vulnerabilities because they have not been trained in security issues. We have found that if they are made aware of the problems they will gladly fix them. In fact, we have had developers run out of a class saying they had to go fix something.
Lockheed Martin’s 10 Application Security Design principles are based in part on the OWASP Top Ten.
Examples, Demonstrations, Stories, Notes
The document was organized like the SANS Top 10 for Windows and Unix.
You and your development team might be surprised at the many ways attackers have found to trick applications into doing unintended things.
Many times vulnerabilities in combination will result in a more complex attack

13. The ‘Big 4’ Documentation Projects + 1 new
ASVS
Developer 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)

14. Developer Guide The First OWASP ‘Guide’ Complements OWASP Top 10
310p Book
Many contributors
Apps and web services
Most platforms
Examples are J2EE, ASP.NET, and PHP
Comprehensive
Project Leader and Editor
Andrew van der Stock,

15. Code Review Guide
Most comprehensive open source secure code review guide on the web
Under development for 3 years
Version 1.1 produced during 2008 Summer of Code
Numerous contributors
But still not complete (may never be )
Need Cover and Description

16. Testing Guide 1. Frontispiece 2. Introduction
3. The OWASP Testing Framework
4. Web Application Penetration Testing
5. Writing Reports: value the real risk
Appendix A: Testing Tools
Appendix B: Suggested Reading
Appendix C: Fuzz Vectors
Appendix D: Encoded Injection
Get new Cover

17. Application Security Desk Reference (ASDR)
Basic reference material on application security terminology
Serves as the foundation definition or description of many topics covered by the OWASP Development, Code Review, and Testing Guides, and the ASVS
ASDR Contents
Section 1: Principles
Section 2: Threat Agents
Section 3: Attacks
Section 4: Vulnerabilities
Section 5: Controls
Section 6: Technical Impacts
Section 7: Business Impact

18. New ‘Cheat Sheet’ Series
XSS Prevention Cheat Sheet
SQL Injection Prevention Cheat Sheet
More … ???
CSRF Prevention (being developed now)
Clickjacking Prevention

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

20. OWASP Application Security Verification Standard (ASVS)
OWASP’s 1st Standard
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

21. 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?

22. Software Assurance Maturity Model (SAMM)
The 4 Disciplines are high-level categories for activities
Three security Functions under each Discipline are the specific silos for improvement within an organization
Alignment & Governance
Requirements & Design
Verification & Assessment
Deployment & Operations
Disciplines
Functions

23. Comprehensive, Lightweight Application Security Process
OWASP CLASP
Comprehensive, Lightweight Application Security Process
Prescriptive and Proactive
Centered around 7 AppSec Best Practices
Cover the entire software lifecycle (not just development)
Adaptable to any development process
CLASP defines roles across the SDLC
24 role-based process components
Start small and dial-in to your needs

24. OWASP Tools and Technology
Vulnerability Scanners
Static Analysis Tools
Fuzzing
Automated Security Verification
Penetration Testing Tools
Code Review Tools
Manual Security Verification
ESAPI
Security Architecture
AppSec Libraries
ESAPI Reference Implementation
Guards and Filters
Secure Coding
Reporting Tools
AppSec Management
Flawed Apps
Learning Environments
Live CD
SiteGenerator
AppSec Education
In terms of OWASP Tools and Technology, our coverage is a bit spotty, but we’re actively working to remedy that.
We have a lot of tools for automated verification, but we lag behind the commercial tools a bit here. We have 3 SoC projects to build better static and dynamic tools, so look for some advances here.
Our manual verification tools are quite good, with WebScarab listed as one of the most popular security tools anywhere.
In the security architecture area, we do not have a lot of tools or technology, although the Enterprise Security API is an important part of this key area.
We have a number of tools to encourage security coding, including several appsec libraries and many guards and filters.
Our appsec management tools are fairly weak, although the OWASP Report Generator shows some promise
And in the AppSec Education area, the WebGoat tool has been very successful, although this region is yellow because we can and should do more in the education areas.

25. OWASP WebGoat – 5.2
WebGoat is a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.

26. OWASP WebScarab – WebScarab-NG – New Proxy Engine
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

27. OWASP Enterprise Security API (ESAPI)
Custom Enterprise Web Application
Enterprise Security API
Authenticator
User
AccessController
AccessReferenceMap
Validator
Encoder
HTTPUtilities
Encryptor
EncryptedProperties
Randomizer
Exception Handling
Logger
IntrusionDetector
SecurityConfiguration
The ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. You can just use the interfaces and build your own implementation using your company's infrastructure. Or, you can use the reference implementation as a starting point. In concept, the API is language independent. However, the first deliverables from the project are a Java API and a Java reference implementation. Efforts to build ESAPI in .NET and PHP are already underway.
Unfortunately, the available platforms, frameworks, and toolkits (Java EE, Struts, Spring, etc...) simply do not provide enough protection. This leaves developers with responsibility for designing and building security mechanisms. This reinventing the wheel for every application leads to wasted time and massive security holes.
The cost savings through reduced development time, and the increased security due to using heavily analyzed and carefully designed security methods provide developers with a massive advantage over organizations that are trying to deal with security using existing ad hoc secure coding techniques. This API is designed to automatically take care of many aspects of application security, making these issues invisible to the developers.
Existing Enterprise Security Services/Libraries

28. OWASP CSRFGuard 2.0
User
(Browser)
OWASP CSRFGuard
Verify Token
Business Processing
Adds token to:
href attribute
src attribute
hidden field in all forms
Actions:
Log
Invalidate
Redirect
Add Token to HTML
The OWASP CSRFGuard Project attempts to address this issue through the use of unique request tokens.

29. OWASP CSRFTester
Just when developers are starting to run in circles over Cross Site Scripting, the 'sleeping giant' awakes for yet another web-catastrophe. Cross-Site Request Forgery (CSRF) is an attack whereby the victim is tricked into loading information from or submitting information to a web application for which they are currently authenticated. The problem is that the web application has no means of verifying the integrity of the request. The OWASP CSRFTester Project attempts to give developers the ability to test their applications for CSRF flaws.

30. OWASP AntiSamy – Safe Rich Input Validation
Uses a positive security model for rich input validation
High assurance mechanism against XSS (and phishing) attacks
Java and .NET
Now built into ESAPI
Slashdot
- links, markup
E-Bay
- links, markup, images, etc
MySpace
- links, markup, images, stylesheets, etc
xss attack surface
You can’t use simple validation and filtering approaches on rich data to ensure that there are no scripts contained within. Regular expressions are not powerful enough to parse these languages.
You need a real parser, and a whitelist validation engine, and a data driven set of rules.
That’s what the OWASP AntiSamy project has built.
Goals for AntiSamy:
provide high assurance
provide 99% (or close enough) protection against XSS
browser wars, new W3C directives, etc. cause rules to change
portable
works with terribly broken HTML
easy-to-use API or tool
use single XML policy file with default settings providing high assurance
absorbable by validator implementations in different languages
provide friendly feedback, able to just “make it work”
users may copy HTML/js from a site they like
not all JavaScript is XSS, user intention may not be malicious
help user to tune HTML/js to work with requirements
(samy)

31. Live CD
Project that collects some of the best open source security projects in a single environment
Users can boot from Live CD and immediately start using all tools without any configuration

32. Available Tools 25 “significant” tools OWASP WebScarab v20090122
OWASP WebGoat v5.2
OWASP CAL9000 v2.0
OWASP JBroFuzz v1.2
OWASP DirBuster v0.12
OWASP SQLiX v1.0
OWASP WSFuzzer v1.9.4
OWASP Wapiti v2.0.0-beta
Paros Proxy v3.2.13
nmap & Zenmap v 4.76
Wireshark v1.0.5
tcpdump v4.0.0
Firefox addons
Burp Suite v1.2
Grendel Scan v1.0
Metasploit v3.2 (svn)
w3af + GUI svn r2161
Netcats – original + GNU
Nikto v2.03
Firece Domain Scanner v1.0.3
Maltego CE v2-210
Httprint v301
SQLBrute v1.0
Spike Proxy v
Rat Proxy v1.53-beta
sqlmap v0.7-rc1 now included!

33. OWASP Code review tools
Code Crawler
Alessio Marziali
Orizon Framework
Paulo Prego
LAPSE (Inactive)
Ben Livshits (Stanford Project)

34. Want More ? About 50 projects! OWASP .NET Project OWASP ASDR Project
OWASP AntiSamy Project
OWASP AppSec FAQ Project
OWASP Application Security Assessment Standards Project
OWASP Application Security Metrics Project
OWASP Application Security Requirements Project
OWASP CAL9000 Project
OWASP CLASP Project
OWASP CSRFGuard Project
OWASP CSRFTester Project
OWASP Career Development Project
OWASP Certification Criteria Project
OWASP Certification Project
OWASP Code Review Project
OWASP Communications Project
OWASP DirBuster Project
OWASP Education Project
OWASP Encoding Project
OWASP Enterprise Security API (ESAPI)
OWASP Flash Security Project
OWASP Guide Project
OWASP Insecure Web App Project
OWASP Interceptor Project
OWASP JBroFuzz
OWASP Java Project
OWASP LAPSE Project
OWASP Legal Project
OWASP Live CD Project
OWASP Logging Project
OWASP Orizon Project
OWASP PHP Project
OWASP Pantera Web Assessment Studio Project
OWASP SASAP Project
OWASP SQLiX Project
OWASP SWAAT Project
OWASP Testing Project
OWASP Tools Project
OWASP Top Ten Project
OWASP Validation Project
OWASP WASS Project
OWASP WSFuzzer Project
OWASP Web Services Security Project
OWASP WebGoat Project
OWASP WebScarab Project
OWASP XML Security Gateway Evaluation Criteria Project
OWASP on the Move Project
About 50 projects!

35. Summer of Code: 2008 OWASP Code review guide, V1.1
The Ruby on Rails Security Guide v2
OWASP UI Component Verification Project (a.k.a. OWASP JSP Testing Tool)
Internationalization Guidelines and OWASP-Spanish Project
OWASP Application Security Desk Reference (ASDR)
OWASP .NET Project Leader
OWASP Education Project
OWASP Testing Guide v3
OWASP Application Security Verification Standard
Online code signing and integrity verification service for open source community (OpenSign Server)
Securing WebGoat using ModSecurity
OWASP Book Cover & Sleeve Design
OWASP Individual & Corporate Member Packs, Conference Attendee Packs Brief
OWASP Access Control Rules Tester
OpenPGP Extensions for HTTP - Enigform and mod_openpgp
OWASP-WeBekci Project
OWASP Backend Security Project
OWASP Application Security Tool Benchmarking Environment and Site Generator refresh
Teachable Static Analysis Workbench
OWASP Positive Security Project
GTK+ GUI for w3af project
OWASP Interceptor Project Update
Skavenger
SQL Injector Benchmarking Project (SQLiBENCH)
OWASP AppSensor - Detect and Respond to Attacks from Within the Application
OWASP Orizon Project
OWASP Corporate Application Security Rating Guide
OWASP AntiSamy .NET
Python Static Analysis
OWASP Classic ASP Security Project
OWASP Live CD 2008 Project

36. OWASP Projects Are Alive!
2009 …
2007
2005
The Testing is alive…
When they say, “print is dead” they don’t mean it’s out of style – it’s static not living! Do you have a bookshelf of security books? When’s the last time you opened them? They don’t have answers to today’s problems because they’re dead.
It’s a process for translating security principles to the latest technologies and getting them to developers fast
It’s an evolving growing living thing
2003
2001 36 36

37. Get Involved