This post has been ported from my old self-hosted blog. The original post was published on 02-04-2020.
In this post, I will walk you through how, in less than five minutes, I found a self-XSS bug on the main Amazon.com website.
It was Christmas time and a colleague of mine had introduced me to Amazon Prime Video, so I decided to take a look at it. Whilst browsing the Amazon website, I noticed something out of the ordinary; the website used to display the user's full name in the top-left corner of the page, but this time only the first name was showing.
The fact only the first name was showing got me curious, so I decided to review the source code of the page looking for the pattern Taha. It turns out this was reflected several times in different contexts.
The one that caught my eye was the following:
window.$Nav && $Nav.declare('config.customerName', 'Taha');
The user's first name was being reflected inside a JavaScript context here! At this point, I'm pretty sure we all have the same idea in mind; close off the string and inject our code!
The way I see it is we have two options for a payload here:
');alert(0);void('or'-alert(0)-'
The last payload wins in this case for the following reasons:
Only 12 characters long
Cleaner syntax
On pasting this into the first name field and viewing any page under my account, the XSS payload would execute:
Please note that this is known as self-XSS, as you can only inject yourself and can't harm anyone else with this unless chaining it with another vulnerability such as inconsistent access controls.
Since Amazon does not have a bug bounty program, testing its services would be illegal, so no further tests were made to escalate this issue.
This issue affected the desktop version of the main Amazon.com website only. Other Amazon products were not affected.
Timeline:
21/12/2019: Reported to Amazon
23/12/2019: Acknowledged by Amazon Security Team
20/01/2020: Resolved by Amazon
15/03/2020: Asked Amazon for updates
31/03/2020: Public disclosure
Thank you for reading.