Home/ Questions/Q 8595519
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T00:27:11+00:00

I’ve recently inherited a ASP.NET MVC 4 code base. One problem I noted was

  • 0

I’ve recently inherited a ASP.NET MVC 4 code base. One problem I noted was the use of some database ids (ints) in the urls as well in html form submissions. The code in its present state is exploitable through both URL tinkering and creating custom HTML posts with different numbers.

Now while I can easily fix the URL problems by using session state or additional auth checks i’m less sure about the database ids that get embedded into the HTML that the site spits out (i.e. I give them a drop down to fill). When the ids come back in a post how can I be sure I put them there as valid options?
What is considered “best practice” in terms of addressing this problem?

While I appreciate I could just “GUID it up” I’m hesitant to do so because I find them a pain in the ass to work with when debugging databases.

Do I have a choice here? Must I GUID to prevent easy guessing of ids or is there some kind of DRY mechanism I can use to validate the usage of ids as they come back into the site?

UPDATE: A commenter asked about the exploits I’m expecting. Lets say I spit out a HTML form with a drop down list of all the locations one can import “treasure” from. The id of the locations that the user owns are 1,2 and 3, these are provided in the HTML. But the user examines the html, fiddles with it and decides to put together a POST with the id of 4 selected. 4 is not his location, its someone else’s.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Validate the ID passed against the IDs the user can modify.

    It may seem tedious, but this is really the only way to make sure the user has access to what they’re trying to modify. Using GUIDs without validation is security by obscurity: sure guessing them is hard, but you can potentially guess them given enough resources.

    You can do this at the top of the controller before you do anything else with the posted data. If there’s a violation, just throw an exception and have your global exception handler deal with it; you don’t need to handle it in a pretty way since you can safely assume that the user is tampering with data in an unsupported way.

    • 0