Querystring manipulation attack is one of the most common methods of attacking a vulnerable web site. Basically it involves changing querystring passed to webpage. Let me show this with an example:

Lets say you have a page on your site to search orders. In search results the OrderID has as a hyperlink pointing to a page ShowOrderDetails.aspx?id=XYZ, where XYZ is the actual orderid (eg. ShowOrderDetails.aspx?id=34).

A user can visit the ShowOrderDetails.aspx page and change the ID value and see any order. This is could be a problem if your site requires a login and not all users are allowed to see all orders. Even if all users are allowed to see all orders, this could still cause problems. Someone can easily write a program to loop through all orders and scrape all the data. This could be a risk based on the sensitivity of the data.

To solve this, you can simply check if a user is “logged in” in ShowOrderDetails.aspx page and avoid unauthorized access. But it will still allow any registered/valid user to see all orders, which may not be desirable.

An easy way to fix this is to encrypt the ID that’s passed in the query string (eg. ShowOrderDetails.aspx?id=XyS3frfasYFx). You should use a strong encrytion algorithm like DES or TrippleDes. The framework library has classes for most standard encryption algorithms.

Now that you’ve encrypted the ID in the querystring, you’d assume your application to be pretty secure. But, there’s still one way to see unauthorized orders: Browser history. The querystring is stored in browser history, so technically you can see all orders someone else has seen if the brower history is available. This defeats the encrypted query string.

One way to prevent this problem is to either use/include the sessionId (or userid) as a part of the key that’s used to encrypt/decrypt orderid. This would give a different encrypted string for the each session/user. Even if a different user click a link in the history, his sessionid/userid will be different, hence decryption will fail.

Notes:

1) The session is active until expiry or browser window closure, so technically, you’re still at risk if the user doesn’t log off from your site and leaves the browser window open (even if he has closed the tab that had your site open).

2) Some people suggest using HTTP_REFERER to prevent querystring manipulation. But its very easy to break since http headers as sent in plaintext over network. Also you can simply use the WebBroswer control in a .NET WinForms application to change the href of any link and hit the link. This defeats the HTTP_REFERER check.

3) Query string manipulation attack is not restricted to GET. POST method is also vulnerable since the information is sent in plain text over the network.