Watch out for vulnerabilities in 3rd party applications on your site's domain.

In the past few years it has become common for site owners to run 3rd party tools on their site. A good example would be Wordpress or other blogs, installations of which are typically located on a subdomain such as http://blog.example.com. Often times these addons are not even hosted by the site owner, instead they are hosted by the third party and the domain owner simply sets up a DNS CNAME record to direct traffic. Recall that any subdomain can set its document.domain to any right hand qualified fragment of its domain in order to obtain permissions through the same origin policy. Many sites now set their document.domain to the top level domain, thereby allowing any scripts running on subdomains to obtain same origin access to anything on the site.

Despite its danger, this practice is so widespread that even Facebook was known for doing it frequently. I say that in the past tense because I was able to take advantage of this to find multiple cross site scripting vulnerabilities affecting http://facebook.com. After I reported the issues Facebook performed a complete audit of everything hosted on their subdomains. As a result, sites like the developer forum and bugzilla have been moved to Facebook.net.

It all started when I noticed that Facebook had once set up a UserVoice (http://www.uservoice.com) account, accessible via http://feedback.developers.facebook.com but hosted by UserVoice. At some point they had chosen to close their account, but they left the domain settings untouched.

I followed the following process to craft a proof of concept exploit:

1. Signed up for UserVoice
2. Purchased the most expensive $500/Month account, with a 30 day trial. This account allows for custom HTML, Javascript, and domains.
3. Configured the account to use the previously active http://feedback.developers.facebook.com domain. No confirmation process was required and UserVoice allowed me to take the domain even though it had been previously used by an inactive account.
4. Wrote a proof of concept exploit which set the site document.domain to "facebook.com" and then hijacked the user's session.

In this case, Facebook was able to fix this vulnerability simply by disabling the http://feedback.developers.facebook.com domain.

I also notified UserVoice about this issue, along with a related issue that would allow a hacker to hijack the sessions of UserVoice users. Here was their response:

Hi George,

First of all thank you for bringing these issues to our attention and for working with us to get them sorted. Our next steps are to:

* Modify the way sessions are created so that they are site-specific (x.uservoice.com). Once a session is created on a specific subdomain it cannot be reused on any others.
* We will prevent any new account from using the cname of a previous account (even if it's been deleted).

We will have this in place before the 14th and I'll let you know when that's the case.

Thanks again,

Richard White
CEO, UserVoice.com

Next, I was able to identify multiple publicly disclosed cross site scripting vulnerabilities present in the outdated version of Bugzilla once located at http://bugs.developers.facebook.com (now moved to http://bugs.developers.facebook.net). As with the UserVoice exploit, I was able to quickly craft the same session hijacking proof of concept exploit.

So what's the conclusion to all this? Don't allow your site to be exposed to vulnerabilities in 3rd party tools such as Wordpress, UserVoice, GetSatisfaction, Tumblr, etc. by hosting them on subdomains. If your primary site's document.domain is a top level domain then any vulnerability in a 3rd party site located on a subdomain is the same as a vulnerability in your site (And you have much less control over the security of 3rd party tools). The only case in which it is truly safe to host 3rd party applications on a subdomain is if your primary site uses a document.domain starting with "www" or similar.