Imagine this scenario:

  1. SQL record is created for user
  2. record ID is stored in session
  3. SQL record can be updated where session ID = SQL ID
  4. user can view data in SQL record where session ID = SQL ID

Pretty straightforward no?!

Anyway, imagine user A (without any malicious intent) can view user B's data.

How on Earth could this happen?

  • I am not sure I understand your question. Are you looking for an explanation for a real-life situation? Is this a homework problem? – Neil Smithline Nov 4 '15 at 18:43
  • Haha! Real life. I have a small web app. User B says he accessed used A's data. I don't think that's possible (discounting SQLi, session spoofing etc.) – user91107 Nov 4 '15 at 18:58
  • He could have if you messed up the server-side code in any number of ways. Did he say he did it on purpose, or was it a complete accident? There are a billion things I can think of that would cause such an issue. – Mark Buffalo Nov 4 '15 at 19:11
  • You should provide more information in your post. We can't see your code, so we can't really troubleshoot it. It's possible you have a glaring issue we can't see right now. – Mark Buffalo Nov 4 '15 at 19:13
  • I know the question is vague sorry, but assuming (a big assumption I know!) that the SQL etc. is fine and the only variable is the session ID, how could this happen? Could a server mess up sessions between users?! For example: SELECT * FROM mytable WHERE id = ? (where ? is the session ID inserted using a parameterized query) - How feasible is it that the session ID could be tampered with? – user91107 Nov 4 '15 at 19:24

If I understand you right... Imagine I spy on your Javascript inner-workings for a while. Imagine I am able to look for the following:

  1. DeleteUserRecord()
  2. UpdateUserRecord()

And in each, you're matching these IDs to the primary key in the database. For example, your code excutes this: DELETE [record] FROM [table] WHERE [id] = '1234', and your Javascript looks like this: DeleteUser(1234). What if I change it to 1? What if I delete every single user? What if I delete the first user, who could presumably be the admin?

Or what if I were allowed to update a single user's record, but I change the ID to 1 and make myself the admin? UpdateUser(1) instead of UpdateUser(1234)

Sounds like your code might be vulnerable to a direct object reference exploit.

All I need to do is tamper with your javascript request and you're TeH PwNz0rEd. Try reading this thread for a better explanation.

  • 1
    Indeed, but what if the session management was done server side e.g. using PHP? – user91107 Nov 4 '15 at 18:55
  • If it's done server-side, meaning the user is never able to come in contact with that ID, let alone modify it, then you should be fine. But if you're allowing them to change the ID, then that's bad news bears. This would only be able to protect from this particular exploit. You'd still need to secure other things; you'd need to sanitize your inputs. – Mark Buffalo Nov 4 '15 at 18:58
  • 1
    Thanks. That's what I thought. The user has no interaction with the ID other than via the session (i.e. by creating a record they're set a session containing the ID for that record). – user91107 Nov 4 '15 at 19:02
  • @user91107 I should correct myself: sanitizing inputs isn't really the answer. You need to make sure that you used Prepared Statements / Callable Statements / SQL Parameters. – Mark Buffalo Dec 5 '15 at 6:18

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.