May 26, 2010

Being manipulative as a software tester: how to try negative-testing web apps through their URLs

This is an *actual* URL from Vignette:

I'm sure that behind those obscure-looking alpha-numeric strings there's a rhyme or reason (hopefully?), but that's not really what I wanted to blog about today :-)

What I did in fact hope to convey today is how to try "breaking" (for various definitions of "breaking") web applications' internal logic (or output) by manipulating their URLs.

Spurred on by our resident web-applications-security guru, Michael Coates, I've been applying some really simple approaches. I'll walk you through just four of them, here (not picking on SUMO, I swear!)

1. Add/remove delimiters/trailing slashes:

Let's take a URL like as an example. Obviously, we make sure that and both return a valid homepage (that's almost a given, but you never know).

The more-interesting test is to add junk after the first trailing slash (which we now know to work), like so: Currently, when you do that on our new version of SUMO, you redirect to http://en-us/forums

Filed bug 566106.

2. Put Unicode/non-ASCII text where it wasn't originally intended:

Prior to a fix, SUMO didn't know what to do with Unicode as a value in its "&tags=" parameter:

Paul Craciunoui found and filed bug 564385.

3. Input non-expected/invalid values for parameters:*Finding+your+Firefox

The above is a long URL, but if you notice, the second parameter is "a=a". The original problem was that SUMO was expecting the value of "a=" to be an integer. So, of course, I fed it an alphabetical character, "a".

The result of which can be seen in bug 565857.

4. Try changing the locale code:

If your web app likes its URLs in a certain format, such as "en-US", try simply omitting the "-US", or "US", leaving, respectively, "en" and "en-".

As a real-world example, both the former, and the latter, redirect us to, which is graceful.

These are, of course, just four really simple examples, but they highlight how quickly and easily testers can begin to help ensure your app won't crash/hang/do something evil with bad data; there are a myriad of other ways, and the URLs in the location bar aren't the only target: try using a add-ons, such as Tamper Data, or Live HTTP Headers (which I've already blogged about for its primary use), to change sent values (on GETs/POSTs, etc.), especially when submitting forms.

Once you know how to manipulate _one_ parameter (irregardless of if you know the expected value, or, maybe in spite of that), you can find some gems.

Feel free to get pathological, too, just be mindful that some constructs are just too heinous for words, and a developer is likely to cast you the stink eye if it's too wild.

Posted by stephend at May 26, 2010 8:51 PM
Post a comment