XSS in Google Feedburner

A fundamental aspect of web applications which developers should bear in mind is securing the input inserted by the user.  Many times, due to lack of attention or understanding, programmers might ignore the review of the code, resulting in security breaches, which through exploiting represent a threat to the confidentiality of the users’ data and to the security of the server.

Lately, the most common vulnerability, which can be found even in the sites pertaining to big brands, is called Cross-Site-Scripting (XSS) and it represents an opportunity for the attackers to encroach on the user’s safety. Usually, this breach permits the injection/insertion of malicious HTML code or JavaScript in the pages of websites by using some unsecured parameters or inadequately secured parameters. The main risks which can affect the users are the stealing of cookies, falling victims to phishing attacks or of unwillingly losing control over the browser.

Most times, Reflected and Stored Cross-Site-Scripting vulnerabilities are caused by unsecured GET or POST parameters; however, this is not always the case. All the headers which are sent together with a certain request to the server can be customized by the user, and, in some cases, can trigger the emergence of various vulnerabilities.

Finding the XSS vulnerability in Feedburner

Recently, I have found this kind of vulnerability in a Google product, Google Feedburner, and I will attempt to explain the process of finding this breach and possible ways of exploiting it (by an attacker).

According to Wikipedia, “FeedBurner is a web feed management provider launched in 2004…FeedBurner provides custom RSS feeds and management tools to bloggers”. One of the features of Feedburner is that it offers a comprehensive/detailed analysis of your own feed traffic.

In order for each new view of a link from the feed to be counted, you should check the corresponding text box “I want more! Have FeedBurner Stats …” during the second step of the registration process of a feed. From this moment on, each request sent to an item from the feed will be initially sent to a proxy server: http://feedproxy.google.com/~r/BLOGNAME/~3/ITEM_ID/ITEM_TITLE and then redirected to the original/primary link.

For each feed that has enabled these statistics, any new source of traffic (any place where a particular item of the feed was viewed or accessed) is filtered by the FeedBurner system. If this source is a common one and was seen across multiple feeds (e.g.: clients’ e-mail, web-based feed aggregators, news filters, etc.), it will be visible to the feed owner, in the control panel (Dashboard), under the tab “Analyze”, in the “Subscribers” field.

Otherwise, the source (link) is visible in the control panel (Dashboard), under the tab “Analyze”, but this time in the “Uncommon uses” field and is highlighted in the central tab.

After several tests, I discovered that these “Uncommon uses” are nothing but values of the “Referrer” header corresponding to GET requests made to the items in the feed. As a security measure, the characters  <, >, ‘,   were encoded as HTML entities, but they were rendered in the following way

<a href="VALUE_OF_CURRENT_REFERER">VALUE_OF_CURRENT_REFERER </a&gt

Therefore, a request sent with the” Referrer” header set to javascript: prompt(1) towards an item of the feed was enough to insert JavaScript code. Once the user had clicked on the payload inserted by me, the prompt() function would have been called.

How it was fixed

The Google engineers solved  this issue by adding some code which checks every new link which comes as an “uncommon use”. If it starts with a valid scheme (http,https,ftp), it is rendered in the HTML page as using the <a></a&gt; tag, if not, it is rendered as a simple text.

Exploiting techniques

This vulnerability could be exploited in two ways

1. The attacker creates a feed, follows the steps mentioned earlier in order to insert an XSS in his own feed and transfers it to a possible victim.
   Requirements
   • The victim must accept the transfer of the feed
   • The victim must click on the payload inserted by the attacker
2. The attacker finds the feed of the victim, saves the link corresponding to an item and sends a few GET requests to it, with the value of the Referrer header set to
   javascript:evil_code_here();.
   Requirements
   • The victim must enable the statistics mentioned earlier
   • The victim must click on the payload inserted by the attacker

Important stuff to bear in mind

1. Never trust user input!
2. Secure all parameters and headers which are controlled by the user and are used within the web application!
3. Be careful with the values used as hyperlinks. Perform a RegEx check on them and ensure that the values submitted by the user are valid URL-s before storing them in the database.

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.