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

← Older edit Newer edit →

@@ Line 52: / Line 52: @@
 # '''Execute Original Unit Tests'''. After instrumenting each subject to mark its executed SQL hotspots, we executed the intrinsic unit tests and recorded the resultant number of executed statements.
 # '''Create Test Cases'''. We used the stored file name and line number of the hotspot from Step 1 to construct an automated system level test with HtmlUnit<sup>14</sup> that executed the SQL statement located at the stored file name and line number. We constructed an initial automated test for each hotspot by using a call hierarchy and manual testing to make web requests until the hotspot was marked as being executed and then modeled our automated test after the use case we discovered<sup>15</sup>.
-# '''Apply Malicious Input'''. We modified the test defined in Step 4 to emulate a malicious user by using 132 forms of malicious input in an attack list from NeuroFuzz<sup>10</sup> in place of normal input. This part of the procedure is similar to “fuzzing”. The difference here is that fuzzing is a semi-random, black box activity; our approach is targeted to specifically attack the areas where user input might reach a hotspot.
+# '''Apply Malicious Input'''. We modified the test defined in Step 4 to emulate a malicious user by using 132 forms of malicious input in an attack list from NeuroFuzz<sup>16</sup> in place of normal input. This part of the procedure is similar to “fuzzing”. The difference here is that fuzzing is a semi-random, black box activity; our approach is targeted to specifically attack the areas where user input might reach a hotspot.
 # '''Record Result'''. We then marked each test that caused incorrect SQL operations or an application error in Step 5 as a successful attack and its corresponding SQL statement as a vulnerability.