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:
- Signed up for UserVoice
- 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.
- 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:
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.
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.