
In this post I want to focus on a common security flaw, the URL.
So let’s start with an example:
http://www.infosupport.com/getProduct.aspx?ProductID=123
Nothing wrong, a customer can manually change this URL to go to another page to view another product.
http://www.infosupport.com/getCustomer.aspx?CustomerID=456
Potentially wrong, because a customer can look into the account of another customer.
So for an anonymous sites with public information there is no problem, but whenever we have private information, we need to authorize the user, otherwise we run a very big risk in information disclosure.
Ways NOT to solve this:
- Move the CustomerID to a Cookie
- Move the CustomerID to a hidden field / Viewstate
- Obfuscate the URL with some random numbers
- Use a custom encryption mechanism
- Use logging/tracking to keep track of unauthorized requests
So how do we solve this problem? We need to apply authorization, so we can make sure that the current authenticated users have the right role to view the information. The best way to do this is to add authorization checks to your Business Layer, Data Access Layer or in the Database itself.
With the advance of the RIA applications (Ajax, Silverlight, Flex, Air) the need for this is even greater, the UI will do some role filtering, but we ALWAYS need to check this in our web services layer/backend systems! Also we could apply logging, but this will only help us after an attack to determine the information being disclosed.
The advantage of still using the URL with private information is that an authenticated user can still bookmark the page with the URL, the user can even forward the url to another person, who can only view the information when properly authorized. The URL isn’t the problem here, just an innocent victim of improper authorization.
During most security reviews I’ve done lately I found this flaw. Most of the time the site started out as a public site, and later authentication was added, together with the private data. So be aware of this for the future!
4 comments
Its that strange that you found it in multiple projects
Its listed in the top 25 http://cwe.mitre.org/top25/
Sans compares it with http://cwe.mitre.org/data/definitions/285.html;
Suppose you’re hosting a house party for a few close friends and their guests. You invite everyone into your living room, but while you’re catching up with one of your friends, one of the guests raids your fridge, peeks into your medicine cabinet, and ponders what you’ve hidden in the nightstand next to your bed.
Rolf Huisman
The vulnarability isn’t new, but the responses from most developers is what scared me the most. Most developers choose the easy way to fix this.
Most of the time this will be due to unsufficient funds/time and lack of security awareness. Fixing this afterwards is expensive so is sometimes left out. Also deadlines force developers to skip this, and the project management should make time afterwards to repare this.
Erik Oppedijk
It gets even worse: By moving the information to a hidden field, a cookie or what not you create new problems that require an even more complex solution. And that while the real solution to the problem is pretty simple to implement using some roles and a few settings 😉
willemm
En het is zeker geen theoretisch probleem. Heb je dit gelezen? http://www.nu.nl/internet/1944739/site-geschillencommissie-was-jarenlang-lek.html
frankg