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

Line 193: Line 193:
   }  
   }  
   }
   }
== 5. Limitations ==
Future case studies should examine much larger web applications than the ones in this study. In addition, the selective criteria as described in Section 3 could have biased the data. For example, perhaps the fact that all of our test subjects were Tomcat Servlet applications caused or prevented some security vulnerabilities that would not have been observable in another architectural setup. In addition, if stored procedures had been used in any of our test subjects, our results may have been different. The development teams for each project may have been using other testing techniques to improve the security posture of our subjects, or security may not have been high on their list of requirements.
The container for the applications (in this case, Apache Tomcat) could also be emulated using a Mock Object pattern<sup>[13]</sup>, and each individual servlet or JSP could be tested in isolation from one another. However, the quality of the testing results is entirely dependent on the quality of the mock object’s ability to emulate the server<sup>[13]</sup>; additionally, mock objects may not be any less expensive than system testing. Prepared statements, which separate the user’s input from the structure of the query at the application level<sup>[14]</sup>, protected the applications in this study. However, prepared statements are only useful if developers are aware of them and choose to use them. Our own system level procedure may not have exposed all vulnerabilities latent in the four subjects. Our procedure was targeted towards SQL injection vulnerabilities, which did not exist in these sampled applications at the locations of the hotspots we identified, but other vulnerabilities of varying types may exist in our subjects.


== 7. References ==
== 7. References ==