Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing


Published on

This talk was given at OWASP AppSec Europe 2008.
Full paper can be downloaded from here:

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing

  1. 1. Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing Andrew Petukhov [email_address] Department of Computer Science Moscow State University
  2. 2. Contents <ul><li>Input validation vulnerabilities. Detection techniques </li></ul><ul><li>Drawbacks of the Taint Propagation approach </li></ul><ul><li>Solving drawbacks of the Taint Propagation approach </li></ul><ul><li>Implementing integrated Dynamic Analysis with Penetration Testing approach </li></ul><ul><li>Conclusions and Future work </li></ul>
  3. 3. Input Validation Vulnerabilities Common approaches: Taint propagation <ul><li>Implemented in static analyzers and runtime protection systems </li></ul><ul><li>Vulnerability Model: </li></ul><ul><ul><li>All data received via HTTP-requests is untrustworthy; </li></ul></ul><ul><ul><li>All local data is trustworthy; </li></ul></ul><ul><ul><li>Untrustworthy data can be made trustworthy by special kinds of processing; </li></ul></ul><ul><ul><li>Untrustworthy data should not be used in sensitive operations: HTTP response construction, database queries, systems calls, eval statements, etc. </li></ul></ul>
  4. 4. Input Validation Vulnerabilities Common approaches: Syntactic checking <ul><li>Implemented in static analyzers and runtime protection systems </li></ul><ul><li>Vulnerability Model: </li></ul><ul><ul><li>Queries to external services (DBMS, OS interpreter, LDAP, etc.) usually have fixed syntactic structure; </li></ul></ul><ul><ul><li>Input validation vulnerabilities render possible injection attacks, which alter the syntactic structure of queries; </li></ul></ul><ul><ul><li>The syntactic structure of such queries should not depend on the user input. </li></ul></ul>
  5. 5. Approaches-Do-Not-Work example <ul><li>Web application module A: </li></ul><ul><ul><li>Receive user data via HTTP request; </li></ul></ul><ul><ul><li>Encode HTML special characters, escape SQL special characters; </li></ul></ul><ul><ul><li>Store data in database table (ex. table A, column a). </li></ul></ul><ul><li>Web application module B: </li></ul><ul><ul><li>Retrieve data from column ‘a’ of table A; </li></ul></ul><ul><ul><ul><li>The data is returned unescaped and therefore SQL-tainted! </li></ul></ul></ul><ul><ul><li>Use this data in another database query. </li></ul></ul><ul><ul><ul><li>Here comes input validation vulnerability that allows second order SQL injection attack! </li></ul></ul></ul>
  6. 6. Drawbacks of the Taint Propagation approach <ul><li>Untyped data taintedness; </li></ul><ul><li>Inability to handle sanitization performed by conditional branching: </li></ul><ul><li>Trust to sanitization routines; </li></ul><ul><li>Intra-module scope of view. </li></ul>
  7. 7. Possible solutions <ul><li>Introduce classes for data taintedness (xss, shell, sql, etc.). Solves drawback № 1. </li></ul><ul><li>Use Taint Propagation with Syntactic checking. Solves drawback №2 . </li></ul><ul><li>Use penetration testing for input generation for dynamic analysis or string analysis in static to validate sanitization routines. Solves drawback № 3. </li></ul><ul><li>Interconnect Data Flow Graphs built for separate modules using information about database interactions. Solves drawback №4 . </li></ul>
  8. 8. Implementation considerations <ul><li>Implement as Static analyzer: </li></ul><ul><ul><li>Pro: Completeness </li></ul></ul><ul><ul><ul><li>Reason: if sound analysis says there are no vulnerabilities, it’s truth </li></ul></ul></ul><ul><ul><li>Contra: False positives </li></ul></ul><ul><ul><ul><li>Reason: dynamic nature of scripting languages, undecidability of static analysis </li></ul></ul></ul><ul><li>Implement as Dynamic analyzer with Penetration tester: </li></ul><ul><ul><li>Pro: Precise reporting </li></ul></ul><ul><ul><ul><li>Reason: every single variable value could be observed </li></ul></ul></ul><ul><ul><li>Contra: Incompleteness </li></ul></ul><ul><ul><ul><li>Reason: depends on the coverage of the test cases </li></ul></ul></ul>
  9. 9. Security and Development Life Cycle <ul><li>Design: Threat Modeling, Safe Technologies </li></ul><ul><li>Implementation: Safe Coding </li></ul><ul><li>Testing: Penetration Testing, Dynamic and Static analysis </li></ul><ul><li>Operation: Web Application Firewalls, Runtime Protection, Sandboxing </li></ul><ul><li>Assessment: Code Review, Static Analysis, Penetration Testing </li></ul>
  10. 10. Decision: Dynamic analysis with Pentesting Our Motivation <ul><li>We want the tool to: </li></ul><ul><ul><li>Aid in web application testing (or Assessment); </li></ul></ul><ul><ul><li>Produce accurate results (no useless investigation); </li></ul></ul><ul><ul><li>Utilize test cases used during the testing phase (in theory, these test cases are specially developed by testing staff to achieve good coverage); </li></ul></ul><ul><ul><li>Require minimal configuration. </li></ul></ul><ul><li>We do not require the tool to: </li></ul><ul><ul><li>Satisfy high performance requirements (this is not protection system, it’s not vital); </li></ul></ul><ul><ul><li>Address coverage issues (operate only with the supplied test cases). </li></ul></ul>
  11. 11. Implementation architecture <ul><li>Pentest module based on OWASP WebScarab </li></ul><ul><li>Fuzz vectors – OWASP Fuzzing Codebase </li></ul><ul><li>Dynamic analysis – instrumented Python 2.4.4 </li></ul>
  12. 12. Conclusions <ul><li>We have defined several drawbacks of the existing input validation vulnerabilities detection approaches; </li></ul><ul><li>We have pointed out possible solutions to each of the stated drawbacks; </li></ul><ul><li>We have extended the formal Tainted Mode model to incorporate inter-module data flows; </li></ul><ul><li>We have developed an automated tool that detects input validation vulnerabilities using dynamic analysis and penetration testing. </li></ul>
  13. 13. Future work <ul><li>Perform extensive evaluation </li></ul><ul><ul><li>Currently, we have tested our approach on the four vulnerable web applications, successfully detecting already known vulnerabilities; </li></ul></ul><ul><ul><li>Evaluate our approach against more web applications; </li></ul></ul><ul><ul><li>Assess each web application with penetration testing tool, dynamic analysis tool and integrated tool, then compare the results; </li></ul></ul><ul><ul><li>Assess TCO of the developed tool. </li></ul></ul><ul><li>Address the initial phase: automated preparation of the input test cases, integration with code coverage analysis tool. </li></ul>
  14. 14. Thank You! Any question?