Scribd
Upload
50 views24 pages

Can (Automated) Testing Tools Really Find The OWASP Top 10?

OWASP Testing Guide is a framework and a guideline, not a technical step-by-step guide for testing web applications. OWASP Testing Guide is not a framework or a technical guideline, but a framework for identifying and exploiting security vulnerabilities. There is no standard to test web applications how to test for vulnerabilities different type of payloads that must be used e.g. Alert(document.cookie) not one tool did what it should do: find the easy vulnerabilities in WebGo

Uploaded by

Sai Kiran
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
50 views24 pages

Can (Automated) Testing Tools Really Find The OWASP Top 10?

OWASP Testing Guide is a framework and a guideline, not a technical step-by-step guide for testing web applications. OWASP Testing Guide is not a framework or a technical guideline, but a framework for identifying and exploiting security vulnerabilities. There is no standard to test web applications how to test for vulnerabilities different type of payloads that must be used e.g. Alert(document.cookie) not one tool did what it should do: find the easy vulnerabilities in WebGo

Uploaded by

Sai Kiran
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Can (Automated) Testing Tools

Really Find the OWASP Top 10?

Erwin Geirnaert
Partner & Co-founder, ZION SECURITY
[email protected]
+32478289466
OWASP
AppSec
Europe
May 2006 Copyright © 2006 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.

The OWASP Foundation


http://www.owasp.org/
Agenda

Introduction
Testing
Automated Tools
OWASP Top 10

OWASP AppSec Europe 2006 2


Introduction

In order to find vulnerabilities in web


applications we need to identify them:
Via code audit: a lot of work
Via 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

OWASP AppSec Europe 2006 3


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

OWASP AppSec Europe 2006 4


Testing

There is no standard to test web applications


How to test for vulnerabilities
Different 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?

OWASP AppSec Europe 2006 5


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

OWASP AppSec Europe 2006 6


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 testing
Automated tools also have a different approach

OWASP AppSec Europe 2006 7


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, …

OWASP AppSec Europe 2006 8


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, …
OWASP AppSec Europe 2006 9
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

OWASP AppSec Europe 2006 10


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 vulnerability
Same 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?

OWASP AppSec Europe 2006 11


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

OWASP AppSec Europe 2006 12


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?

OWASP AppSec Europe 2006 13


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

OWASP AppSec Europe 2006 14


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

OWASP AppSec Europe 2006 15


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

OWASP AppSec Europe 2006 16


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 

OWASP AppSec Europe 2006 17


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?

OWASP AppSec Europe 2006 18


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
OWASP AppSec Europe 2006 19
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

OWASP AppSec Europe 2006 20


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

OWASP AppSec Europe 2006 21


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

OWASP AppSec Europe 2006 22


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

OWASP AppSec Europe 2006 23


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

OWASP AppSec Europe 2006 24

You might also like