1 / 16

Sound and Precise Analysis of Web Applications for Injection Vulnerabilities

Explore the significance of SQL injection vulnerabilities in web applications based on the article by Gary Wassermann and Zhendong Su. Understand soundness and static analysis techniques for detecting vulnerabilities, particularly in PHP scripting languages.

Download Presentation

Sound and Precise Analysis of Web Applications for Injection Vulnerabilities

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. Sound and Precise Analysis of Web Applications for Injection Vulnerabilities CSC-682 Cryptography & Computer Security Based on an article by : Gary Wassermann & Zhendong Su Pompi Rotaru

  2. Why study SQLCIV • Web applications are widely by everybody, so vulnerabilities that allow an attacker to compromise a web application’s control of its data pose a significant threat. • In 2006, 14% of the reported vulnerabilities were SQL command injection vulnerabilities (SQLCIV), making SQL injection the second most frequently reported security threat. • It is speculated the theses types of attacks are more frequent then reported. • This vulnerability is common in scripting languages like PHP because it uses queries via low-level string manipulation and it uses strings as the default representation for data and code.

  3. Definitions: sound and static • SOUNDNESS - a property checking tool is said to be sound with respect to the specification if it will always report a problem if one exists. Such tool will never suffer a false negative. • STATIC analysis – the process of analyzing the code without executing it.

  4. Existing approaches • Existing approaches : static and dynamic • General (run-time) techniques have higher overhead then the ones doing well-placed checks on untrusted input. • Some runtime techniques require a modified runtime system, which constitutes a practical limitation in terms of deployment and upgrading. • Statically verifying code to be free from one kind of error (static type checking) reduces the risk for other errors. • Some static analyses techniques require a specification in the form of a regular expression for each query-generated point or hotspot in the program. • The static taint analysis cannot guarantee the absence of of SQLCIV without being overly conservative • Static taint analysis for PHP typically requires user assistance to resolve dynamic includes.

  5. The new approach • They proposed a sound, automatic static analysis algorithm that overcomes previous limitations. • The proposed method considers as attacks those queries for which user input changes the intended syntactic structure of the generated query. • It checks conformance to this policy by conservatively characterizing the values a string variable may assume with a context free grammar, tracking the nonterminals that represent user-modifiable data, and modelling string operations precisely as language transducers. • It is grammar-based; they model string values as context free grammars (CFGs) and string operations as language transducers following Minamide.

  6. How it works: • The analysis takes PHP files as input and returns as output either a list of bug reports or the message “verified”. • In order to provide useful bug reports, the sources are labelled as : - “direct” if user can influence the source directly - “indirect” if user can influence the source indirectly (as with data returned by a database query); it provides data from a source whose data may come from untrusted users (less severe than that of standard injection attacks). • Has 2 phases : - The first one generates an annotated CFG, showing which string is untrusted. - The second one takes the CFG previously generated and checks whether all strings are safe (there are no SQL injections).

  7. How it works: This is the grammar production for this code

  8. Analysis Algorithm • 1st phase (String-Taint Analysis) : String analysis has the goal of producing a representation of all strings values that a variable may assume at a given program point. • A) Adapting string analysis • - The goal of the analysis is producing not only a representation of all string values that a variable may assume, but also a function from string values to substrings whose values come from direct or indirect sources. • - The first step of the string analysis translates the program into static single assignment form. Then we translate each assignment statement into a grammar production that yields a CFG that reflects the program’s dataflow. By simply annotating the nonterminals corresponding to direct and indirect sources, we have a string-taint analysis for programs with concatenation, assignments, and control flow. • - Converting extended CFGs into standard CFGs requires some approximation, and Minamide models string operations as finite state transducers (FSTs) in order to capture their effects and make the approximation reasonably precise.

  9. Analysis Algorithm (continuation) • B) Tracking Substrings through Filters • In order to avoid reporting many false positives, the string-taint analyzer must model the effects of filters and propagate annotations through them. • This happens because many string operations that PHP provides as library functions behave as finite state transducers. • C) Handling Other String Operations • Because real-world web applications also perform operations involving strings that do not simply map strings to strings, we must determine how substrings in the input map to substrings in the output and propagate annotations accordingly.

  10. Analysis Algorithm (continuation) • 2nd phase (Policy-Conformance Analysis) : The second phase checks the generated, annotated grammar for SQL injection attacks. We check that inputs take the syntactic position of literals, and also the case when the input may be derived from an arbitrary nonterminal in the reference grammar. • A) Untrusted Substrings as Literals : • - The first check attempts to find untrusted substrings that cannot be syntactically confined in any SQL query; • - The second check finds the nonterminals that occur only in the syntactic position of string literals and, (for each one) either verifies it as safe or find that it derives some unconfined string; • - The third check attempts to identify those remaining nonterminals that only derive numeric literals.

  11. Analysis Algorithm (continuation) • B) Untrusted Substrings Confined Arbitrarily • If any nonterminals remain after the checks in previous section we check whether each string derivable from them is derivable from some nonterminal in the SQL grammar. • Derivability is checked using an extension of Earley’s parsing algorithm.

  12. Evaluation • Was done on five real-world PHP web applications. • The tool successfully discovered previously unknown vulnerabilities in real-world programs, has a low false-positive rate, and scales to large programs. • They had 20.8% false-positive rate which demonstrate that the approach is effective for finding SQLCIVs and verifying the absence of them. • The tool successfully analyzed all of the web applications in the test suite. • The tool has some limitations, because of certain unsupported constructs, but they represent only a current limitation in the prototype.

  13. Evaluation (continuation) • The following thing were discovered during testing: - the grammar size is not necessarily proportional to the web application size; - the string analysis time is not necessarily proportional to the grammar size. • SQLCIV checking phase is relatively efficient. Although the grammars had more than one million production rules in some cases, SQLCIV checking never took more than a few minutes, and usually took less.

  14. Soundness • The authors claim that if the analysis algorithm does not report any SQLCIVs for a given web application P, then P has no SQLCIVs.

  15. Conclusions • They have implemented this analysis for PHP, and applied it to several real-world web applications. • It successfully analyzes the largest PHP web application, about 100k LOC. • It characterizes the sets of possible database queries that a web application may generate using context free grammars, and tracks information flow from untrusted sources into those grammars. • It detected unknown vulnerabilities in real world web applications with few false positives • Because of the success of the applications the authors plan to improve it by adding new features.

  16. Questions ??!?

More Related