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

Jump to navigation Jump to search
Line 47: Line 47:


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.  
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.  
<center>
'''Table 1. Information about the test subjects (n=4)'''
|-
| '''Projects'''
| '''iTrust'''
| '''Hispacta'''
| '''LogicServices'''
| '''TuduLists'''
|-


# '''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.
# '''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.