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 to create a wishlist with an arbitrary name. The following is a sample malicious page that redirects a user to to create a wishlist named "CSRFed".

Loading ....

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
  2. I opened my Shopping Cart page at
  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
  2. I shortened the URL to 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=//><!--".
  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 was vulnerable to a persistent XSS attack. A malicious user could have activated an arbitrary JavaScript in any visitor's browser. 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 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. 

Sunday, November 27, 2011

Sunday, March 6, 2011

Submarined XSS - DEMO

I made demonstration webpage for the XSS I described as a submarined XSS in the previous post, since I was not sure I could adequately explain it in words. The demo has two examples; one is for an XSS that can be successful after some user interaction, and another is to show the incapability of executing reflected attack.
The demo page is here.

Thursday, March 3, 2011

Submarined XSS

It is not a new attack vector but I haven't found a proper word for describing this attack so far.

The attack I describe here is an XSS in which an attack code is properly sanitized before being contained in the immediate response and is not stored by the server, so the attack won't be carried out at this step yet. However, the attack does harm as a result of the appearance of the already-sanitized attack code (not being sanitized this time, this is the cause of the vulnerability by the way) after a victim visits several pages in the same website. In this website, the session manager prohibits visitors from directly accessing the target webpage the attak code does harm, the attack can be successful only when the victim clicks on the link the attacker prepared and is required to browse some pages in the website to activate the attack code before a session expires.

This attack is not a reflected type of attack since the attack code is properly sanitized in the immediate response. In addition, since the attack code is not stored by the server, this attack does not do harm as a stored type of attack does to any visitors to the target webpage the attack code appears.

Sunday, December 19, 2010

post4a.js Demo

I introduced a small JavaScript library that send a POST request with an Anchor HTML tag in the last post. Today I made the post4a.js project web page with its demonstration in this page.
The web page has two demos: one for successfully sending a POST request, and the other is for showing an error caused when requesting a static content (such as an HTML page) with the POST method and getting a "405 Method not allowed" error. Since static contents might refuse your POST requests, although it depends on the server configuration, please use post4a.js to send POST requests only for executable scripts (such as PHP, CGI, JSP, ASP, etc.). Thanks.
post4a.js web page is here.

Thursday, December 16, 2010

post4a.js: POST for Anchors to Prevent Referrer Information Leakage

Lately, much attention has been focused on information leakage stemmed from HTTP Referrer. As far as I saw The Wall Street Journal, I found these articles:
These articles seem to refer to Google and Facebook as those who leak user information though, it sounds like the websites are requested to refuse to be accessed via URL with query-strings. Since the browsers automatically embed the URL of the referring site into the HTTP Referrer value, the only thing websites can do is to not use URL with query-strings... The most part of this problem lies in the browsers because the Referrer-related security settings are allowed in the today's browsers by default. Even though we can disable sending Referrer information according to this page, these are not easy for most users... Anyway, from the website developer's point of view, it is not recommended that the website attach user's sensitive information to its URL. HTML anchor tags also cannot hold any security token or user id. What would you do? I made a JavaScript library named post4a.js for sending a POST request with an HTML anchor tag. The following is the summary of post4a.js project page in GitHub.
post4a.js is a JavaScript library that would help to prevent websites from exposing a user's identity embedded in Referrer to other sites, by avoiding selected query-strings from being used for the page URL. The regular HTML anchor tags (<A>) let browsers issue GET requests when the user clicks on the anchors, so that the browser can simply, directly open the requested page with the URL specified in the anchor's href attribute. When the browsers send the HTTP request, they by default automatically attach the Referrer value to the request for the purpose of letting the destination website know about the page from which the browser is arriving. If the URL contains user's sensitive information, the destination website can extract them from the URL. Since POST requests embed query-strings into the request body instead of the URL, they are safer than GET requests in terms of Referrer information theft, because the request body is not automatically embedded to other requests. However, the browsers only send GET requests for anchor tags, currently. post4a.js provides a simple solution currently available on the today's browsers. It automatically converts the specified anchor tags into form tags to send POST requests with some pieces of parameters you want to hide from Referrer.
post4a.js can be used like this.
Loading ....
The source code and detailed information about post4a.js are on GitHub. Your involvement to post4a.js is always welcome :) thanks. post4a.js on GitHub