For those we lost, We will not forget 09/11/2001 “Our God given unalienable rights are given to us all as individuals. They tell us what me may do for ourselves, and they are the embodiment of liberty. The so-called rights that government gives to some of us are parcelled out to select groups as classes. They tell us what one class of people may require another to do for them, and they are the very essence of slavery.”
— Perri Nelson, February 9, 2010

A bheil Gàidhlig agaibh?

It’s not collagen


Published Thu, Nov 12 2009 11:52 AM
Technorati Tags: Computers and Internet, Software Development, Annoyances

I use a URL rewriter library to set up my permalink URLs. I did this for a couple of reasons. The primary reason is that it allows me to provide you with a simple way to get to my archive. For example, the URL for this post should be http://perrinelson.com/2009/11/12/1392.aspx. The format is obvious – the path consists of the year, month, and day of the post, followed by the post ID. This together with the way the URL rewriter library lets you hack off the end of the post URL and get an archive of posts.

For example, the URL http://perrinelson.com/2009/11/12 would present you with a list of all of the posts that I made today. The URL http://perrinelson.com/2009/11 would present you with a list of all of the posts that I made this November – grouped by day, and the URL http://perrinelson.com/2009 would present you with a list of months, and the number of posts I made each month.

Another reason is that URLs of this form are (or were) more search engine friendly. A URL like http://perrinelson.com/viewpost.aspx?postid=1392 is only distinguished from another post URL by a querystring parameter. This tells the search engine that the content is dynamic rather than static – and at one time dynamic content wasn’t indexed by some search engines. At least, that’s the way I recall it – whether correctly or not.

There’s still another reason for doing this. Exposing a URL like http://perrinelson.com/viewpost.aspx?postid=1392 is an open invitation to hackers to attack my site using SQL injection. I’m not particularly worried about that problem though – I’ve taken other steps to prevent SQL injection attacks from working on my site.

Just a few minutes ago my site sent me e-mail. I set it up to do this whenever certain events take place – typically events due to a programming error on my part. There’s one programming error that I made a long time ago and have never bothered to fix. It involves the parsing of the post ID.

You see, I use a SQL database to store metadata about my posts. The actual posts are stored in an HTML document that is stored in the file system on the server. I have much more available file system space than SQL data storage, so it makes sense to do this this way. Anyway, the metadata rows have a field that identifies the post – the post ID, which is generated by the database engine. This ID is an integer value (like 1392 for this post) and so I treat it as a number and not a character string. To do this, I have to convert the character string to an integer data type, and I neglected to put an exception handler around the parsing of the number. If the postid querystring parameter contains anything but digits the parser throws an exception and I get e-mail telling me that I made a bone-headed programming error.

It’s an easy enough error to fix, but I have no plans to fix it. I’m entertained by the things that people put in the querystring when they’re trying to hack my site. In July of 2008 I posted an analysis of one hack attempt that was truly imaginative. That one used a combination of SQL injection to try to insert code into every text column in my database (it failed) that ran a foreign piece of javascript that inserted a tracking cookie onto the client’s machine and inserted an IFRAME element into the page. The document that would have been loaded into the IFRAME exploited a buffer overrun bug in Internet Explorer (since fixed) to install malware on the client’s machine.

Interestingly enough, several major websites, including a few British financial institution websites were compromised by that particular attack. In contrast, today’s attack is much less imaginative. Here’s what they tried putting in the postid querystring parameter.

postid=270'%20And%20char(124)%2b(Select%20Cast(Count(1)%20as%20
varchar(8000))%2Bchar(124)%20From%20[sysobjects]%20Where%20
1=1)>0%20and%20''='

Some of this is simply URL encoded character substitution. For example “%20” represents a space character and “%2b” is the “+” character. While we’re dealing with character subsitution, we can also get the “char(124)” out of the way too. That expression evaluates to the vertical bar character. Doing the substitution gives us…

postid=270' And '|'+(Select Cast(Count(1) as varchar(8000))+'|' From [sysobjects] Where 1=1)>0 and ''='

This isn’t even good SQL!  At least it’s not good TSQL. An expression like “|554|>0”  might be acceptable in some other variants of SQL such as MYSQL – it’s been a while since I actually coded for those variants, but an expression like “|554|” can’t be converted to an integer value in TSQL, so SQL Server would throw an error with this code. I can only conclude that these attempts were a probe to see whether SQL injection even had a chance at success on my site – and if they had been successful I’d be subject to still more attacks.

SQL injection is such a tired old hacking technique – I’m surprised that anyone still tries it – or that anyone is still victimized by it. Still, I guess there are some out there that want to compromise other people’s systems for any number of reasons, not the least of which is watching the world burn.

In these days when malware is proliferating through so many different channels it pays to err on the side of caution whenever you receive a suspicious piece of e-mail, or visit a web site you aren’t familiar with. In fact, you should err on the side of caution even with web sites you are familiar with. Who knows what some malicious hacker has managed to get away with?

Oh, and if you write code for web sites, please, please, please make sure that you learn how to mitigate the risks associated with SQL injection and other types of hacking attempts. It ought to be obvious by now that you’re putting your customers at risk if you don’t.


Trackback URI for this post: http://perrinelson.com/track.aspx?postid=1392
Permalink URI for this post: http://perrinelson.com/2009/11/12/1392.aspx


Subscribe to this entry's comment feed. (Atom)

David responded with:

Gravatar
Some things to give more thought to...

And, "Still, I guess there are some out there that want to compromise other people’s systems for any number of reasons, not the least of which is watching the world burn," is spot on for many juvenile-minded (no matter what age) black hatters.

Delicious Bookmark this on Delicious 

Comments to this entry are closed.

View Perri Nelson's profile on LinkedIn I'm a proud friend of Israel! Are you? Republican National Committee