Web applications typically interact with a back-end database to retrieve persistent data and then present the data to the user as dynamically generated output, such as HTML web pages. However, this interaction is commonly done through a low-level API by dynamically constructing query strings within a general-purpose programming language, such as Java. This low-level interaction is ad hoc because it does not take into account the structure of the output language. Accordingly, user inputs are treated as isolated lexical entities which, if not properly sanitized, can cause the web application to generate unintended output. This is called a command injection attack, which poses a serious threat to web application security. This paper presents the first formal definition of command injection attacks in the context of web applications, and gives a sound and complete algorithm for preventing them based on context-free grammars and compiler parsing techniques. Our key observation is that, for an attack to succeed, the input that gets propagated into the database query or the output document must change the intended syntactic structure of the query or document. Our definition and algorithm are general and apply to many forms of command injection attacks. We validate our approach with SQLCHECK, an implementation for the setting of SQL command injection attacks. We evaluated SQLCHECK on real-world web applications with systematically compiled real-world attack data as input. SQLCHECK produced no false positives or false negatives, incurred low runtime overhead, and applied straightforwardly to web applications written in different languages.

This paper proposes a static analysis technique for detecting many recently discovered application vulnerabilities such as SQL injections, cross-site scripting, and HTTP splitting attacks. These vulnerabilities stem from unchecked input, which is widely recognized as the most common source of security vulnerabilities in Web applications. We propose a static analysis approach based on a scalable and precise points-to analysis. In our system, user-provided specifications of vulnerabilities are automatically translated into static analyzers. Our approach finds all vulnerabilities matching a specification in the statically analyzed code. Results of our static analysis are presented to the user for assessment in an auditing interface integrated within Eclipse, a popular Java development environment. Our static analysis found 29 security vulnerabilities in nine large, popular open-source applications, with two of the vulnerabilities residing in widely-used Java libraries. In fact, all but one application in our benchmark suite had at least one vulnerability.Context sensitivity, combined with improved object naming, proved instrumental in keeping the number of false positives low. Our approach yielded very few false positives in our experiments: in fact, only one of our benchmarks suffered from false alarms.

Monitoring-Oriented Programming (MOP) [19, 16, 20, 17] is a formal framework for software development and analysis, in which the developer specifies desired properties using definable specification formalisms, along with code to execute when properties are violated or validated. The MOP framework automatically generates monitors from the specified properties and then integrates them together with the user-defined code into the original system. The previous design of MOP only allowed specifications without parameters, so it could not be used to state and monitor safety properties referring to two or more related objects. In this paper we propose a parametric specification-formalism-independent extension of MOP, together with an implementation of JavaMOP that supports parameters. In our current implementation, parametric specifications are translated into AspectJ code and then weaved into the application using off-the-shelf AspectJ compilers; hence, MOP specifications can be seen as formal or logical aspects. Our JavaMOP implementation was extensively evaluated on two benchmarks, Dacapo [13] and Tracematches [8], showing that runtime verification in general and MOP in particular are feasible. In some of the examples, millions of monitor instances are generated, each observing a set of related objects. To keep the runtime overhead of monitoring and event observation low, we devised and implemented a decentralized indexing optimization. Less than 8 % of the experiments showed more than 10 % runtime overhead; in most cases our tool generates monitoring code as efficient as the hand-optimized code. Despite its genericity, JavaMOP is empirically shown to be more efficient than runtime verification systems specialized and optimized for particular specification formalisms. Many property violations were detected during our experiments; some of them are benign, others indicate defects in programs. Many of these are subtle and hard to find by ordinary testing.

RFID systems as a whole are often treated with suspicion, but the input data received from individual RFID tags is implicitly trusted. RFID attacks are currently conceived as properly formatted but fake RFID data; however no one expects an RFID tag to send a SQL injection attack or a buffer overflow. This paper is meant to serve as a warning that data from RFID tags can be used to exploit back-end software systems. RFID middleware writers must therefore build appropriate checks (bounds checking, special character filtering, etc..), to prevent RFID middleware from suffering all of the well-known vulnerabilities experienced by the Internet. Furthermore, as a proof of concept, this paper presents the first self-replicating RFID virus. This virus uses RFID tags as a vector to compromise backend RFID middleware systems, via a SQL injection attack. 1.

This reports presents a runtime solution to a range of Web application security vulnerabilities. The solution we proposes called SecuriFly consists of instrumenting the application to precisely track the flow of data. When a potential vulnerability is observed, the application is either terminated to prevent the vulnerability from being exploited or special recovery code is executed and the application is allowed to continue on running. We have used SecuriFly to harden and experiment with a range of large opensource benchmarks written in Java. Protection provided by SecuriFly was sufficient to protect against all exploits we were able to generate. Chapter 1

Abstract. Data integrity is an assurance that data has not been modified in an unknown or unauthorized manner. The goal of this paper is to allow a user to leverage a small amount of trusted client-side computation to achieve guarantees of integrity when interacting with a vulnerable or untrusted database server. To achieve this goal we describe a novel relational hash tree, designed for efficient database processing, and evaluate the performance penalty for integrity guarantees. We show that strong cryptographic guarantees of integrity can be provided in a relational database with modest overhead. 1

Many modern software platforms today, including browsers, middleware server architectures, cell phone operating systems, web application engines, support thirdparty software extensions. This paper proposes InvisiType, an object-oriented approach that enables platform developers to efficiently enforce fine-grained safety checks on thirdparty extensions without requiring their cooperation. This allows us to harness the true power of third-party software by giving it access to sensitive data while ensuring that it does not leak data. In this approach, a platform developer encapsulates all safety checks in a policy class and selectively subjects objects at risk to these policies. The runtime enforces these policies simply by changing the types of these objects dynamically. It uses the virtual method dispatch mechanism to substitute the original methods and operations with code laced with safety checks efficiently. The runtime hides the type changes from application code so the original code can run unmodified. We have incorporated the notion of InvisiType into the Python language. We have applied the technique to 4 realworld Python web applications totaling 156,000 lines of code. InvisiType policies greatly enhance the security of the web applications, including MoinMoin, a popular, 94,000line Wiki Engine. MoinMoin has a large number of thirdparty extensions, which makes security enforcement important. With less than 150 lines of Python code, we found 16 security bugs in MoinMoin. This represents a significant reduction in developers ’ effort from a previous proposal, Flume, which required 1,000 lines of C++ code and modifications to 1,000 lines of Python code. Our InvisiType policies successfully found 19 cross-site scripting vulnerabilities and 6 access control errors in total. The overhead of applying the policies is less than 4 percent, indicating that the technique is practical. 1

We present xJS, a practical framework for preventing code-injections in the web environment and thus assisting for the development of XSS-free web applications. xJS aims on being fast, developer-friendly and providing backwards compatibility. We implement and evaluate our solution in three leading web browsers and in the Apache web server. We show that our framework can successfully prevent all 1,380 real-world attacks that were collected from a wellknown XSS attack repository. Furthermore, our framework imposes negligible computational overhead in both the server and the client side, and has no negative sideeffects in the overall user’s browsing experience. 1

Abstract not found

Code-injection attacks can take place in a large variety of layers, from native code to databases and web applications. The latter case involves mainly client-side code injection in the browser environment, also known as Cross-Site Scripting (XSS). There are numerous ways to defeat XSS attacks, from static and taint analysis to policy enforcement in the web browser. In this paper, we enlist new forms of XSS attacks that seek to bypass browser enforced policies. The attacks outlined in this paper resemble the classic return-tolibc attack in native code. We propose a new form of code isolation, based on browser actions, in order to mitigate the problem. 1.