5.
Testing <ul><ul><li>There is no standard to test web applications </li></ul></ul><ul><ul><ul><li>How to test for vulnerabilities </li></ul></ul></ul><ul><ul><ul><li>Different type of payloads that must be used e.g. <script>alert(document.cookie)</script vs <body onload=alert(document.cookie)> </li></ul></ul></ul><ul><ul><ul><li>What should be the result of a test: how to detect a pop-up window in an HTML stream? </li></ul></ul></ul><ul><ul><ul><li>What should not be the result of a test: will a script tag embedded in another script tag really get executed? </li></ul></ul></ul>OWASP AppSec Europe 2006

6.
Testing <ul><ul><li>OWASP Testing Guide is a framework and a guideline, not a technical step-by-step guide </li></ul></ul><ul><ul><li>OSSTMM - Open Source Security Testing Methodology Manual: more detailed but not on an web app level more on a network/OS level </li></ul></ul><ul><ul><li>No education or recognized certifications for security testing </li></ul></ul>OWASP AppSec Europe 2006

7.
Testing <ul><ul><li>People have different backgrounds: </li></ul></ul><ul><ul><ul><li>Network security: how experienced are they in XML parsing, AJAX, SQL,… </li></ul></ul></ul><ul><ul><ul><li>Functional testers: how do they know what a security vulnerability is? How can they exploit a vulnerability? </li></ul></ul></ul><ul><ul><ul><li>Developers: hate to test or audit code </li></ul></ul></ul><ul><ul><ul><li>Application security expert: has the experience and the knowledge of the three groups above but are a rare species </li></ul></ul></ul><ul><ul><li>Conclusion: </li></ul></ul><ul><ul><ul><li>Everyone has a different approach to testing </li></ul></ul></ul><ul><ul><ul><li>Automated tools also have a different approach </li></ul></ul></ul>OWASP AppSec Europe 2006

11.
Some questions <ul><ul><li>Is the Top 10 about vulnerabilities, attacks or bad coding practices? </li></ul></ul><ul><ul><li>How to differentiate the different classifications? </li></ul></ul><ul><ul><ul><li>Invalidated input (A1) is a vulnerability, XSS (A4) is an attack against this vulnerability </li></ul></ul></ul><ul><ul><ul><li>Same for A5, A6 and A7 </li></ul></ul></ul><ul><ul><li>How to define a test plan for the OWASP Top 10? </li></ul></ul><ul><ul><li>What are the payloads to discover the Top 10? Eg. 10000000 X or 10000000 A for buffer overflow? </li></ul></ul>OWASP AppSec Europe 2006

12.
A1. Unvalidated Input <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: insert all possible values for parameters: GET, POST, hidden fields, cookies, HTTP Headers,... </li></ul></ul><ul><ul><li>Automated tools: do this very good, but lack classification of the errors returned </li></ul></ul>OWASP AppSec Europe 2006

14.
A2. Broken Access Controls <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: login with valid accounts with different privileges and attempt to access protected parts like URLs, Struts actions, hidden fields,... </li></ul></ul><ul><ul><li>Automated tools: can guess known URIs like /admin but do this within the existing user context or as an anonymous user </li></ul></ul>OWASP AppSec Europe 2006

17.
A4. Cross Site Scripting Flaws <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: use RSnake’s cheat sheet for XSS filter evasion (http://ha.ckers.org/xss.html) </li></ul></ul><ul><ul><li>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  </li></ul></ul>OWASP AppSec Europe 2006

18.
A5. Buffer Overflows <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: replace every parameter with a lot of data: integers, strings, binary data,... </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Results: crash of the web application, corrupt database, crash of the server so be very careful on a production environment </li></ul></ul><ul><ul><li>Automated tools: detect database corruption? </li></ul></ul>OWASP AppSec Europe 2006

19.
A6. Injection Flaws <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: replace every parameter with command injection strings which depend on the operating system in use </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Results: output of the command injection must be obtained, how to automate this? E.g. Net user /add Erwin </li></ul></ul>OWASP AppSec Europe 2006

20.
A7. Improper Error Handling <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: corrupt parameters and look for propagating exceptions </li></ul></ul><ul><ul><li>Automated tools: by default </li></ul></ul><ul><ul><li>Result: how to classify an uncaught exception, this depends on the exception </li></ul></ul>OWASP AppSec Europe 2006

22.
A9. Denial of Service <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: attempt to brute-force accounts, performance test,… </li></ul></ul><ul><ul><li>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 </li></ul></ul>OWASP AppSec Europe 2006

23.
A10. Insecure Configuration Management <ul><ul><li>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. </li></ul></ul><ul><ul><li>Test: use Google to retrieve vulnerabilities about SUT and try to exploit them </li></ul></ul><ul><ul><li>Automated tools: can test automatically for these vulnerabilities and when they have a built-in update function these are very useful </li></ul></ul>OWASP AppSec Europe 2006