Amazon packaging feedback cross-site scripting vulnerability


I received an order from Amazon the other day which had a URL printed on the side of the box leading to the packaging feedback form. Amazon have a vulnerability reporting programme and I had a spare 20 minutes, so I thought I'd have a look to see if there were any obvious security vulnerabilities.

After a few dead ends I noticed that the form used a hidden input field named failureRedirect, which when set was followed when invalid user input was submitted. After testing, it seemed that the URL could be set to any domain as long as it started with a valid protocol; an open redirect. But there was more…

The Amazon packaging feedback form

The attack

By default, the redirect was performed using the standard Location HTTP header. I noticed another parameter, however, named useJSRedirect, which in normal use was always set to a value of 0. I tried changing its value to 1, and sure enough the script returned a small JavaScript redirect snippet in place of the Location header.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
function cmuJsOnLoad() {
	var redirect = "";
	parent.location.href = redirect;
<body onload="cmuJsOnLoad()">

The snippet contained the failureRedirect parameter as the redirect variable, and it didn't take long to find that quotation marks contained within the string weren't properly encoded, making it trivial to break out of the redirect code and execute arbitrary JavaScript within the <script> tag kindly provided by the packaging feedback form itself.

The exploit

Exploitation was possible by POSTing to the form with a custom JavaScript payload:

<form action="" method="post" enctype="multipart/form-data">
	<input type="hidden" name="failureRedirect" value='";alert("Your session cookies:\n"+document.cookie+"\n\n-- Bitquark");//' />
	<input type="hidden" name="useJSRedirect" value="1" />

The XSS in actionPage source during attack

As you can see, the redirect string is broken out of, allowing arbitrary JavaScript to be injected and executed directly after the variable is set. The injected string is ended with a // comment to prevent the ?s_tc=1 string, which is always appended to the URL, from generating an error and stopping the exploit code from running.

As an added bonus, because the attack is structured around a fairly innocuous looking string, the attack doesn't trigger Chrome's XSS protection. Sneaky!


  1. 2013-06-13 Vulnerability reported to
  2. 2013-06-13 Acknowledgement email received from an engineer with a case number
  3. 2013-06-17 Received notification from Amazon that the issue was fixed
  4. 2013-06-21 Tested, script still vulnerable, contacted Amazon again
  5. 2013-07-01 Notification of fix, previous email accidentally sent before fix deployment
  6. 2013-07-03 Tested again, fixed as expected

Update: I asked Amazon about rewards for their bounty programme, this is the reply I received:

Amazon operates under a responsible disclosure policy. As such, we do not offer a reward for reporting security issues. However, we do acknowledge the reporter of bona fide issues when we publish an advisory on them.