Idea: Using System Level Testing for Revealing SQL Injection-Related Error Message Information Leaks: Difference between revisions
Jump to navigation
Jump to search
Programsam (talk | contribs) |
Programsam (talk | contribs) |
||
| Line 151: | Line 151: | ||
|} | |} | ||
</center> | </center> | ||
We found that unit testing could have identified none of the 17 confirmed vulnerabilities; rather, these confirmed vulnerabilities are system level vulnerabilities that had to involve the application server. A missing exception handler for pages or Servlets within Apache Tomcat caused each of the vulnerabilities we discovered. The example presented in Table 3 and Table 4 helps illustrate why these vulnerabilities cannot be exposed at the unit level. | |||
Table 3 presents the relevant code from one of the confirmed vulnerabilities that we found in iTrust, in the file <code>editHCPs.jsp</code>. In other pages within iTrust, there is a JSP directive declared at the top of the page’s code (along with various navigational toolbars and headers) that declares an exception handler: | |||
<%@page errorPage="/auth/exceptionHandler.jsp"%> | |||
This directive does not appear in editHCPs.jsp (see Table 3). At the moment an exception is thrown, Apache Tomcat forwards the user to the page declared in this directive, if this directive is declared. Otherwise, Apache Tomcat outputs a revealing stack trace to the user’s browser window, also known as an error message information leakage. | |||
Since the omission of an exception handler is something that happens in the JSP code and not the Java code, some form of interaction is required with the application server (Apache Tomcat) in order to expose the vulnerabilities. One may view each JSP as a unit, but still the exception handler is a JSP page directive that involves a separate page; the unit therefore cannot be tested in isolation. The confirmed | |||
== 7. References == | == 7. References == | ||