CODEWITHSUNDEEP
c#javascript.netsecurityurl
Dav.id
Dav.id

Reputation: 2797

How to hide a database ID from HTML/Javascript

Obviously depending on the type/context of data returned to a web front-end (in my case the setup is HTML/Javascript, .NET Csharp back-end and JSON as the data transport), if I have to return an ID say of a message that is an auto-generated primary key (Int64), what is the best way to "hide" this real ID?

For most things of course, I can understand it doesn't make too much difference, however an application I am working on means if a user "guesses" an ID in the URL to pull back another record, it could prove to be a security issue..

There seems to be lots of ideas/commentary about methods, but nothing has quite clicked.

I was thinking of having an auto-generated primary INT, but also a secondary alternate GUID too. It would be the GUID returned to any front-end process, and of course the auto-generated primary ID would still be used in the backend..

The thinking of course is the GUID would be far more difficult to guess/obtain another one to access a record?

Any ideas or best practices people use?

Thanks in advance, David.

Upvotes: 0

Views: 2914

Answers (5)

Yahia
Yahia

Reputation: 70369

Regarding security you have several aspects:

  • Session hijacking
  • Accessing/Modifying/Creating/Deleting records the user is not authorized to
  • Non-Authenticated access
  • Cross-Site* attacks
  • Man-in-the-middle attacks
  • etc.

The measures to deal with these depend on your architecture and security needs.

Since you don't say much about your arhcitecture and security needs it is really hard to give any specific advice...

Some points regarding "ID shouldn't be guessable":

  • "Correct" solution
    The problem goes away in the moment you implement authentication + autherization properly because properly implemented these two make sure that only authenticated users can access anything at all AND that every user can only access things he is allowed to. Even if an authenticated user knows the correct ID of something he is not allowed to access this would be secure because he would prevented from accessing it.

  • "weak solution"
    create a ConcurrentDictionary as a thread-safe in-memory-cache and put the real IDs plus the "temporary IDs" (for example upon first record access freshly generated GUIDs) in there. You can combine that temporary ID with some salt and/or encryption and/or hash of some connection-specific aspects (like client IP, time etc.). Then on every access you check with the ConcurrentDictionary and act accordingly... one positive effect: after app restart (for example app pool recycling) the same record gets a different ID because this is only an in-memory-cache... though this is hardly usable in a web-farming scenario

Upvotes: 3

gahooa
gahooa

Reputation: 137332

All of the other answers (3) failed to cover the possibility of this being a non-cookied, non-authenticated, non-sessioned, non-logged-in user.

For example, a confirmation page after a order, etc...

In that case, your authentication is based on a secret in the URL. You use a secret that for all practical purposes is unguessable, and very unique per record. Then you assume that if the user has that secret, then they have access to said record, etc...

The real chalenge is to find a good way to make a secret UUID. Many developers will take the SHA1() of rand() + time() + uuid() + remote_ip() or something like that (which is typically sufficient), but I'm sure there is plenty of documentation out there on this.

Yes, in a situation where you have a non-authenticated user accessing a specific piece of data or performing an action (such as password reset), you need to have a second identifier (eg, varchar 40) on your records with a unique key (as you had outlined). Fill it with very random data, and if they have that secret, then let them in.

Take care.

Upvotes: 1

Polity
Polity

Reputation: 15130

Ofcourse technically, pulling back another record by quessing another ID is a bad thing- only when that other ID shouldnt be visible for the user who's pulling it back. But then you have a security problem anyways and you should focus on that rather then find a way to obfuscate the ID

Anyways, if you want to mess up the url, i recommend you looking into Rijndael. We use it alot here to pass around tokens. Basically, this encryption technique allows you to both encrypt and decrypt. Therefore you can encrypt the ID, send it to the client, the client posts it back and you can simply decrypt again. No need for an extra database record. Even more secure is to encrypt/decrypt the record ID salted with something like an IP for the current client, therefore even URL fishing will be a reduced problem.

See: http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndael.aspx

Upvotes: 2

gekowa
gekowa

Reputation: 452

I would like to say that, the URL are meant to be public, it is not kind of confidential data. There's no need to hide the url from users. If a url can be seen by one user and should not be accessable to another user, you should check the privilege of the user from the server side instead of hiding that url.

Upvotes: 1

rabs
rabs

Reputation: 1827

I am working on means if a user "guesses" an ID in the URL to pull back another record, it could prove to be a security issue.."

If this is the case then you really need to step back and review the approach to security. If a user can access records which they don't have authorisation to view you do not provide appropriate security of your Object References - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References

The GUID approach will attempt to provide security by obscurity see Is using a GUID security though obscurity? as to whether or not it does you will have to make your own mind up based on your circumstances.

Upvotes: 3

Related Questions