owasp appsec europe 2006 automated tools
TRANSCRIPT
Copyright © 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.
The OWASP Foundation
OWASP
AppSec
Europe
May 2006 http://www.owasp.org/
Can (Automated) Testing Tools Really Find the OWASP Top 10?
Erwin GeirnaertPartner & Co-founder, ZION [email protected]+32478289466
3OWASP AppSec Europe 2006
Introduction
In order to find vulnerabilities in web applications we need to identify them:Via code audit: a lot of workVia testing: manual or automated
Manual testing: a human being attacks a web application using his experience, knowledge and tools (open-source, self-made, IE )
Automated testing: a human being uses an automated vulnerability scanner to attack a web application
4OWASP AppSec Europe 2006
Existing studies
Arian Evans – Tools Taxonomy – OWASP 2005 Personal experience with tools Conclusion: still a lot of work
Dr. Holger Peine – Fraunhofer IESE Test of AppScan, Acunetix & WebInspect on WebGoat
and proprietary application Conclusion:
A lot of false positives A lot of false negatives Not one tool did what it should do: find the easy
vulnerabilities in WebGoat (they can’t read the lesson hints )
Reviews by Infoworld & eWeek
5OWASP AppSec Europe 2006
Testing
There is no standard to test web applicationsHow to test for vulnerabilitiesDifferent type of payloads that must be used
e.g. <script>alert(document.cookie)</script vs <body onload=alert(document.cookie)>
What should be the result of a test: how to detect a pop-up window in an HTML stream?
What should not be the result of a test: will a script tag embedded in another script tag really get executed?
6OWASP AppSec Europe 2006
Testing
OWASP Testing Guide is a framework and a guideline, not a technical step-by-step guide
OSSTMM - Open Source Security Testing Methodology Manual: more detailed but not on an web app level more on a network/OS level
No education or recognized certifications for security testing
7OWASP AppSec Europe 2006
Testing
People have different backgrounds:Network security: how experienced are they in
XML parsing, AJAX, SQL,…Functional testers: how do they know what a
security vulnerability is? How can they exploit a vulnerability?
Developers: hate to test or audit code Application security expert: has the experience
and the knowledge of the three groups above but are a rare species
Conclusion: Everyone has a different approach to testingAutomated tools also have a different approach
8OWASP AppSec Europe 2006
Automated Tools – Open-source
For free Run on multi-platforms, thank you Java No or very limited reporting Usage-mode: expert security tester Examples: Oedipus, Paros, Burp Intruder,
WebScarab Fuzzer, Spike, E-Or, …
9OWASP AppSec Europe 2006
Automated Tools - Commercial
Not cheap: license is application, server or network based
Very good reporting capabilities Run only on Windows Usage-mode: typical Next – Next clicking
usage but expert in application security and the tool is required for optimal results
Examples: Cenzic HailStorm, SPIDynamics WebInspect, Sanctum AppScan, Acunetix, NTOspider, …
10OWASP AppSec Europe 2006
OWASP Top Ten Most Critical Web Application Security Vulnerabilities
A1. Unvalidated Input A2. Broken Access Controls A3. Broken Authentication and Session
Management A4. Cross Site Scripting Flaws A5. Buffer Overflows A6. Injection Flaws A7. Improper Error Handling A8. Insecure Storage A9. Denial of Service A10. Insecure Configuration Management
11OWASP AppSec Europe 2006
Some questions
Is the Top 10 about vulnerabilities, attacks or bad coding practices?
How to differentiate the different classifications? Invalidated input (A1) is a vulnerability, XSS (A4)
is an attack against this vulnerabilitySame for A5, A6 and A7
How to define a test plan for the OWASP Top 10?
What are the payloads to discover the Top 10? Eg. 10000000 X or 10000000 A for buffer overflow?
12OWASP AppSec Europe 2006
A1. Unvalidated Input
Definition: Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.
Test: insert all possible values for parameters: GET, POST, hidden fields, cookies, HTTP Headers,...
Automated tools: do this very good, but lack classification of the errors returned
13OWASP AppSec Europe 2006
A1. Unvalidated Input
How to detect: examine result (and NOT error codes) and identify vulnerabilities SQL Injection: parse for SQL error codes :S No exception handling: parse for stacktraces? Authorization bypass: is that a Admin-button? Buffer overflow (Denial-of-Service?): empty HTML-page? LDAP Injection: different user attributes? ...
Ultimate test: exploit vulnerability MANUALLY -> THIS REQUIRES THE TESTER TO KNOW THE ATTACK PAYLOAD
What about non-English web applications?
14OWASP AppSec Europe 2006
A2. Broken Access Controls
Definition: Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.
Test: login with valid accounts with different privileges and attempt to access protected parts like URLs, Struts actions, hidden fields,...
Automated tools: can guess known URIs like /admin but do this within the existing user context or as an anonymous user
15OWASP AppSec Europe 2006
A2. Broken Access Controls
What I want: expected output should be an authorization matrix: user A can access URI A, user B cannot access URI B, ... like a sitemap but with authorization levels
16OWASP AppSec Europe 2006
A3. Broken Authentication and Session Management
Definition: Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
Test: analyse the authentication mechanism: is HTTPS used, secure cookie, random session-ID,...
Automated tools: do this out-of-the-box
17OWASP AppSec Europe 2006
A4. Cross Site Scripting Flaws
Definition: The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user’s session token, attack the local machine or spoof content to fool the user.
Test: use RSnake’s cheat sheet for XSS filter evasion (http://ha.ckers.org/xss.html)
Automated tools: some tools inject a limited XSS pattern and for some tool you don’t know what they inject and you CAN’T change it. But if you have a web site with 1000 forms they are very useful to automate the injection. But ... If you find 1 XSS, you probably find more
18OWASP AppSec Europe 2006
A5. Buffer Overflows
Definition: Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.
Test: replace every parameter with a lot of data: integers, strings, binary data,...
Automated tools: some tools inject a buffer-overflow patterns but with some tools you don’t know what they inject or you’re unable to change it. But if you have a web site with 1000 forms they are very useful to automate the injection
Results: crash of the web application, corrupt database, crash of the server so be very careful on a production environment
Automated tools: detect database corruption?
19OWASP AppSec Europe 2006
A6. Injection Flaws Definition: Web applications pass parameters when
they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
Test: replace every parameter with command injection strings which depend on the operating system in use
Automated tools: some tools inject command injection patterns but with some tools you don’t know what they inject and it is impossible to change them. But if you have a web site with 1000 forms they are very useful to automate the injection
Results: output of the command injection must be obtained, how to automate this? E.g. Net user /add Erwin
20OWASP AppSec Europe 2006
A7. Improper Error Handling
Definition: Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
Test: corrupt parameters and look for propagating exceptions
Automated tools: by default Result: how to classify an uncaught
exception, this depends on the exception
21OWASP AppSec Europe 2006
A8. Insecure Storage
Definition: Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
Test: attempt to access configuration files via forceful browsing like web.xml, examine cookies and parameters, dump passwords from database via SQL Injection
Automated tools: are unable to exploit vulnerabilities in order to find passwords
22OWASP AppSec Europe 2006
A9. Denial of Service
Definition: Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.
Test: attempt to brute-force accounts, performance test,…
Automated tools: have no problem to attack accounts and they don’t execute performance tests but when attacking a site with full force it can have some unexpected side-effects
23OWASP AppSec Europe 2006
A10. Insecure Configuration Management Definition: Having a strong server
configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.
Test: use Google to retrieve vulnerabilities about SUT and try to exploit them
Automated tools: can test automatically for these vulnerabilities and when they have a built-in update function these are very useful
24OWASP AppSec Europe 2006
Conclusions
Automated Tools are not the silver-bullet to test for the OWASP Top 10
They can help a security tester to assess a web application faster
Security tester must master the tools and know the limitations
Combine open-source tools with commercial tools But automated tools will have difficulties with the
latest technologies: AJAX: asynchronous XML requests One-time tokens like in Struts, SAP BSP, … Thick clients e.g. Java Web Start Web services