Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions src/pentesting-web/account-takeover.md
Original file line number Diff line number Diff line change
Expand Up @@ -151,11 +151,32 @@ This also happened in [**this report**](https://dynnyd20.medium.com/one-click-ac
As explained [**in this post**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9), it was possible to login into an account, save the cookies as an authenticated user, logout, and then login again.\
With the new login, although different cookies might be generated the old ones became to work again.

### Trusted device cookies + batch API leakage

*Long-lived device identifiers that gate recovery can be stolen when a batch API lets you copy unreadable subresponses into writable sinks.*

- Identify a **trusted-device cookie** (`SameSite=None`, long-lived) used to relax recovery checks.
- Find a **first-party endpoint** that returns that device ID in JSON (e.g., an OAuth `code` exchange returning `machine_id`) but is not readable cross-origin.
- Use a **batch/chained API** that allows referencing earlier subresponses (`{result=name:$.path}`) and writing them to an attacker-visible sink (page post, upload-by-URL, etc.). Example with Facebook Graph API:

```http
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
```

- Load the batch URL in a hidden `<iframe>` so the victim sends the trusted-device cookie; the JSON-path reference copies `machine_id` into the attacker-controlled post even though the OAuth response is unreadable to the page.
- Replay: set the stolen device cookie in a new session. Recovery now treats the browser as trusted, often exposing weaker “no email/phone” flows (e.g., automated document upload) to add an attacker email without the password or 2FA.

## References

- [https://blog.hackcommander.com/posts/2025/12/28/turning-a-harmless-xss-behind-a-waf-into-a-realistic-phishing-vector/](https://blog.hackcommander.com/posts/2025/12/28/turning-a-harmless-xss-behind-a-waf-into-a-realistic-phishing-vector/)
- [https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050](https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050)
- [https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea)
- [0xdf – HTB Era: security-question IDOR & username oracle](https://0xdf.gitlab.io/2025/11/29/htb-era.html)
- [Steal DATR Cookie](https://ysamm.com/uncategorized/2026/01/15/steal-dtsg-cookie.html)
{{#include ../banners/hacktricks-training.md}}