CSRF and stored XSS in Amazon Wishlist

The Amazon Wishlist was vulnerable to both CSRF and stored XSS. I discovered these vulnerabilities separately, but I'd like to describe both of them in one blog post here. Even though neither of these vulnerabilities would have had a big impact by themselves, if combined, they could have become a serious problem.

There was no CSRF-token validation for creating a new wishlist. Because of this, an attacker could have made a user send a request to amazon.com to create a wishlist with an arbitrary name. The following is a sample malicious page that redirects a user to amazon.com to create a wishlist named "CSRFed".

The stored XSS was in the wishlist name displayed on the Shopping Cart page. This vulnerability could only have been dangerous if an attacker could have tricked a victim user into changing his wishlist name. The following steps were taken to produce the XSS:

1. I created a new wishlist and set its title to "<img src=x onerror=alert(/XSSed/)>" in my Wishlist page at http://www.amazon.com/gp/registry/wishlist/.
2. I opened my Shopping Cart page at http://www.amazon.com/gp/cart/view.html.
3. An alert popup showing "/XSSed/" was displayed on my browser--the script was activated. 

If an attacker would have exploited these two vulnerabilities, he could have activated an arbitrary script on a victim's browser. In this attack, the attacker would have been required to create a malicious web page containing two iframes. One frame would have been for executing CSRF to create a wishlist and set its name to a malicious script. The other frame would have been for opening the Shopping Cart page. The iframe for XSS would have had to have been loaded after the wishlist had finished being created. When the XSS iframe opened, the script would have been activated.

I reported the XSS vulnerability on August 30 and confirmed that it had been fixed on September 25. Likewise, I reported the CSRF vulnerability on September 25 and confirmed that it had been fixed on October 3.