• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how to avoid URL manipulation? user place IDs on the url to get a result without permission

 
Adrian Burlington
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A relatively 'abstract security question' how can I avoid users to manipulate the URL and circumvent a security permission?

Example, user clicks a link: https://localhost:8443/MyApp/userProfile_prepareProfile.do?userID=53122

In this example the parameter will be for user ID 53122 but what if the end user manipulates the URL and place userID=4444 (someone else).

I guess, one way to solve this is to encrypt the userID but wonder if there's a better way to do it (I'm using struts2)

Thanks!

 
Mike Zal
Ranch Hand
Posts: 144
Fedora Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you encrypt the id, you will still run into the same issue if people know what encryption algorithm you used. I would add a check on the Controller (I assume Servlet or Facelet) to verify that the user is an admin or that the id matches the id of the person logged in. I can't think of any other way besides the programmatic way, but I am not an expert.
 
Paul Clapham
Sheriff
Posts: 21416
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
People don't even need to know how you encrypted the user ID. They can just observe somebody else sending in an encrypted user ID and copy what that person sent in. That isn't as easy to do as just guessing random user IDs, or finding somebody else's user ID, but it's still a possible threat.
 
James Sabre
Ranch Hand
Posts: 781
Java Netbeans IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adrian Burlington wrote:A relatively 'abstract security question' how can I avoid users to manipulate the URL and circumvent a security permission?


Since the user ID is the prime means of identifying a user it should never be visible to anyone or anything outside of the server. An approach to this is to use an encrypted cookie. When a user logs on he is sent an encrypted cookie that contains his user ID, time of generation (according to the server that created it), the login state, a random IV and a checksum/digest. Each subsequent request from the client takes with it the encrypted Cookie which decrypted by the server. The server then does some checks on the content of the Cookie value; as a minimum

1) it checks that the checksum/digest indicates that the Cookie has not been tampered with,

2) it checks that the Cookie was presented within N minutes (say 5) of being created (a window of use). If it has expired then the user is forwarded to the login page to restart the process.

3) The login state.

If it passes all the tests then it is accepted as valid and the request is actioned. When the results are passed back to the client a new values for the Cookie is generated and encrypted.

At no time is the user ID exposed to anyone outside of the server.
The Cookie values has a very limited lifetime before it expires which means the window available for reuse/copy to another computer is very very small.
The Cookie value cannot be forged.

If one desires that Cookies not be enabled then one can instead use a hidden field to contain the encrypted values.


 
Adrian Burlington
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you all for the input!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic