Unfortunately, I too have seen this before in web assessments. I
highlighted an SQL Injection example of this problem in my book
"Preventing Web Attacks with Apache." This is from the "Mitigating
the WASC Threat Classification with Apache" chapter -
http://www.awprofessional.com/articles/article.asp?p=442984&seqNum=7
and shows the same problem where the web appliction is executing the
HTTP request before validating the user's session data.
Real-Life SQL Error Message Disclosure
I was contracted in May of 2005 to do a web assessment for a power
company's customer portal web site. In order to track the user's
identity, the application used two cookie values:
Customer_number—the user's account number with the company.
Identification_hash—a hashed value of an authenticated user.
During the assessment, I found numerous security vulnerabilities with
how their back-end database and PHP web pages validated the user
credentials in the cookie values and presented data back to the
client. For instance, when submitting a request to view my current
bill statement, I removed the cookie values from my request and the
application responded with this SQL error message:
======================================================
HTTP/1.1 302 Found
Date: Sat, 21 May 2005 12:58:40 GMT
Server: Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7g
Location: /login.php?refering_php=/bill/currentbill.php
Connection: close
Content-Type: text/html
<HTML>
<!--displaybill.php-->
<BR> Error in selecting SELECT max(billdate) FROM billing where
custnumber = <BR>
<BR> error: 1064 You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near '' at line 1 <BR>
<!--formbill_1.php-->
There are two important things to notice here:
The HTTP Response Code was a 302 Found and included a Location header
that is supposed to tell the browser to go to the specified page. In
looking at the Location header, it appears that the application is
instructing the browser to take the user back to the login page while
showing where the client came from. The problem is that the web
application has already processed the request and is providing the
data in the payload of the request. It is just asking that the browser
not show this information. This is an extremely poor method for
protecting against information disclosure attacks as it relies on the
security of the client's browser to send the client to the correct
location and to not show them the payload of the request. As you can
see in the response output, all I had to do to view this data was to
run a sniffer and intercept this data.
The HTML at the bottom of the response shows the MySQL error messages.
This data may help an attacker to better plan an attack as it
discloses the database table format in the "SELECT max(billdate) FROM
billing where custnumber =" line.
These types of verbose error messages should not be sent to clients.
--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor: Securing Apache
GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
-------------------------------------------------------------------------
Sponsored by: Watchfire
Watchfire named worldwide market share leader in web application security
assessment by leading market research firm. Watchfire's AppScan is the
industry's first and leading web application security testing suite, and
the only solution to provide comprehensive remediation tasks at every
level of the application. See for yourself.
Download a Free Trial of AppScan 6.0 today!
https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007t9c
--------------------------------------------------------------------------
