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 amazon.co.uk, then later discovered the same vulnerable component was present on all of the other Amazon locales.
Vulnerability: Cross-site scripting (Reflected) [CWE-79] Affected: amazon.co.uk, amazon.com, amazon.de, amazon.ie, 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.
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=//yoxall.me.uk> worked fine.
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).
prompt(document.domain, "yoxall") which were to be later evaluated by the eval function and executed in the client's browser:
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.
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: