I take form input all over my site, and use query parameters to sanitize data. When an invalid data type is passed, a simple (not detailed) notice is thrown and I receive an email with what was passed.

It appears that in this automated attack, one of the dropdown boxes is reinjected into one of the fields and iterated through. What's the objective of this, and how can I make sure it doesn't work?

Here's some sample errors (edited down):

Invalid data Choose Calendars for CFSQLTYPE CF_SQL_INTEGER.
Invalid data -------------------------------- for CFSQLTYPE CF_SQL_INTEGER.
{20 more with every single option}

Edit: going to try to explain a little better, bear with me! Here's the HTML:

<option value="0">Choose Calendars </option>
<option value="0">--------------------------------</option>
<option value="0">Select multiple calendars...</option>
<option value="0">--------------------------------</option>
<option value="0">Select a calendar from this list...</option>
<option value="1">Options 1-30</option>

(Rinse and repeat)

When a value is selected, it is added to the URL (GET) and submitted - the attack seems to be taking all of the options as an array and putting them into the GET request to try to compromise the SQL. I hope that makes sense?

  • I am having a little bit problem understanding what is happening. Can you also include HTML code example maybe?
    – Chris Dale
    Jul 25, 2011 at 16:22
  • @Karrax sorry about that, added a little more. Hope that helps.
    – Nic
    Jul 25, 2011 at 16:37

1 Answer 1


It seems like this may just be probing for vulnerabilities, error messages, difference/changes in response size and result.

For example by providing all the different values to your backend system may provide the end user with for example:

  • Maybe looking for information disclosure. A too verbose error message. It may reveal datatypes, names of columns and what not.
  • Unintended use of the script. For example exploiting logic flaws in your script by say trigging multiple IF statements or something similar.

The attacker may be looking at the result coming back to see if any drastic changes has happened to the webpage or size of the result (in kilobytes). Often when doing very many requests against one page it is easiest to distinguish changes based on the result size. If any of the GET parameters has triggered something the developer did not think about, the mission may be successfull for the attack.

I am sorry I could not provide a definite explanation on what this attack may be all about, but this is what I think it is.

  • 1. Thanks for the comment on my work, I really appreciate it! 2. I agree, I think it is a probe, and I think I have the obvious things covered, so hopefully it won't come back to bite me. I think I'll create a whitelist sometime in the future for even more security.
    – Nic
    Jul 25, 2011 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .