Amazon XSS

Georgie Yoxall Jun 20, 2017
1 favorite favorites
bookmark bookmark
share share

Amazon XSS

So it's been empty here for a while; mainly because I've been busy with studies, but also due to the nature of security and responsible disclosure.

Since a good margin of my more recent quality findings are yet to be patched, I haven't been able to post anything really as I wouldn't want to put the customers of these services at any potential risk.

Thought I would kick off the blog content with a recent vulnerability I discovered affecting the Amazon web application. Hats off to their security team for their exceptional cooperation and incident response to this. And for permission to share my findings here.


A quick look at the basic details of the security vulnerability I identified affecting the Amazon web application can be found in this section. I discovered this on, then later discovered the same vulnerable component was present on all of the other Amazon locales.

Vulnerability: Cross-site scripting (Reflected) [CWE-79]
Affected:,,,, and so on.
Vulnerable end-point: amazon.*/gp/buy/storeaddress/handlers/search.html/
Affected parameter: GET=storeZip, storeZip2
Time to response: 2d
Time to resolution: 2w


In this section I will discuss the more technical details of the security vulnerability.

Note: If you are not interested in details and would like to see the final results and summary, you may skip to the end of this.


So I had just decided to try out the free trial of Amazon Prime, primarily for the delivery benefits; when I noticed there was a feature which allowed you to have deliveries sent to a local pickup location for future collection.

What I noticed:
  • There were inputs for the ZIP which would be used to locate the closest pickup locations. A convenience kind of feature of the component.
  • Those inputs were not correctly validating the input data. For example, a ZIP would generally consist of: 5-6 characters, and contain alphanumeric only. I was in-fact able to enter -/+ 5 and special characters.
  • The output of the entered ZIP code was being output back onto the pickup location search results page.

Note: Although I was originally just looking to make a purchase through their services, this immediately grabbed my attention and I couldn't help but look into it more; mainly because I like to know the services which I use are secure.

HTML Injection

The next step was to inject some special characters into the input to see what output I got back. After injecting a simple header (<h1>), I noticed that the component was vulnerable to scripting as it injected my element into the source of the webpage.

From here I looked into injecting an image which were to request an external resource (hosted on my web-server), although it appeared spaces were being filtered so <img src=""> would not work; neither would standard quotes or colons as they were also blocked. Instead I found that <img+src=//> worked fine. minipic


So while I was initially able to inject HTML, such as images and headers. I wanted to go further and pop an alert (who wouldn't!), except there appeared to be a number of characters being blocked (potentially WAF or some kind of other bodged mechanism).

Blocked Allowed
Element/attribute divider / space %2f : +
Quotes " '
Functions alert confirm prompt eval atob

So after several attempts, I constructed something which met this criteria. The final payload consists of an img, apostrophes to single handily separate attributes, onerror JavaScript event handler, eval, and an atob followed by a base64 encoded string prompt(document.domain, "yoxall") which were to be later evaluated by the eval function and executed in the client's browser: <img+ src='x'onerror=eval(atob('cHJvbXB0KGRvY3VtZW50LmRvbWFpbiwgInlveGFsbCIp'))>

And there it was. It is also worth noting that document.cookie was accessible and held some interesting session-* cookies since HttpOnly was not enforced. This in conjunction with the original payload (inclusion of external resource) could have potentially been used by a malicious attacker to hijack customer accounts and/or access sensitive account information. minipic

Thanks for reading! Below you can find additional resources which discuss effective counter-strategies to these types of security vulnerabilities.

**Test:** Ignore this for now.

Tip: Never trust any user input into your application. Always ensure to carry out concise yet robust data validation checks prior to processing.

Note: You can find more information: