1

Suppose, There is a user list.

<a href="user/5">Edit</a>
<a href="user/6">Edit</a> 

When a system user clicked to edit a user info. Then it goes to url to browser like as

http://abc.com/user/5

He can manually replace 5 to 155 and edit(update) the user info. It is a problem to me. How can I remove this problem?

I have an idea: Calling the edit page by ajax. So that the number will be hidden. Is there any good idea?

  • 6
    There is no way to hide a URL in this way. Instead, you should look at how to make it impossible for a user to do anything malicious with a URL (eg editing another users details) – Andy Hunt Jul 6 '15 at 8:16
  • 7
    "But, System will be used by general and non technical user." Security through obscurity is no security at all... The question is more like can your user base be trusted to not execute anything with malicious intent? – user2033511 Jul 6 '15 at 8:52
  • 8
    Your server needs to verify if a request is valid. A random connection should not be given access to sensitive data. Only connections that are associated with a certain user (a session, established after a user logs in) should be allowed to view and edit information for that particular user. – Pieter Witvoet Jul 6 '15 at 9:00
  • 3
    I would advise looking into why security by obscurity doesn't work – Esben Skov Pedersen Jul 6 '15 at 10:31
  • 1
    I want to stress that all of the approaches to this problem that don't involve securing the resource on the server are missing the forest for the trees. If your Resource is "in the wild" and your Identifier is published to your browser via http, it is a trivial matter to attach a non-browser client to the resource and bypass your effort. There is no way to "secure" a remote resource from inside the browser. – K. Alan Bates Jul 6 '15 at 15:21
1

Your application probably have different actions with different access levels, for example an admin will probably be allowed more things than a simple user.

So you better build some data-matrix summarizing user(-roles) access-rights and check brefore treating any request if the current logged-in user (or even unlogged Guest if you happen to have such a role) has the right or not to perform this action. Of course this might look overkill, but if you mind about security you definitely need it. You can NEVER trust the user, you always have to validate server-side.

5

I have encountered this issue several times and have found what I think is the simplest solution. Since your user can edit (personal/account?) information, I assume you have some kind of authentication system up and running. If you use sessions to keep track of recognized clients you can store the user's ID inside it. Then you can fetch the ID from the session when the appropriate page is requested. You would have to change your URL structure to users/edit (or something similar) so that is does NOT have any sensitive information.

Now you have hidden the sensitive data from the URL. This also comes with a bonus. Imagine a user linking his current URL (your old structure with the ID) in an email and the recipient clicks it. Your validated user have now unwillingly given away his/hers ID.

Sum up

  1. Remove the user ID from the URL structure
  2. Store the user ID inside a session
  3. Change the URL structure to NOT include any sensitive information
  4. Fetch the ID from the session when the appropriate page is requested
  5. Continue business as usual

Alternative

If the ID inside the URL is a requirement you can "borrow" some of the concept from the above. If you store the user ID inside the session (or your used temporary storage of recognized users), you can compare the ID from the URL against it. If it matches we are good to go, otherwise we can show and error, logout the user and so on.

Hope this can help you, happy coding!

3

Just use an URL with some query parameters, like

<a href="user/5?checksum=12345">Edit</a>

Of course the checksum is computed, perhaps using some session cookie, and your server code has something to validate it. So if your user is abusing the system by editing the URL (e.g. replacing user/5 by user/567) the checksum should no more be valid.

Be kind with your users. Don't have an absurdly long checksum (like linkedin does). Make it of reasonable length (e.g. 48 chars is more than enough).

Expect advanced users to eventually (and legitimately) bookmark such an URL so ensure it is working when some user uses it next month or next year.

  • How can this help us avoid a malicious user changing the ID? As I see it the checksum works like an CSRF-token or am I completely off? Edit to update: If the checksum is long-lived isn't just another kind of ID. It has to be long-lived if persistence of links is desired. – AnotherGuy Jul 6 '15 at 10:25
  • @AnotherGuy checksum would be calculated by e.g. taking a substring of the result of sha256(requesturl + secret), where requesturl is the path portion of the url and secret is a server-side secret string that's never shared with the user. – Jules Aug 1 '15 at 14:34
  • @Jules - The issue still stands. Even though the server side secret is never shared with the client, the checksum/hash works as an alternative ID and would persist in links sent by email. This only makes guessing the actual ID harder, but if enough checksums are collected you can start to crack them for their common secret. – AnotherGuy Aug 1 '15 at 16:34
0

You can't just let your users edit other peoples account. If you are thinking that your problem is in URL, then I think you're wrong. If you have a proper user authentication and session handling this wouldn't occur. Then if you really don't like having readable values in your URL, you could try to hash or encrypt them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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