As security consciousness rises, more developers are using security technologies to secure their applications, systems, and users from compromise by malicious agents. But, just because developers are using a security technology, does not mean they are using it correctly.
Take encryption, for example. The main reason to use encryption is to protect the confidentiality of the data that is being encrypted. If there is no real requirement to encrypt the data, then encryption should not be used because it can degrade performance and it complicates application design.
As an example of how encryption can be used poorly to provide a false sense of security, consider an application that has a user profile page accessible through a link similar to the following:
http://hackx/userprofile/user-profile.aspx?uid=ZauX%2f%2fBrHY8%3d
Check the uid value in the above URL, this parameter almost invariably represents “user IDs” and hold unique values related to various users in an application. Generally, these values are consecutive positive integers that map directly to the primary key values used in the database.
In the case of the above URL, the value is not an integer, but a complex string. Although it is not clear what this value might actually be, it’s possible that the value is base64-encoded due to the URL encoded %3d (=) at the end. Subsequent decoding of the value results in a seemingly random sequence of 8 bytes, indicating that the value is likely encrypted.
The key to attacking this functionality is to recognize that the same encryption scheme used for securing other objects in the system (such as unique product and category IDs) is also used for uid values. For example, if you assume that the value underlying the encrypted uid value is an integer that corresponds to the primary key of a user row in a backend database table, then it would make sense for other encrypted object IDs to also be primary key values in their respective tables.
That means that we might be able to use an encrypted product ID value as a uid value in a request to the application and gain access to the record for another user. To test whether such an attack will work, all that is needed is to get a number of encrypted product and category IDs and use those as the uid value in requests to the user profile page, user-profile.aspx. After some trial and error with this method, we hit pay dirt and succeed in accessing another user’s profile containing all his juicy personal details.