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 Detecting Web Application Vulnerabilities Using Open Source Means Konstantinos Papapanagiotou Committee Member OWASP Greek Chapter 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008

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

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   Soon: 3

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

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

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

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

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

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

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

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

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

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

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

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.  SP_WebScarab_Project SP_WebScarab_Project  Under Development: OWASP Web Scarab Next Generation  Complete rewrite  New user interface 15

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: ( 16

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

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

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

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

OWASP Q & A