I’ve found a few bugs on various Facebook satellite/marketing domains (ones which are part of the Facebook brand, but not necessarily hosted/developed by them, and not under the *.facebook.com domain). Most of them aren’t that serious.
This one isn’t an exception, and I wouldn’t normally blog about it, but it’s an interesting use case as to why content types are important.
The bug is an XSS discovered on Facebook Studio. This is linked to by some Facebook marketing pages, and is used to showcase advertising campaigns on Facebook.
There is an area which allows you to submit work to the Gallery. This form conveniently has an option to scrape details from your Facebook page and fill in boxes for you (such as Company Name, Description).
This calls an AJAX end-point with your pages URL as a parameter.
If we set our pages description to something containing HTML/Javascript, it’s properly escaped. However, it’s escaped client-side. The end-point incorrectly sends a content-type header of text/html, when the response is actually JSON.
When browsed to directly (it doesn’t need any CSRF tokens to be viewed, despite the hash param), we see our script executed.
The cool thing about this bug is that whilst it’s not persistent (the payload is fetched when the page is visited), the code is not present in the request body, therefore avoiding Chrome’s XSS Auditor and IE’s XSS Filter.
Had the content type been set to application/json, the code would have not run (until you start to consider content sniffing…).
Fix
The content type is now set correctly.
Timeline
- 15th August 2013 - Issue Reported
- 21st August 2013 - Acknowledgment of Report
- 21st August 2013 - Issue Fixed