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.