Idea: Using System Level Testing for Revealing SQL Injection-Related Error Message Information Leaks: Difference between revisions

SQL Injection Vulnerabilities. Consider a Java method used for the deletion of a patient’s information in a medical record system.  We present the relevant source code for this operation in Figure 1 (assume that patients are deleted by their names).  The vulnerability in this example was introduced in the line defining the SQL statement.  The example we have presented in Figure 1 performs no input validation and, as a result, the example contains a SQL injection vulnerability relative to the use of the name parameter.  An attacker could cause change to the interpretation of the SQL query by entering the SQL command fragment “‘ OR TRUE --“ in the input field instead of any valid user name in the web form.

The single quotation mark (‘) indicates to the SQL parser that the character sequence for the username column is closed, the fragment OR TRUE is interpreted as always true, and the fragment of the query after the hyphens (--) is a comment.  The altered WHERE clause of the SQL statement will be interpreted as always true and thus every patient is deleted from the table.  Because no input validation was performed, the attacker can exploit the system by inserting the malicious input in the name field, and causing truncation of the Patients table. Thus, the bolded statement in Figure 1 is an example of a SQL injection hotspot (or just “hotspot” in this paper)—any source code location that may contain a SQL injection vulnerability [1, 2].  

Error message information leak vulnerabilities. These vulnerabilities occur when an application does not correctly handle exceptional conditions and subsequently leaks sensitive information to a user [4, 5]. This information can be obviously dangerous in the case of error messages that contain system or application passwords, or it may seem more benign, containing only version numbers or stack traces.  Unfortunately, even these seemingly benign error information leaks can provide valuable information to an attacker and could expose additional attack vectors.  Since a tester cannot tell what information an attacker needs to conduct future attacks, a good policy is to treat all error information leakage vulnerabilities as if they contain obviously dangerous information such as passwords.