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