The Querystring: Soft Target

Gentle reader, I want to let you in on a little soft underbelly your Web sites and Web applications might have. The querystring.

As you might know, gentle reader, the querystring is that junk in the Address bar of the Web application. It includes the URL/pagename of the page your user is accessing, but it also can include parameter/value pairs that server-side applications process. That is, it’s a way that your developers can ignore inserting error-catching logic and show the world the stack traces they’re so proud of.

Here’s the basic anatomy of the querystring:

protocol: domain: page: separator: parameter: equals: value:
http:// www.site.com/ page.aspx ? pid = 4

This particular querystring uses server-side scripting using ASP.NET (aspx as the page extension gives this away). It also shows that the application will accept at least two parameters, pid and sec, and it will attempt to process values you pass in the querystring. Of course, the application should check the validity of the values passed into the page, but because the developers are too busy refreshing Calico Monkey over and over to see if the new episode is finally up, they don’t have time.

To really make your developers’ inattentiveness shine, you should apply all the normal boundary analysis sorts of mean things to the parameters on the querystring as you would to any control or edit box on the pages themselves:

  • If the value appears to be a number, replace it with letters.
  • Try to put as many characters/numbers into the value as you can; if it’s currently 49, change that to 7435378347425675432676790676767674676.
  • Try to access the page without a value specified. That is, remove the value from the querystring and send that to the Web server.

You’ll find, as I mentioned, that many times the developers just trust the querystring to have valid information on it. When you log your defects with the pretty, pretty screenshots of stack trace after stack trace with Input string was not in a correct format and Microsoft VBScript runtime error '800a0006' kinds of errors, your developers will no doubt try to put you off with the standard, “Only QA would do that” sorts of responses.

Sure, circumstances never would occur where another site/application would have to pass values to your application like that. Say, a banner ad or e-mail campaign or integration with a third party widget somewhere in the ether. Oh, no, Mr. Developer, only QA thinks that the application should be constrained to behave correctly in all circumstances, not that it should behave correctly in correct circumstances. But then again, who listens to QA?

Comments are closed.


wordpress visitors