Using parse tree validation to prevent SQL injection attacks

An SQL injection attack targets interactive web applications that employ database services. Such applications accept user input, such as form fields, and then include this input in database requests, typically SQL statements. In SQL injection, the attacker provides user input that results in a different database request than was intended by the application programmer. That is, the interpretation of the user input as part of a larger SQL statement, results in an SQL statement of a different form than originally intended. We describe a technique to prevent this kind of manipulation and hence eliminate SQL injection vulnerabilities. The technique is based on comparing, at run time, the parse tree of the SQL statement before inclusion of user input with that resulting after inclusion of input. Our solution is efficient, adding about 3 ms overhead to database query costs. In addition, it is easily adopted by application programmers, having the same syntactic structure as current popular record set retrieval methods. For empirical analysis, we provide a case study of our solution in J2EE. We implement our solution in a simple static Java class, and show its effectiveness and scalability. 1

On Soundness of Verification for Software with Functional Semantics and Abstract Data Types

Abstract. A threat to the soundness of modular verification systems arises from the following combination of specification and programming language features: a semantics in which the denotation of every program operation is a mathematical function, the opportunity to write relational specifications for program operations, and support for abstract data types. There is no apparent practical workaround for this problem short of changing one of these features. After accounting for software engineering considerations, the recommendation is to relax the first one and to restrict the second, i.e., (1) to partition program operations into "function" operations and "procedure" operations; (2) to define the language semantics so the meaning of each function operation is a mathematical function, and to permit only a functional specification for a function operation; and (3) to define the language semantics so the meaning of each procedure operation is a mathematical relation, and to permit either a functional or a relational specification for a procedure operation

Reasoning about Parameterized Components with Dynamic Binding

Parameterized components provide an effective way of building scalable, reliable, flexible software. Techniques have been developed for reasoning about parameterized components in such a way that the relevant properties of a parameterized component can be predicted based on the restrictions on actual parameters. These techniques assume that the parameters are bound at compile-time. But in some cases, compile-time is just not late enough to instantiate a parameterized component; we would like to push instantiation into run-time instead. Doing this is sometimes dangerous, since we can no longer depend on the type system of the language to support our reasoning methods. In this paper, we present a specification notation and associated proof obligations, which when satisfied, allow us to extend the theories of reasoning about templates with static binding to dynamically-bound templates. We present these proof obligations in the context of the Service Facility pattern, which is a way of building templates whose parameters are dynamically bound

Micro-Architecture vs. Macro-Architecture

The field of study commonly known as "software architecture" should be split into two subareas: micro-architecture and macro-architecture. Work to date under the name "software architecture" has concentrated largely on macro-architecture. But microarchitecture, a.k.a. software component engineering, is of equal concern. Copyright 1994 by the authors. All rights reserved. THIS PAGE INTENTIONALLY BLANK 1 1. Introduction Economists discovered some time ago that one view of economics cannot be made to fit all economic situations. They noticed that different analytical techniques and models were needed when looking at economics-in-the-small as compared to economics-in-the-large [Bach 87]. This is not to say that one is more important than the other, or that one deserves more or less attention. It simply admits that the understanding and analysis of these two different classes of economic situations require different approaches in order to capture and reason about their fundamental pro..

Components-First Approaches to CS1/CS2: Principles and Practice

ABSTRACT Ê Among the many ways to focus CS1/CS2 content, two have been published that emphasize concepts of component-based software engineering. Courses based on these two instances of a "components-first " approach are remarkably similar in several crucial respectsÑwhich is surprising because they were developed independently and with very different objectives. Indeed, the two versions are based on virtually the same principles for content organization, and they share many common features that are unusual for CS1/CS2. Yet, they are notably different in other ways. Detailed analysis of similarities and differences suggests that it might be possible to transfer some of their claimed and documented advantages to other approaches within the programming-first paradigm for CS1/CS2, by rearranging the content of such courses in accord with the underlying principles of the components-first approach