October 23, 2013 · research websec

Persistent XSS and HTML Injection in Google Feedburner

Timeline:

Oct 19, 2013 - Disclosed vulnerability to Google Security Team  
Oct 22, 2013 - Google – “your report was triaged and we’re currently looking into it”  
Oct 23, 2013 - Google Security team did not classify bug as vulnerability  
Oct 24, 2013 - Initial bug write up  

Report:

When creating a feed on Google’s Feedburner service, it is possible to inject custom HTML and Javascript through the “Summary Burner” functionality.

Initially, I sent this report through:

img1

The feed hosted by the service is found on the domain “http://feeds.feedburner.com/” which means that whilst we are able to inject HTML and execute script, it is sandboxed and certain cross domain policies disallow us to view Google session/misc cookies.

This led Google to reply accordingly:

img2

I completely agree with Tim that the domain is well sealed off from Google authentication cookies, but I still think that significant harm can be done through injecting HTML and scripts on a Google owned domain/service.

This blog post is not made to go against the decisions of Google’s Security Team as the bug I have submitted is not considered a vulnerability as per their rules, which is very fair. This rule stated that they did not accept bugs which were:

So what was the point of this post?

People know that blogspot/blogger subdomains often have active site content which is not from Google and that they should not be trusted. However, not many know that feedburner too, may have unsafe active content from the publisher. Hence, this is just an informative blog post for all.

What real harm can I do through injecting HTML or JS?

Mainly, I see social engineering attacks to be of the most harm here. Imagine visiting a feedburner page, being redirected to an attackers phishing page which asks for google credentials to view the feedburner, and then when entered, redirecting you to the feedburner. I feel as if people are unlikely to be worried when it is feedburner itself redirecting the user to the phishing page.

Note: summary burner functionality itself, says “No HTML allowed” however, there is no filtering? Anything can be added to the feedburner.

img2

Here is a final GIF of the entire process, as well as the PoC Link:

img3

Comments powered by Disqus