11

If I provide a public-facing website for users on my website at their own subdomain (e.g. bob.myapp.com) under their own control, can I allow them to execute arbitrary JavaScript without putting my main app server at risk (e.g. myapp.com)? The users would be able to put their own *.js files in the public root of their subdomains.

I have an extremely limited understanding of the JS Same Origin Policy, but I believe that different subdomains count as different origins. Therefore if my main app (myapp.com) is secured from XSS etc., is there anything specific I need to worry about from the users' subdomains that I wouldn't have to worry about for any other external source?

Thanks!

AviD
  • 73,317
  • 24
  • 140
  • 221
  • are you concerned about users of myapp.com or about someone stealing your scripts and using them on bob.myapp.com? because if you don't include data from subdomains in your main html/javascript/... files, i see no way the data would suddenly include themselves.. –  Oct 25 '12 at 18:36
  • The [tag:cross-domain] tag has a nice writeup. Does this help? – pd40 Oct 25 '12 at 20:54
  • @deathApril I'm not so much worried about them stealing my scripts, as I am about them being able to do something funky with AJAX or my cookies. I.e. is there anything special they can do with AJAX (from a different domain) that they couldn't do through HTTP that I wouldn't be guarding against already? –  Oct 25 '12 at 22:25
  • 2
    @deathApril I guess I'm more just worried about what I don't know... Not sure if I'm asking the right questions. If you were going to give users free reign over a subdomain on your site, what would you be worried about? –  Oct 25 '12 at 22:26

2 Answers2

7

Yes, you do have to worry. While the subdomains are mostly isolated from your main domain (thanks to the same-origin policy, there are some exceptions that could pose a risk.

One risk has to do with cookies. Script on bob.myapp.com can set a cookie for myapp.com. This cookie will be sent to myapp.com when the user visits myapp.com. This can be used for session fixation attacks.

For instance, malicious user content can set a session cookie (sessionid=1234) with domain myapp.com. Then when the user visits myapp.com, their browser will send the session cookie set by the attacker. Since the attacker knows the session ID that the user will be using, the attacker can now hijack their session.

One mitigation is to host the user content on alice.myappusercontent.com, bob.myappusercontent.com, etc., while your app is on myapp.com. That should stop these attacks.

The classic reference for information about the same-origin policy and isolation on the web is the Browser Security Handbook. See especially the section on the same-origin policy and on life outside same-origin rules.

D.W.
  • 99,525
  • 33
  • 275
  • 596
6

From my understanding, the same-origin policy will protect AJAX users from each other, but not necessarily your main site. For example, user1.myapp.com will not be able to post requests to user2.myapp.com, but will be able to post requests to myapp.com. You could solve this by forcing the main site to use the 'www' subdomain (www.myapp.com) and forward any request to myapp.com there.

There's a few things that you could do to help secure your main app's cookies. Make sure that all of your cookies' domains are bound to a specific and aren't being wildcarded(e.g., *.myapp.com), otherwise subdomains will be able to access them. You could enable the HttpOnly flag to prevent users from stealing the cookie through javascript. If users are able to use server side languages, place your main application on a subdomain, otherwise they'll be able to access your cookies. It would be wise to enable the Secure flag as well.

For more info on the same-origin policy (And a lot of other web application security topics), take a look at Michal Zalewski's Browser Security Handbook or his book The Tangled Web.

tifkin
  • 241
  • 1
  • 6