4

The Question:

How do I, as the victim, protect my site from being manipulated into doing something it's not supposed to, on a shared host? Same-Origin policy looks the other way. Most convenient would probably be if I could somehow say something like "my url = always unique origin".

Background:

I have freshly stepped into the world of Javascript and here's my understanding of Same-Origin policy: SOP comes into play whenever two sites on different origins interact, be it via XMLHttpRequest, <script> loading, DOM access via window.open()'s Window reference or through an iframe..

Now it's all good and well in case of a "one site per domain" or "on site per sub domain", but what about shared hosting or shared domains?

Scenario:

Let the good guy's site reside at

http://shared-hosting.tld/~target/administration/

and the attacker's at

http://shared-hosting.tld/~attacker/

Cookies aside, the victim has an authenticated session somehow going on at /administration/ (cookies, local storage, whatever). After this, the attacker tricks the victim into visiting the site on /~attacker/ and using window.open() or iframe on the attacker's site, navigates the victim's browser to /administration/. Now since the attacker has a reference to the Window object and both sites are of same origin, the attacker has complete access to that site's content via DOM manipulation (authenticated and all), because SOP doesn't interfere.

And please don't get tangled up how the victim's /administration/ site authenticates (and maintains) it's users' authenticated status. Unless there's a way to fix this issue that way.

Also:

I understand that I'm only pointing at the Window object and access to DOM through it, because I don't see (know) other ways a a site could maliciously interact with other sites on a shared host in this case, but feel free to highlight other bad intentions relevant to this.

Some thoughts: Javascript checking for legimate page load? Doesn't sound like it would help. Iframing victim's "real" site inside a "welcome" site with sandbox-attribute? Does it disallow parent->child access as well? .. Everything seems to always come back to the "parent" being able to access the "child" without any restrictions.

Gima
  • 143
  • 4

2 Answers2

5

First of all you should read Part2 of the Browser Security Handbook, specifically the same origin policy for DOM access and XMLHttpRequest.

The same origin policy is bounded by the domain name, not the path and this fundamental rule will likely never change. If two web applications share the same domain then they will be able to read each-others data using an XMLHttpRequest. This can be used to defeat CSRF tokens, in an attack similar to the Sammy MySpace worm. The session id may also be accessible if the http_only cookie flag isn't set.

So how do you have two applications properly sandboxed? They must be on a different domains. Sub-domains are free, so in order to use the SOP to sandbox these applications you must use target.shared-hosting.tld and attacker.shared-hosting.tld.

If you read the same-origin policy for cookies you will see that if a cookie is scoped to shared-hosting.tld then *.shared-hosting.tld will be able to access this cookie value. But this is also easy to avoid, just make sure that all cookies are scoped to sub-domain, so www.shared-hosting.tld would be a safe domain.

And this use of the SOP to sandbox applications will work just fine, as long as the target application isn't vulnerable to XSS.

rook
  • 46,916
  • 10
  • 92
  • 181
  • Yeah, I kind of knew these already, but was hoping there'd be _some_ thing I hadn't found that'd enable tighter security.. So counter intuitive! This area feels left out security-wise. As if asking for more vulnerabilities to pop up while there are so many shared web hosts. – Gima Mar 24 '13 at 20:22
  • 1
    @Gima I think the SOP is a wonderful design. XSS and CSRF are still extremely common, but at least we have tools to prevent these attacks. – rook Mar 24 '13 at 20:57
1

The short answer is to put your application on its own domain. Don't share the domain with anyone you trust.

For example, instead of hosting your content at http://shared-hosting.tld/~gima/, host it at http://gima.shared-hosting.tld/ or http://gima.org/. Any good hosting company should support this. (If they don't, pick a different hosting company!) If you use cookies, http://gima.org is safer than http://gima.shared-hosting.tld/, because it will prevent cookie injection by others using the same shared hosting service.

If you do this, the same-origin policy will protect you.

D.W.
  • 98,420
  • 30
  • 267
  • 572