Home > Development, Security > Making a Hash of Security

Making a Hash of Security

We recently had a situation in which we needed to be sure that a user was not able to meddle with the parameters in a specific URL. The process on each side is simple enough; when generating the URL:

  1. Build up the querystring values into a single string.
  2. Pass this string to a hashing function that adds a known (to us) salt, and returns the SHA-512 hash.
  3. Return the URL to the user with the original querystring values and an additional hash value.

And when the page is visited:

  1. Read the querystring, removing the hash and its associated value.
  2. Pass this string to the same hashing function as before, using the same salt.
  3. Compare the returned hash with the value passed in. If they differ, throw an immediate exception.

Unfortunately, this single situation brought up the following comment from the Security Moron:

“OWASP recommend that any direct object references (parameters such as IDs) are encrypted, whether they appear on the URL or in the POST parameters

Why aren’t we hashing all URLs by default? Surely it’s good practice not to expose what our data structures, variables etc.. are named?  I’m still not sure what the overhead is when building a system from scratch?”

These aren’t necessarily bad questions, but are driven by a lack of knowledge about how security works, and introduce elements of security theatre: processes that appear to add security, yet fail to improve it at all.

Encrypting Direct Object References

OWASP define a ‘direct object reference’ as occurring when:

“… a developer exposes a reference to an internal implementation object, such as a file, directory, or database key.”

However, they then go on to say:

“Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.”


As with everything – whether it’s programming or following up on academic references – always check the source to ensure that the original message hasn’t been corrupted. The SM’s version of what OWASP were recommending was inadvertently misleading, as the second part of their statement had been omitted.

See https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References for more information.

Hashing all URLs and the Overheads

As long as the access control check was in place, the system could be viewed as secure. What wasn’t being appreciated here were the overheads involved in ensuring that every URL in the entire system works this way, and the additional processing that the server is required to do alongside every single request it will make.

A simple example is a grid showing a list of all the clients an individual has access to, which could potentially be in the tens or hundreds depending upon the size of the dataset. Access control is required anyway to allow the list to be filtered correctly; adding hashing requires additional code to be written (to create the hashes when each row is created), and decreases performance.

“Surely it’s good practice not to expose what our data structures, variables etc.. are named”

Apache would disagree with you. As would WordPress, Wikipedia, Drupal, Silverstripe, Joomla, Request Tracker, … The simple answer is that hundreds of well-known projects have their complete source code available for anyone to download and analyse at their leisure. Hiding a data structure does not increase security.

In addition, it should be noted that it is quite possible for a skilled developer, aware of how your system works from the outside, to make guesses about its internal structure anyway. In a chat recently with developers for an insurance comparison website, I was asked how I thought it worked behind the scenes. When I finished a few minutes later, they looked at me and asked who I’d spoken to; the concept that someone external to the company could sit down and describe their precise design had never occurred to them before.

In summary …

“Obscuring your data” is not the same as “being secure”. Your software is secured by ensuring that only objects that the user has permission to access are available to them. If you need to hash or encrypt your URLs to guarantee security, then you are merely putting a sticking plaster over an insecure system.

Categories: Development, Security
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: