Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 899
  • Last Modified:

Security Metrics SQL Injection Vulnerability Error, But I Can't Duplicate It?


I am an Classic ASP programmer and I started a new ecommerce site on a Windows Enterprise Server 2003 using a mySQL Server on Fedora...  and I am required to get PCI Compliance with

My scan has failed 5 times, and with tweaking, I still cannot duplicate (with POST or GET) in any web browser to reproduce their errors.   I am familiar with escaping single quotes and SQL injection commands and have functions for the data retrieval.

Description: SQL injection vulnerability in emailaddress parameter to  /signup.asp
Severity: Critical Problem Impact: A remote attacker could execute SQL commands
on the back-end database, possibly leading to password retrieval, authentication
bypass, unauthorized data access, or unauthorized data modification.
Background: Structured Query Language (SQL) is the most common language
understood by modern relational databases. It is made up of queries. A typical
query reads: SELECT * FROM table WHERE condition where table is a table
belonging to a relational database, and condition is a logic condition which is
either true or false for each row of the table.  The query would return any or all
rows for which the condition is true.  Resolution All user-supplied parameters
should be checked for illegal characters, such as a single quote ('), before being
used in an SQL query.
See the references below for fix information for specific products.
Vulnerability Details: Service: 80:TCP SENT: POST  /signup.asp
HTTP/1.0 Host:
User-Agent: Mozilla/4.0
Content-length: 245
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive firstname=default&lastname=default&emailaddress='&username=default&password=default&passwordverify=default&referurl=%3Cscript%3Eal ert%28%27SAINT2To%27%29%3C%2Fscript%3E  RECEIVED: error in your SQL syntax

The weirdest part about the vulnerabilities is that they ONLY appear on my signup page (POST) on ALL the input variables, EVEN if the variable isn't even used in any SQL query???

I called them and they claim that they're test logs into a Linux Terminal to post to my page and that they get errors... not telling me anything specific on the error or how I can create the same environment so that I may see what they are talking about.

I am not familiar with Terminal Services, Telnet, SSH, etc... SO, can someone tell me HOW to recreate what they are seeing?  I did a little research and downloaded Putty, but not sure how to use it or even sure if it's what I needed.

I just need a quick course on what to download, how to prepare the POST to my web page via Port 80 with my post data (like they did) so I can see if there is some error or not, because at this point, I can't create any MySQL errors on my end with what they are claiming.

This is so frustrating.... please help.


  • 2
1 Solution
You need to find out what they're actually looking for in the response that makes the scanning software think there's a sql injection.

Something I would suggest trying is use firefox and get the addon tamper data. Once you get that addon go to your page and click start tampering and click the submit button. From there you can directly inject whatever you want into the post ignoring any javascript or form field length restrictions.

The line: "Resolution All user-supplied parameters
should be checked for illegal characters, such as a single quote ('), before being
used in an SQL query." makes me doubt this scanning software because it appears to me that it thinks if you allow an apostrophe you're vulnerable. As long as your query is properly parameterized it's not sql injectable.
Steve BinkCommented:
If they are failing your server, they have the burden to show what vulnerability their scan manipulates.  However, the vulnerability report does show the "environment" they are using to discover the issue.  The POST information, once decoded, looks like this:

firstname=default&lastname=default&emailaddress='&username=default&password=default&passwordverify=default&referurl=<script>al ert('SAINT2To')</script>

From the other headers, it is clear they are posting to /signup.asp through normal HTTP.  Using crisco96's method (the Tamper Data add-on...a good tool), you should be able to duplicate the error rather easily.  

To describe what it happening, let's take a closer look at the data.  The strategy looks fairly basic, and has two parts.  First is the single-quote on email address.  When put into an SQL query, this will cause a syntax error at best.  In a real-world attack, the email address field would be engineered to close a quote, finish the "real" query without triggering a syntax error, and follow it up with a data exposure or escalation attack through your database engine.  This is a basic injection strategy, and the fact that the POST returns an SQL error shows that you are not escaping data properly.

The second part is the referurl field.  This test is usually to see if POST variables are inserted back into a response unmodified/escaped/entity-ized.  If the referurl makes it back to the response, the user will receive a javascript alert box stating "SAINT2To".

While crisco96 does have a point as far as "properly parameterized" queries, that particular statement does not cast doubt on the scanning engine.  The scanning companies are well aware of standard practices, proper practices, and what actually happens in the real world.  As programmers, we tend to take shortcuts if we're in a hurry, and it is a very simple thing to write out a query quickly to get the job done.  There's nothing wrong with that, per se, but you do have to make sure all input is scrubbed and safe'd before pushing anything to your database.  In the real world, my own maxim of "Trust Nothing" serves me well.  I make sure every piece of data entering my application is escaped or entitied before it goes anywhere.

I'm not sure of the ASP methods of accomplishing this, but it is pretty simple in PHP: (be sure to visit the "See Also" links at the bottom as well)

Escape *EVERYTHING*.  No exceptions.  Even if you're in a hurry.
BenBlingBucksAuthor Commented:
Installed cURL, I ran a POST:

noc# curl -d "firstname=default&lastname=default&emailaddress='&username=default&password=default&passwordverify=default&referurl=%3Cscript%3Ealert%28%27SAINT2To%27%29%3C%2Fscript%3E"

No SQL error, nothing, just my standard redirect for any injection attempt, here's the results:
<head><title>Object moved</title></head>
  <body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body>

So, now I'm like scratching my head still wondering what is it that they see.

I ran another scan, it came back CLEAR and COMPLIANT.   Now I'm like "what's up with that?"

I made no changes, did nothing.   All that frustration for nothing.  I hope this never comes up again because if it does, I'm using another company.

Thanks for the advices people.

BenBlingBucksAuthor Commented:
I simply needed to know how to install a terminal client in windows to run the same post like the scanner.  I am familiar with everything else like I stated in the initial help request.  I figured it out myself.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now