In this post I want to focus on a common security flaw, the URL.
So let’s start with an example:
Nothing wrong, a customer can manually change this URL to go to another page to view another product.
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!