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

← Older edit Newer edit →

@@ Line 39: / Line 39: @@
 In this section, we present information about our case study. Each part of the case study was conducted using Eclipse v3.3 Europa executed using Java v1.6 running on an IBM Lenovo T61p running Windows Vista Ultimate with a 2.40Ghz Intel Core Duo processor and 2GB of RAM. We used MySQL v5.0.45-community-nt for our research database management system<sup>9</sup>.
+To obtain our case study applications, we collected information about 12 enterprise Java web applications, which we found by searching SourceForge<sup>11</sup> with the query “Java web application,” and sampling the first 12 projects that contained the Eclipse webtools<sup>12</sup> project file structure. We then rejected eight subjects from our study because they did not meet one or many of the following criteria:
+* Could be compiled, built, and deployed.
+* Contained automated unit tests, written in JUnit, which were distributed with the source code.
+* Relied upon a relational DBMS to store its data.
+We were left with the four subjects presented in Table 1. In an attempt to reveal both SQL injection and error message information leak vulnerabilities in our test subjects, as stated in Section 1, we created the following systematic, system level, security testing procedure and executed it on our subjects. By design, this procedure produces an automated system level test suite that executes all reachable hotspots with normal and malicious input. We note here that by intrinsic, we mean that we did not augment or modify the existing test set in any way; values for these measures were achieved by the unit tests that were distributed with each system.
+\# '''Identify and Instrument Hotspots'''. We manually inspected the source code to discover any point where the system interacts with the database. We note here that hotspots can take many forms; we explain this issue more below. We have written the Java program <code>SQLMarker</code>, introduced in our earlier work<sup>[9]</sup>. <code>SQLMarker</code> keeps a record of the execution state at runtime for each uniquely identified hotspot<sup>13</sup>. <code>SQLMarker</code> has a method, <code>SQLMarker.mark()></code>, which passes the line number and file name to a research database that stores whether the hotspot has been executed.
 == 7. References ==