So why in the world would you want to do XSSing via SQLinjection instead of just doing it the normal way?

The reason for this is that if there’s an application firewall, client side scripting controls, or Asp.net validation then sending a script via website to the server in order for it to be reflected will be denied because of those controls in place. However if the script were to come from the server itself (via SQL), then it would be reflected and bypassing those controls.

In Mutillidae, on the User Lookup page, is vulnerable to a UNION SQL injection.

Columns 2, 3, & 4 are reflected onto the page. If we take a very basic script such as

<.script>alert(HACKED)<./script>      (no periods, they're just there so I don't XSS my own site)

and input it into the second NULL parameter in the query, it won’t work because you can’t just inject the script, you have to write a SQL query that generates the script. To do this, we’ll have to play around with ASCII values.

Passing in “A” instead of a “1” in the UNION SQL statement with throw a Syntax error because SQL takes the A and thinks it’s a column, which of course doesn’t exist. So to get around this, letters are represented with ASCII values with the: char() function.

Example:
Passing in char(65) which is the ASCII Char value for “A” (here’s a link to a table) correctly places A in the right column.

Now we have to make a script out of Char values. This can get tedious but luckily there’s a Firefox addon called Hackvar that does this for you.

Putting in my script then converting to to SQL Char, gives us the string we need.

Pasting that in place of the second null parameter in the query statement successfully injects the script via SQL.