Injection is not always about SQL
February 7th, 20103
Injection is not always about SQL
February 7th, 20103

I think anybody even remotely involved with databases these days has seen the xkcd comic about Bobby Tables :

Basically, the comic warns against SQL injection, and reminds you to sanitize your database inputs rather than blindly append incoming data to queries. There are more elaborate discussions about this concept in these articles on MSDN, and of course your favorite search engine will have many results as well:

It is important to remember, though, that not all injection attacks are intended to screw up your database or gain unauthorized access to your data. Some vectors are a little more subtle, and while the damage isn't always as severe, it is still something you need to be aware of to prevent fraudulent activity or even just to keep egg off your face. I'll illustrate with two examples:

Letting customers dictate your pricing

I remember several years ago, I demonstrated to an online shop why they shouldn't add items to a shopping cart by passing (among other things) price information in the query string. I showed them how I was able to buy a bunch of T-shirts at $0.01 each, and encouraged them to verify whether my cart would have gone through like that. As it turned out, it would have. For pointing out this fundamental flaw, they added a free t-shirt to my order, and eliminated the shipping charge. I am curious how quickly they would have caught this – or if some folks even got away with it unnoticed – had I not pointed it out. I think it would be really hard to trace back and prove the buyer to be at fault.

Letting customers change your messaging

This morning, someone pointed out that Toyota Ireland had a similar flaw in a site used for their recent recall issues. Basically you could change their message to whatever you wanted to. Now arguably this doesn't really harm anyone (because you are only able to change messaging within your own session), except it was fun to get a screen shot of something like this before they fixed the exploit (remarkably quickly, I might add):


So just as a reminder, when you're accepting input from users, validate and sanitize! And when you're accepting input from your own site, make sure it really comes from your site – there is no reason to expose contextual information in the query string, as this just invites users to tinker. Unless you have a really good reason to use querystring parameters, protect your data and variables by passing them via post or session.

By: Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at Simple Talk, SQLPerformance, and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a husband, a father of two, a huge hockey and football fan, and my pronouns are he/him.

3 Responses

  1. AaronBertrand says:

    Simon, that's true I suppose, but I think it's a pretty edge case – you'd also have to send them a valid registration number, which means you'd probably have to send your own, unless you were a dealer with access to other valid codes.  But my point remains the same: you should never be coding a site where you blindly take user input and do stuff with it.

  2. K. Brian Kelley says:

    Nice! Toyota's page is susceptible to XSS.

  3. Simon Sabin says:

    It was very severe because you could include script code in the page. Someone could then send a perfectly valid looking link to toyota's site and execute some malicious code on the users machine. Not good.