1

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?

user91107
  • 29
  • 2
  • 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 04 '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 04 '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 04 '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 04 '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 04 '15 at 19:24
  • If you visit index.php with the session ID of 1, you see record ID 1, with the session ID 2, you see record ID 2 etc. etc. There is a further login and check that logged in user has permission to access requested record etc. but that aside isn't altering the session to access a different record infeasible? – user91107 Nov 04 '15 at 19:38
  • Are you able to do this? `index.php?id=1`, or something like that? Does the session data show when you send a request? Check out something like `TamperData` for Firefox, and see if the session variable is visible on the client end. – Mark Buffalo Nov 04 '15 at 19:45
  • Are your session IDs really successive integers or was that just an example? – Neil Smithline Nov 04 '15 at 20:56

1 Answers1

1

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.

Community
  • 1
Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • 1
    Indeed, but what if the session management was done server side e.g. using PHP? – user91107 Nov 04 '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 04 '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 04 '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 05 '15 at 06:18