slides
TALK

Basic Web Hacking.

From IDOR to Account Takeover
Jonathan Christiani
THE BASICS

Four aspects an attacker goes after.

C

Confidentiality

Only the right people can read the data.

I

Integrity

Data cannot be changed by the wrong people.

A

Availability

The service stays up when people need it.

A

Authenticity

You really are who you claim to be.

C-I-A is the classic triad.

THE VULNERABILITY

What is IDOR?

Insecure Direct Object Reference: the app exposes an id and trusts whatever id the client sends, without checking who is allowed to see it.

Normal request
GET /api/profile/1023
Your own account.
Change the id
GET /api/profile/1024
Another user's account.
The server never checks
200 OK
It returns the data anyway.
IN MOTION

Same endpoint. One number.

The response is JSON: profile fields plus a password reset token. Change the id, and the server hands you another user’s token.

WHY IT MATTERS

Small bug, big blast radius.

  • No exploit tool needed, just change a number
  • Easy to miss in code review and in tests
  • One endpoint can leak every user's data
Aspect attackedConfidentiality+ Integrity, if you can also change it
THE ESCALATION

From IDOR to Account Takeover.

Account Takeover (ATO): the attacker ends up controlling an account that is not theirs, able to log in and act as that user.

What usually causes it
  • An IDOR on the change email or change password endpoint
  • A password reset token tied to a guessable id
  • Updating another user's account because the id is trusted
Aspect attackedAuthenticitythe attacker is now you
THE CHAIN

One token, four steps.

That leaked reset token is all it takes. No password needed.

01"reset_token": "7bc3..."Pulled straight from the leaked user response.
02POST /reset-passwordSend the stolen token with a new password.
03200 OKThe server trusts the token and sets the password.
04POST /loginLog in as her. The account is yours.
HANDS ON

Live demo.

The hacking lab is ready. Let’s walk an IDOR all the way to a full account takeover, then patch it.

User APIGET /api/profile/1
Reset password/reset-password/[token]?email=victim@example.com
Lab environment, authorized target
THE FIX

How we close the gap.

01

Authorize every request

Check that the logged-in user owns the record, on the server, every time.

02

Do not trust the id from the client

Scope queries to the current user, for example where user_id = auth id.

03

Use non-guessable ids

Prefer UUID or ULID over sequential numbers, as defense in depth.

04

Log and rate-limit

Watch for one account walking through many ids in a row.

05

Return only the fields you need

Never ship secrets like a reset token in a user response. Send what the screen needs, nothing more.

STAY CURIOUS, STAY ETHICAL

Thank you.

Jonathan ChristianiFrom IDOR to Account Takeover