This post is prompted by an exchange with a client that develops and hosts web applications for customers. A recent automated vulnerability scan performed by the developers, on behalf of their client, revealed that a possible blind SQL injection point had been located in an aspx file. As clear as day, passing bad data caused an unhandled exception, which was visible in the browser due to custom error messages being enabled. The error message included a stack trace, the name of the database table used to authenticate users, the directory where the application was located, and the specific lines of code where the exception occurred.
Attempts by the client to exploit the injection point were not successful, so a heated discussion arose between the developers and the client. It did not center around how to fix the issue, but whether or not the named vulnerability actually existed. In this case, the text of the alert was "Possible Blind SQL injection", pointing to the aspx file and the variable used in the injection.
Now the discussion over the scan result is understandable: is it really SQLi or not? Can data be extracted from the table "tblUser" or not? I get this. But what about the bounty of data contained in the stack trace, confirming that bad data caused an exception? SQLi, RFI, XSS, XSRF -- who cares what it is called?!? The code, as written, faults when bad data is passed!
Apparently, this was not enough to convince the client that a code level fix was required. The solution? Disable custom errors. The result? No more vulnerability detected by the scanner.
Despite my best efforts, a "clean scan" was more important than bug-free code. I believe this mentality is caused by a growing "checkbox security" attitude which allows mediocrity to displace excellence. A "D-" is now acceptable because it's not an "F" -- "At least we passed!" This checkbox attitude lets stakeholders console each other with "We scanned the app according to PCI 6.6. No errors. CHECK!" Never mind the fact that we all know there's a bug, but we've disabled the error messages that allow the security tools to see it...
Security through obscurity at its finest.
Comments