Rubicon: Scalable Bounded Verification of Web Applications

Transcription

1 Joseph P. Near Research Statement My research focuses on developing domain-specific static analyses to improve software security and reliability. In contrast to existing approaches, my techniques leverage properties specific to a particular domain to improve scalability and reduce programmer burden. Scalability. Existing research has focused on general-purpose static analyses for all kinds of programs. The most precise analyses come with poor scalability, prompting the development of less precise, more scalable versions. My work chooses instead to compromise on generality, but maintain preciseness: by focusing on a particular domain of programs, I have developed precise static analyses that scale to real-world problems. Programmer Burden. Static analysis can be used to determine what a program does, but not to figure out what the program is supposed to do. Existing research has focused on classes of bugs with general specifications (e.g. buffer overflows or SQL injection) or required the programmer to write a formal specification. My work, on the other hand, leverages domain properties to eliminate the requirement of a written specification. The process typically becomes interactive the programmer inspects an inferred specification for correctness or explores the space of program behavior to find bugs relieving the programmer of the burden of writing a specification. To address the problem of scalability, I developed Rubicon, a scalable bounded verifier for web applications. To reduce programmer burden, I built Derailer, which leverages Rubicon s scalable analysis but uses developer interaction rather than a specification to uncover security bugs. Rubicon: Scalable Bounded Verification of Web Applications The web is fast becoming the most popular platform for application programming, but web applications continue to be prone to security bugs. Rather than write them explicitly, developers encode security policies in the form of checks embedded in application code. Many security bugs are the result of programmers simply forgetting to include one of these checks. To find these missing security checks, I built Rubicon [1], a verifier for Ruby on Rails applications. Rubicon provides automatic bounded verification of application code against a specification written by the developer. Its specification language is as expressive as first-order logic, but based on a popular domain-specific testing language. To extract verification conditions from the target Rails application, Rubicon uses symbolic execution a technique that yields precise results but can be exponential in the number of program paths. The key insight of Rubicon is that web applications are different from regular programs in ways that can be exploited to improve the scalability of symbolic execution. First, web applications are built from independent actions, each of which is typically fewer than 20 lines of code; these actions can be analyzed independently. Second, web developers tend to embed program logic in database queries, so applications have few conditionals and few loops. For example, the 20 most popular Rails applications on Github have only 12 while loops in total. These properties minimize the exponential behavior of symbolic execution, enabling the technique to scale to even the largest Rails applications. A second challenge in building Rubicon was the size and complexity of Rails itself. The framework is over 200,000 lines of code, and is so reliant on the unspecified behaviors of the standard Ruby interpreter that until recently no other Ruby implementation could run Rails applications. I began by building a 1

2 standalone symbolic evaluator for Ruby, but quickly realized that replicating enough of the standard interpreter to run Rails programs would take several years of work. The solution was to take advantage of Ruby s flexibility to build a symbolic evaluator as a library, and use the standard Ruby interpreter to perform symbolic execution [3]. This strategy ensures compatibility with Rails, since the standard interpreter is used. The symbolic evaluation library defines a class of symbolic values and overrides the operators of the standard library to compute over them. The resulting symbolic execution library is less than 1000 lines of code long. Rubicon translates the verification conditions resulting from symbolic execution into the Alloy specification language and performs bounded verification against the specification using the Alloy Analyzer. Like the symbolic execution step, this verification step is scalable due to careful leverage of domain properties. First, Rubicon specifications are intentionally partial, with granularity selected by the developer: a single specification may cover only a single property on a single action. Second, symbolically executing the code with respect to a single specification produces a slice that omits parts of the implementation unrelated to the property. Finally, Alloy s relational logic is a good fit for Rails relational database, so Alloy s optimizations apply directly. As a result, both steps of Rubicon s analysis scale to real-world Rails applications. I used Rubicon to specify and check properties of five open-source Rails applications. I converted a total of 250 developer-written test cases into general specifications checking the same desired property as the test case. Rubicon s analysis took an average of 3 seconds per partial specification, and no specification took longer than 5 seconds to check. In the largest application, Fat Free CRM (23k lines of code), Rubicon s analysis of a converted test case found a previously unknown security bug, which the developers confirmed and fixed in the next release. Derailer: Specification-Free Bug Finding Web developers are reluctant even to attempt writing specifications, and when they do, they often make mistakes. Moreover, properties that are the most difficult to test like security are also the most difficult to specify. Even my own security policy specifications often contained errors, and were regardless timeconsuming to produce. Rubicon s requirement for a specification has therefore been a barrier to its adoption, despite its success as a verification tool. In writing a number of security policy specifications, I found striking similarities across applications. Most policies implement some form of access control, and most security vulnerabilities are caused by either a missing security check or an access path not exposed by the user interface that bypasses the security checks. This experience led to the key insight of Derailer: that web application security policies tend to be uniform. Sensitive data is usually subject to security checks everywhere it is used, so an access that is missing one of those checks is likely to be a mistake. Derailer [2] helps Rails developers find security bugs without writing a specification. It uses the same symbolic evaluator I developed for Rubicon; instead of producing verification conditions, however, Derailer builds a set of data exposures. Each exposure comprises a symbolic representation of a set of database records and the constraints under which they might be displayed to a user of the application; the set of 2

3 exposures therefore represents all the ways in which information from the database can appear on a page rendered by the application. To find missing security checks, the developer and the tool together infer a specification of the application s security policy, and the tool finds exposures that do not obey the policy. First, the developer classifies the constraints on an exposure according to whether or not they are securityrelated. Then, Derailer highlights exposures missing some of the selected security constraints. The developer chooses either to iterate adding or removing constraints to make the highlighted exposures obey the policy or to consider those exposures security bugs. When the developer is finished with this iterative process, the selected constraints represent a specification of the security policy, and the remaining highlighted exposures are security bugs. This approach has been very successful in finding bugs, mainly because Derailer does not require the time-consuming step of writing a specification. For example, I have used Derailer to: Find security bugs in 65% of student projects from a web design course at MIT 30% of which the TAs missed Find security bugs in 18% of the 50 most popular Rails applications on Github; of applications that implement security, 30% had bugs Test scalability on the 1000 most popular Rails applications on Github: 90% of analyses completed in 15 seconds, and 100% in 45 seconds Summary & Future Directions Rubicon s scalability comes from properties unique to the domain of web applications the decision to use symbolic execution was due to the structure of Rails programs. Similarly, Derailer s ability to find bugs in the absence of a formal specification is based on another domain property: the uniformity of security policies. The success of these projects suggests both further improvements in the domain of web applications, and that similar improvements are possible in other domains. Cyber-physical systems. My domain-specific approach to static analysis was actually inspired by a case study in building a dependability case for the proton therapy system at Massachusetts General Hospital [4], which provides radiation treatment to cancer patients. The safety requirements of this system involve statements about its environment, so verification requires building a formal model of the environment s properties. This is a difficult task, even for an expert, since the environment is complex; and if the environmental model is incomplete, the system may be verified correct even if it has a bug. I found that it was sufficient to check only the environmental properties on which the software actually depended, eliminating the need for a complete model of the environment. I used static analysis to enumerate the calls to libraries used for environmental interaction, and produced a short list of conditions for a domain expert to check. The same kind of environment-focused analysis could be used to ensure both security and reliability for the new generation of internet-connected cyber-physical systems. My work on web applications is a good starting point, since cyber-physical systems have similar structural properties, and the success of the proton therapy analysis suggests that analyses of other cyber-physical systems could likewise benefit from the application of domain-specific properties. To support this effort, I will build new collaborations with 3

4 the networking and security communities, to investigate the security and reliability guarantees desired by users and possible in each device s environment. Access control and APIs. My work on Derailer has focused on consistent application of access control policies, since failures in this area account for a large number of security bugs. But there is more work to be done in this area both in expanding the kinds of bugs Derailer can find and in providing more automation to make finding bugs easier. My experience with Rails applications suggests that developers make certain kinds of security mistakes over and over again. These mistakes suggest a corresponding set of heuristics that can detect them automatically. Derailer s analysis, combined with heuristics highlighting common kinds of mistakes, could make Derailer even easier to use. A large enough set of heuristics could, in turn, form a partial model of correctly implemented access control; violations of this model represent security bugs, and could be found automatically. Libraries for enforcing access-control policies are increasingly popular, since they represent a significant improvement over ad hoc security checks, but these libraries still require programmers to use them correctly. Derailer s model of analysis, interaction, and automation is also suitable for detecting inconsistent API use within an application; I plan to extend my work on Derailer to detect these mistakes. In fact, Derailer s model might even extend to other kinds of APIs, since they, too, expect consistent use. I therefore plan to build new collaborations within the software engineering community to explore the extent to which Derailer s analysis can help programmers use APIs correctly. Statistical models of behavior. If two exposures of the same data have inconsistent constraints, one of them represents a bug. But without information about the security policy, it is impossible to determine which one is buggy. Automatic anomaly detection techniques consider a large majority of consistent examples to represent a specification, and highlight examples outside of that set. Since web applications contain relatively few exposures, however, these techniques do not apply. The set of all web applications, on the other hand, contains a huge number of exposures. This aggregate set of exposures represents a library of specifications for different kinds of applications. Individual applications may contain bugs, but the average of all implementations of a particular piece of functionality represents a correct specification of that functionality. And as the amount of publicly available application code grows, so does the size of the library. I have already tested Derailer s scalability by running its analysis on more than 1000 open-source applications from Github; using Derailer s analysis to compile a database of the data exposures from every Rails application on Github would take only a few weeks of compute time. In collaboration with the machine learning community, I plan to explore the use of Derailer s analysis to build clusters of applications according to aspects of their functionality. Analysis results typical of a cluster would be considered a specification of that cluster, and would be compared against the analysis results of the target application. Security checks typical of the cluster but missing from the target represent likely bugs. A tool based on this approach may produce some false positives, but would enumerate bugs in a target application automatically. 4

5 References [1] Joseph P. Near and Daniel Jackson. Rubicon: bounded verification of web applications. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE), page 60. ACM, [2] Joseph P. Near and Daniel Jackson. Derailer: interactive security analysis for web applications. In Proceedings of the 29th ACM/IEEE international conference on Automated Software Engineering (ASE), pages ACM, [3] Joseph P. Near and Daniel Jackson. Symbolic execution for (almost) free: Hijacking an existing implementation to perform symbolic execution. MIT CSAIL Technical Report MIT-CSAIL-TR , [4] Joseph P. Near, Aleksandar Milicevic, Eunsuk Kang, and Daniel Jackson. A lightweight code analysis and its role in evaluation of a dependability case. In Proceedings of the 33rd International Conference on Software Engineering (ICSE), pages IEEE,