How can I prevent my HTML from being used while avoiding the GUID?

Question

I recently inherited an ASP.NET MVC 4 database. One of the problems I noted was the use of some database identifiers (ints) in URLs, as well as in HTML form submissions. The code in its current state can be used both for URL search and for creating custom HTML messages with different numbers.

Now that I can easily fix problems with URLs using session state or additional authentication, I'm less sure about the database identifiers that are embedded in the HTML code that the site pulls out (i.e. I give them a drop-down list option fill). When identifiers are returned in a message, how can I be sure that I will put them there as valid options? What is considered “best practice” to solve this problem?

While I appreciate that I could just “DIRECT it”. I hesitate to do this because I find them a pain in the ass to work when debugging databases.

Do I have a choice here? Should I have a GUID to prevent easy guessing of identifiers, or is there some DRY mechanism that I can use to check if identifiers are used when they return to the site?

UPDATE: A commenter asked about the exploits I am expecting. Suppose I spit out an HTML form with a drop-down list of all the places from which you can import a "treasure". The identifier of the locations owned by the user is 1.2 and 3, they are presented in HTML. But the user learns html, scripts with him and decides to build a POST with an identifier of 4 selected. 4 is not his location, his alien.

Answer 1

Confirm the identifier passed with identifiers that the user can change.

This may seem tedious, but it is really the only way to make sure that the user has access to what they are trying to change. Using a GUID without verification is the security of obscurity: the certainty that it is difficult to guess them, but you can guess that they have enough resources.

You can do this at the top of the controller before you do anything else with published data. If there is a violation, just throw an exception and handle your global exception handler; you don’t need to handle it beautifully, as you can safely assume that the user is faking the data in an unsupported manner.

Answer 2

You describe the problem as "unsafe direct object references", and the OWASP group recommends two policies to solve this problem.

• using references to indirect objects based on the session and
• checking all calls to object links.

An example of proposal No. 1 is that instead of the drop-down list options 1, 2, and 3, each parameter is assigned a GUID, which is associated with the original identifier on the map in a user session. When you receive a POST from this user, you check to which object this identifier should be bound. OWASP ESAPI has several libraries that can help with this in different languages.

But in many cases, proposal No. 1 is actually counterproductive. For example, in many cases you want to have URLs that you can copy / paste from one user to another. Process No. 2 is usually regarded as the most reliable way to solve this problem.

Answer 3

You are describing Broken Access Control with Insecure Ids. Once you have identified the threat and decided which identifiers belong to specific users, make sure that checks are installed on this side of the server.