This happens when a cyber-criminal controls somebody else’s account by using credentials (session ID, username number, etc.)

In this example I will demonstrate this technique using Mutillidae, we’ll create 2 accounts and highjack it.

  • OWASP 2017 - “A5 - Broken Access Control” - Insecure Direct References – Via Account Highjacking

Demo

1. Create an account “Please register here”

It opens a script named “page=register.php” Enter the following

  • Username: attacker
  • Password: test
  • Confirm Password: test
  • Signature: Follow on Twitter -> @Vry4n_

Click on create account

2. Go back and this time click on “login here”

Click on Login to access the new account. It shows at the top “Logged In User: attacker”

3. Capturing the login request with BurpSuite we noticed that by logging in the servers modified the current cookie by adding 2 more values besides the existing “showhints=1; PHPSESSID=21cv08dsk7jisebj1vb0a428jp”

HTTP request

HTTP response

New values:

  • username=attacker
  • uid=24 # This is the user ID we will exploit it

4. Send that to Burp Intruder, set the uid value as variable, as I saw 24 as uid of my created account, I will count from 1 - 100

Positions

  • Attack type: sniper
  • Uid-$24$

Payload 1

  • Simple list
  • Load ->select the list of numbers
  • Start attack

I went through the results and checked what is printed on “Logged In User: “, some results showed other than attacker, which means the uid exists

I found “admin” to be uid=1, this time the result show “Logged In Admin: “

5. Inspecting the cookie and changing the current value in the browser from 24 (attacker) to 1 (admin)

6. The result is that the user logged in now is “admin”

7. If you go back to “OWASP 2017 – ‘A5 - Broken Access Control’ - Insecure Direct References – Via Account Highjacking”

The password of the user admin can be changed.

Tips: To test this vulnerability you can create 2 accounts and compare their values to know if that can be predicted/stolen somehow.

Best practices

  • Implement role based access control to assign permissions to application users for vertical access control requirements
  • Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
  • Avoid assigning permissions on a per-user basis
  • Perform consistent authorization checking routines on all application pages
  • Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis