1 / 28

QED

QED. Automatic Generation of XSS and SQL Injection Attacks with Goal-Directed Model Checking. Regina Bohn Alex Langhart Keegan Schulz. Layout. Introduction and Overview Vulnerability Specifications Input Optimization The Results and Summary Related Work The End. Introduction.

tacita
Download Presentation

QED

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. QED Automatic Generation of XSS and SQL Injection Attacks with Goal-Directed Model Checking Regina Bohn Alex Langhart Keegan Schulz

  2. Layout • Introduction and Overview • Vulnerability Specifications • Input • Optimization • The Results and Summary • Related Work • The End

  3. Introduction • Problem • XSS and SQL injections are responsible for a large number of security breaches • Proposed Solution • QED goal-directed model-checking system

  4. QED Overview • Java web applications • Vulnerabilities of interest specified • QED eliminates inputs not of interest • Model Checking • Reports example attacks if vulnerability specifications are matched

  5. Relevance of QED • Web based businesses • New architecture means new vulnerabilities • Commercial systems rely on black box testing • Tester can only make HTTP requests and examine the responses

  6. Design Principles • Focus on class of taint-based vulnerabilities • New architecture means new vulnerabilities • Exploit higher level semantic information about the framework • Java Servlets • JSPs • Apache Struts • Model Checking by simulated program execution on candidate input

  7. Contributions • Session-based model for user input • Programmable approach to check event-driven applications • Model Checking framework to explore java web applications • Experimental Validation of the Approach

  8. Taint-based Vulnerabilities • SQL Injection • Cross-site Scripting • Reflection Attack • Detection • How to detect • Considering sequences of URLs

  9. Attack Scenario <html> <body> <h1>Login required</h1> <p>To search for <%=getSession().getAttribute("text")%>, you must first log in.</p> <form> <!-- rest of page... → Snippet fromsearch login.jsp • <html> • <head> • <% HttpSession s = getSession(); • if (s.getAttribute("login") == null) { • s.setAttribute("text", • getParameter("s"); %> • <meta http-equiv="refresh" • content="10;URL=search login.jsp"> • </head> • <body></body> • </html> • <% } else { %> • <!-- rest of page... → • Snippet from search begin.jsp.

  10. Domain of Web Applications • Web Application • Session-based reactive system • Session • Series of events • Event • HTTP request submitted by same user • Session data • User-specific data temporarily stored on server • Attack • Sequence of events within a session

  11. Vulnerability Specifications • Taint Source • Propagators • Taint Sink • Not Sanitized

  12. XSS Vulnerability Specification query source(object * x) Matches HttpServletRequest.getParameter(x) | x = Cookie.getValue(); query prop(object * x, object *y) matches (StringBuilder) y.append(x) | y = (StringBuilder) x.toString(); query sink(object * x) matches JspWriter.print*(x) | JspWriter.write(x, ...);

  13. Input Generation • Generated GET parameters include • common values • null • “Magic keywords” found by detecting comparisons of GET variables with constants • A more detailed analysis of the Java program could ensure that the parameters are exhaustive. This is generally overkill though.

  14. Goal-Directed Optimization • QED optimizations work by reducing the search space – sets of paths and input parameters • Some URL sequences are redundant or unlikely to produce new vulnerabilities • Four optimizations are used…

  15. Filtering Final Results • Remove sequences that do not end on a URL that accesses a taint sink • e.g. index.jsp does not access the database, so remove any sequences that end with index.jsp • Sequences are tested in increasing-length order, so another sequence will catch it

  16. Eliminating Redundant URL Sequences • HTTP is a stateless protocol • State is implemented at a higher level through cookies and sessions • Cookies can be tampered with, but session information is maintained by the server • Cookies are removed and generalized by detecting dependencies between entry points…

  17. Finding Session Dependencies If search.jsp is a taint sink, then it depends on all of the entry points. However, if index.jsp is a taint sink, then login.jsp and search.jsp can be eliminated because index.jsp does not depend on them. Session Variables index.jsp index.jsp Var A Var B Var C Var D Var A login.jsp Var B login.jsp Var C search.jsp search.jsp Var D Writes to Is read by

  18. Removing Repetitive Cycles • In the previous dependencies, if one is cyclic (e.g. index.jsp depending on index.jsp), then there is an infinite number of sequences • This is restricted to being called once

  19. Statically Eliminate Sequences • All URLs passing the other 3 optimizations are further analyzed statically • A special algorithm (described in another paper) is used to look at each URL request in a sequence • The algorithm soundly determines if it is possible to provide parameters that permit the control flow needed to reach the sink • Tracks pointers, copies, new objects, etc.

  20. The Results Dependency pairs are found by the algorithm talked about earlier.

  21. PersonalBlog • Doesn’t make any use of session data • Fewer event handlers == quicker run through • Previous run through with PQL as dynamic checker • QED found an additional vulnerability previous run didn’t find

  22. JOrganizer • Access to database through an “Object Query Language”, preventing direct access • 15 event handlers cannot touch database; others require a log-in event • QED only tests log-in event and database access event pairs

  23. JGossip • Many cyclic dependencies among the event handlers • Events requested a ton of parameters, restrict number of parameters t0 2

  24. Related Work • FindBugs • Metal system • SQLCHECK • WebSSARI • Focuses on interpretation of PHP code • Looks for violations of data flow control • FiSC • What QED’s design philosophy based on

  25. Summary • Plenty of security risks in using web applications • Combine and use 3 approaches • Sound, sophisticated program analysis • Dynamic monitoring • Model checking

  26. The End

  27. Other Questions? Comments? Unfinished Business? Corrections? Insults? Compliments? Concerns? Quibbles?

More Related