Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Say I wanted to avoid exposing a database primary key in a URL; somehow I must encrypt the key, so that the url only exposes elements of an unenumerable cipherspace. What kind of encryption should I use?

N.B. I'm aware that this is not the whole of a secure process. I would of course have to validate attempted access to such a URL. I'm asking about how I might use encryption to add a layer of obfuscation that prevents object enumeration.

share|improve this question

3 Answers 3

Direct Object Reference is a really bad name for: lack of authorization controls. Knowing the ID isn't really the problem. The problem is that each record in the database needs to have ownership information, and you should enforce this ownership by keeping information about the user in a session.

The best cryptographers know when crypto isn't needed, and a stronger system can be used in its place.

share|improve this answer

Cryptography on the record ID does nothing meaningful. They could still replay the ID unless it was tied to a session key as well. The larger question though is why is a primary key being passed in a URL at all? If you are tracking session state, it should be possible to work with the data server side without having to pass it back and forth. You can also use things like POST to avoid having to put it in the URL at all, even if some identifier has to be passed to the client.

If the ID is sensitive, set up a one time use mapping in the DB so that you can pass a token instead of a meaningful ID. That way it can't be broken and can only be resolved by the server for the time period that you choose, by the user that you choose.

share|improve this answer
1  
To add, I think having key (even if encrypted) is risky for SQLi –  Novice User Apr 12 '13 at 18:38

There are two general means to avoid Insecure Direct Object references.

As @Rook says the best way is Check authorisation on all requests :), that's the correct place to solve the problem.

If, for some reason, you can't do that or you want additional layer of protections you could consider creating an access map, so that the reference presented to the users isn't a direct one and can't be changed to give access to another users data.

To illustrate this concept. Say we have a database ID that goes A1..A10000 which are records for a number of users. When the user logs in or accesses the page that shows them this data we do a database query that returns all the records they should have access to. Then on the server we create a mapping table

e.g

1 --> A1000

2 ---> A1005

etc

Then when we give the ID to the user we give them the mapped ID (e.g. 1, 2 ) and not the direct ID (e.g A1000, A1005).

So when a user makes a request to the application they can only request IDs that they have access to and not one's belonging to other users (as the direct object reference isn't exposed..)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.