1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Detecting Web Application Vulnerabilities Using Open Source Means Konstantinos Papapanagiotou Committee Member OWASP Greek Chapter conpap@owasp.gr 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008

2. OWASP What is OWASP?  The Open Web Application Security Project  Worldwide, free and open community  Mission: improve application software security  Information and awareness  Documentation  Guidelines  Forums, mailing lists, conferences, local chapters  Practical aspects  Open Source Tools  Non-profit, charitable organization  Members: VISA, Deloitte, Unisys, Foundstone, … 2

3. OWASP The Greek Chapter  Created in 2005 but active since early 2007  Mission: raise security awareness in Greece  Activities:  Translation of OWASP documentation  Mailing list  Monthly newsletter  Participation in working groups and conferences  Software tools: Web Vulnerability Scanner  ~60 members  http://www.owasp.gr http://www.owasp.gr  Soon: http://blog.owasp.gr 3

4. OWASP 4 Outline  Motivation: The need for web security  Terminology  OWASP Top10: 10 most important vulnerabilities  Detection Tools  OWASP Web Scarab  WVS (Web Vulnerability Scanner)  Conclusions

5. OWASP Web Security  Rapid growth of the Internet in the last 2-3 years  Increase of population and bandwidth  Dynamic web sites  Hacker trends have changed  Used to be: viruses, worms, defacements  Now: phishing, zombie networks, web application security  Weakest links  End-users  Developers 5

6. OWASP Web Application Vulnerabilities  Some vocabulary  Threats  Vulnerabilities  Exploits  Attacks  Patching…  Web Applications: new category of applications  Widely available  Can access local resources  New code – old code 6

7. OWASP Tackling the problem  Security is not a one-off project  Secure Development Lifecycle: 1.Getting informed, raise awareness 2.Secure design and implementation 3.Product Launch 4.Vulnerability detection 5.Patching 6.Monitoring 7.Keep the track  Not a end-user or developer only matter 7

8. OWASP Step 1: Awareness - The OWASP Top 10  Document that lists the 10 most important web vulnerabilities  Aim: educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities.  Provides:  Brief description  basic methods for protection  2007: second version 8

9. OWASP The Vulnerabilities  A1 - Cross Site Scripting (XSS)  User supplied data are sent to web browser without validating or encoding that content.  Result: can allow script execution that can lead to user sessions hijacking, web site defacement, etc.  A2 - Injection Flaws (e.g. SQL injection)  User supplied data are sent to an interpreter as part of a command or query.  Result: the interpreter is tricked into executing unintended commands or changing data. 9

10. OWASP The Vulnerabilities (2)  A3 - Malicious File Execution (e.g. remote file inclusion (RFI)  Can allow attackers to include hostile code and data  Result: up to total server compromise.  Target: PHP, XML and any framework which accepts filenames or files from users.  A4 - Insecure Direct Object Reference  Reference to an internal implementation object (file, directory, database record, key, etc) as a URL or form parameter is accidentally exposed by the developer.  Result: Attackers can manipulate those references to access other objects without authorization. 10

11. OWASP The Vulnerabilities (3)  A5 - Cross Site Request Forgery (CSRF)  Forces a logged-on victim's browser to send a pre- authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker.  A6 - Information Leakage and Improper Error Handling  Unintentional leak of information regarding configuration, internal workings, or privacy violation  Result: Attackers use this weakness to steal sensitive data, or conduct more serious attacks. 11

12. OWASP The Vulnerabilities (4)  A7 - Broken Authentication and Session Management  Account credentials and session tokens are often not properly protected.  Result: Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.  A8 - Insecure Cryptographic Storage  Web applications rarely use cryptographic functions properly to protect data and credentials.  Result: can lead to identity theft, credit card fraud, etc. 12

13. OWASP The Vulnerabilities (5)  A9 - Insecure Communications  Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.  A10 - Failure to Restrict URL Access  Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users.  Result: Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. 13

14. OWASP Step 2: Detection – OWASP WebScarab  Framework for analysing applications that communicate using HTTP and HTTPS.  Written in Java for portability  Operates as an intercepting proxy  The operator can review and modify requests created by the browser before they are sent to the server  He can also review and modify responses returned from the server before they are received by the browser.  Several modes of operation and plugins 14

15. OWASP Step 2: Detection – OWASP WebScarab (2)  Target Groups:  Developers can debug otherwise difficult problems  Security specialists can identify vulnerabilities in the way that the application has been designed or implemented.  http://www.owasp.org/index.php/Category:OWA SP_WebScarab_Project http://www.owasp.org/index.php/Category:OWA SP_WebScarab_Project  Under Development: OWASP Web Scarab Next Generation  Complete rewrite  New user interface 15

16. OWASP Step 2: Detection – WVS  Web Vulnerability Scanner  Started off as a university student project  Goal: test a web site or application (not the server in the back end)  Target group: security specialists, penetration testers, developers  Functional but still under development  Beta version at: http://www.owasp.grhttp://www.owasp.gr (http://www.owasp.org/images/6/65/WVS_beta-0.2.1.zip) 16

17. OWASP WVS – Design and Implementation  Three tier architecture:  Vulnerability database  SQLite  Data retrieval API  Update API  Communication API  Communication with server (GET, POST, etc)  Presentation Level  Plaintext output, graphical interface, html, etc  Multi-threaded  User-specified 17

18. OWASP WVS – Advantages  Less false negatives  “Paranoid scanning”  User-enabled  Retrieves the site’s structure  Makes all possible checks in the entire site  Less false positives  Static sites: MD5 hash checking  Future work: dynamic sites  Portability  Use of open and portable technologies (SQLite, libcurl, etc)  Future work: POSIX threads 18

19. OWASP WVS – Future Work  Eliminate false positives in dynamic sites  Enhance Portability  POSIX threads  Java implementation (?)  Sophisticated checks for XSS and SQL injection  Fuzzing algorithms  Other suggestions… 19

20. OWASP Conclusions  Web Application Security is a continuous process  Developers  have the skills  Are not always well informed  Organizations  Follow deadlines  Worry about security after release  End users  Low awareness  OWASP  Continuous effort to raise awareness 20

21. OWASP Q & A http://www.owasp.gr http://www.owasp.org 21