Detecting Web Application Vulnerabilities Using Open Source Means OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008 Kostas Papapanagiotou Committee Member OWASP Greek Chapter conpap@owasp.gr 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 http://www.owasp.org
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, OWASP 2
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 P i in working groups and conferences Software tools: Web Vulnerability Scanner ~60 members http://www.owasp.grp p g Soon: http://blog.owasp.gr 3 OWASP
Outline Motivation: The need for web security Terminology OWASP Top10: 10 most important vulnerabilities Detection Tools OWASP Web Scarab WVS (Web Vulnerability Scanner) ConclusionsC l OWASP 4
Web Security Rapid p growth of the Internet in the last 2-3 years Increase c of population o and bandwidth dt 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 OWASP 5
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 OWASP 6
Tackling the problem Security y 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 OWASP 7
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 i methods for protection tion 2007: second version OWASP 8
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. OWASP 9
The Vulnerabilities (2) A3 - Malicious File Execution (e.g. remote file inclusion (RFI) Can allow attackers esto include cudehostile ecodea and ddatadata 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. OWASP 10
The Vulnerabilities (3) A5 - Cross Site Request Forgery (CSRF) Forces a logged-on victim's browser to send a preauthenticated 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. OWASP 11
The Vulnerabilities (4) A7 - Broken Authentication and Session Management Account t 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. OWASP 12
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. OWASP 13
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 OWASP 14
Step 2: Detection OWASP WebScarab (2) Target g 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 _ Under Development: OWASP Web Scarab Next Generation Complete rewrite New user interface OWASP 15
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 T t group: security specialists, penetration ti testers, developers Functional but still under development Beta version at: http://www.owasp.gr p// pg (http://www.owasp.org/images/6/65/wvs_beta-0.2.1.zip) OWASP 16
WVS Design and Implementation Three tier architecture: Vulnerability database SQLite Data retrieval API Update API Communication API Communication with server (GET, POST, etc) Presentation P t ti Level Plaintext output, graphical interface, html, etc Multi-threadedM th d d User-specified OWASP 17
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 OWASP 19
Conclusions Web Application Security is a continuous process Developers have the skills Are not always well informed Organizations Follow deadlines Worry W about security after release End users Low awareness OWASP Continuous effort to raise awareness OWASP 20
Q & A http://www.owasp.gr http://www.owasp.org p OWASP 21