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

Jump to navigation Jump to search
← Older editNewer edit →
Line 161: Line 161:


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 vulnerabilities, then, are caused by a system level error: the absence of an exception handler in the JSP or Servlet code of the application. Consider a JUnit test case that is written to execute <code>undeclareHCP</code> (see Table 4). This JUnit test case would pass, but would not expose the vulnerability even if it uses the some malicious input, such as <code>‘ UNION SELECT</code>. However, an HtmlUnit test case that targets <code>editHCPs.jsp</code> (see Table 3), produced by our system level testing technique, would expose the vulnerability using the same attack. That is, the vulnerability is not that an exception is thrown, but rather that the exception is not correctly handled by the JSP.
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 vulnerabilities, then, are caused by a system level error: the absence of an exception handler in the JSP or Servlet code of the application. Consider a JUnit test case that is written to execute <code>undeclareHCP</code> (see Table 4). This JUnit test case would pass, but would not expose the vulnerability even if it uses the some malicious input, such as <code>‘ UNION SELECT</code>. However, an HtmlUnit test case that targets <code>editHCPs.jsp</code> (see Table 3), produced by our system level testing technique, would expose the vulnerability using the same attack. That is, the vulnerability is not that an exception is thrown, but rather that the exception is not correctly handled by the JSP.
<center>'''Table 3. JSP for Example Vulnerability (editHCPs.jsp)'''
  DeclareHCPAction action = // Action class for declaring the HCP.
  String confirm = ""; // used to store the result from the DAO.
  String removeHCP = request.getParameter("removeID");
  if(removeHCP!=null && !removeHCP.equals("")){
  confirm = action.undeclareHCP(removeHCP);
  }
  List<PersonnelBean> hcps = action.getDeclaredHCPS();
</center>
<center>'''Table 4. Java Method undeclareHCP'''
  //given: patientDAO, a DAO pertaining to the patients table
  //given: iTrustException, a custom-build Exception class for
  // handling alternate flow errors
  public String undeclareHCP(String input) throws iTrustException {
  try {
  long hcpID = Long.valueOf(input);
  boolean confirm = patientDAO.undeclareHCP(loggedInMID, hcpID);
  if (confirm) {
  return "HCP successfully undeclared";
  } else
  return "HCP not undeclared";
  } catch (NumberFormatException e) {
  throw new iTrustException("HCP's MID not a number");
  } catch (DBException e) {
  throw new iTrustException(e.getMessage());
  }
  }
</center>


== 7. References ==
== 7. References ==
Retrieved from "https://bw.kn1.us/wiki/index.php?title=Idea:_Using_System_Level_Testing_for_Revealing_SQL_Injection-Related_Error_Message_Information_Leaks"