Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I want your help on getting more concrete information on a type of vulnerability that I remember vaguely.

I vaguely remember hearing about a year ago that if you set up a webapp on a subdomain, and that webapp gets compromised, then your main webapp (on the root domain) could be compromised as well, because (and this is the part that's vague in my memory) the browser has some assumptions about the two different webapps being the same entity because they're from the same root domain.

I heard that this why Facebook originally hosted their developer forums on a different domain instead of a subdomain of facebook.com; because the forum app was far, far less extensively audited for security problems than Facebook itself, and they didn't want any security holes in the forums to allow an attacker to gain access to Facebook itself.

(To clarify, these attacks are based on the browser, not on some kind of connection between the two servers.)

My question: Do you have the specifics of what those vulnerabilities are and how I could protect against them so I'd be confident that an attacker getting access to one webapp couldn't get access to a different webapp on the same root domain?

share|improve this question
    
Do you mean, that a cookie set on a sub-domain can also be read on the domain itself? –  Manuel Faux Nov 18 '12 at 21:19
    
I think that's one of the issues, not sure whether it's the only one. –  Ram Rachum Nov 18 '12 at 22:19
add comment

4 Answers

up vote 4 down vote accepted

The purpose is to ensure that XSS vulnerabilities in one webapp doesn't allow compromise of the other webapp.

If you run them on two separate domains (e.g., facebook.com and facebookdevelopers.com; not facebook.com and developers.facebook.com), then the browser same-origin policy provides isolation between the two webapps.

This has been discussed at length in several other questions here. Rather than repeating all of the technical details, let me refer you to those other questions:

share|improve this answer
add comment

It has nothing to do with the domain IIRC. It's just that it's running on the same webserver under the same user. So to get segregation, you would need to run the webapp under a different user with limited rights. The user your one site is running under should have no rights on files or directories your other user is running under.

Anyway, if you think your webapp is going to be insecure. Don't put it online.

share|improve this answer
    
I guess you do not recall correctly, because cookies are one issue with the domain that has absolutely nothing to do with whether they're run on the same server. –  Ram Rachum Nov 18 '12 at 22:20
    
Also, all webapps are insecure. –  Ram Rachum Nov 18 '12 at 22:21
    
Yea, you didn't mention cookies, I thought you were talking about running apps on the same server :) –  Lucas Kauffman Nov 19 '12 at 6:20
add comment

This sounds like an insecure cookie scope. If the application is scoping its cookies to .domain.com then XSS in a sub-domain can lead to an account compromise.

As long the applications are on separate servers, they are not sharing the same database account and cookies are scoped properly there shouldn't be a concern.

share|improve this answer
    
aah I see that's what he meant. –  Lucas Kauffman Nov 18 '12 at 20:52
    
Great, I'll take care of that. Do you think there could be anything besides cookies? Perhaps (just wildly brainstorming here) a browser letting a script from one webapp access info in the iframe of the other webapp because they're the same domain? –  Ram Rachum Nov 18 '12 at 22:22
    
@RamRachum, Yes, that could happen, too. See my answer. –  D.W. Nov 18 '12 at 22:59
    
@Ram Rachum that doesn't sound like a SoP abuse, unless you set the x-frame-options... –  Rook Nov 19 '12 at 2:37
add comment

You might be interested in this S.O. thread discussing cookie scope as @Rook describes.

One way to fix this issue is with Channel Bound Cookies (a pending RFC) that is illustrated in the above link.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.