Hey everyone, Kevin here. I took our assessment product prototype out for a spin the other day, and it detected a fairly interesting SQL injection vulnerabilty on an extremely popular Web site (Alexa top 100 in the United States at least). The SQL injection vulnerabilty revealed itself in a HTTP 500 error response, similar to the following (site directory and affected file name have been changed):
— START —
<font face=”Arial” size=2>
<p>Microsoft OLE DB Provider for SQL Server</font> <font face=”Arial” size=2>error ’80040e21′</font>
<p>
<font face=”Arial” size=2>Invalid character value for cast specification.</font>
<p>
<font face=”Arial” size=2>/sitedir/file.asp</font><font face=”Arial” size=2>, line 31</font>
— END —
A couple interesting points regarding this particular vulnerability:
- Applications using mshtml.dll won’t be able to detect this. Since the SQL error was buried inside a 500 HTTP error response, if you’re using Internet Explorer (i.e., you’re a security consultant) or a scanning tool built on top of mshtml.dll (most, if not all) you won’t see this error response. Mshtml.dll will serve up a generic error message and evidence of this vulnerability will be essentially masked.
- The error message is spread across formatting HTML tags. This is the most interesting aspect of this issue. If your tool is looking for specific SQL error messages such as, then the more interspersed the message is in between HTML tags, the more unlikely your tool will be able to detect the SQL error message.
Our tool was able to detect this instance primarily because of the way our patent pending scanning engine was designed, but if say every other word (or worse every other letter) was interspersed between HTML tags, even I would start having doubts on our tool and every other tool. To detect vulnerabilities like this would require something more innovative than just string searches. Anyhow, a little food for thought.
–Kevin
