Can different subdomains of the same app prevent m

2019-02-25 18:52发布

问题:

In my Rails app i have 2 subdomains,

one : members.myapp.com which is the area shared between all members (where they can login and manage their accounts)

Two : each member has its own website on a subdomain like this : member1.myapp.com, member2.myapp.com, member3.myapp.com etc...

Let's imagine that user1.myapp.com run a malicious js code in his site, can members.myapp.com be affected through XSS or other attacks?

回答1:

They would be able to set cookies that can be read by members.myapp.com - so if they are any coookie handling vulnerabilities on members.myapp.com then they could possibly exploit these. An example of cookie poisoning could be session fixation.

XSS would not be possible unless both domains opted in. i.e. they would both have to contain the following code.

document.domain = 'myapp.com';

Unless members.myapp.com is doing this, the Origin will not be shared between subdomains.

Example of a cookie handling vulnerability

As mentioned, one type is Session Fixation.

Now, say the attacker visits members.myapp.com and is given a random session cookie: set-cookie: session_id=123456.

The attacker then sends an email to an administrator saying there is a problem on his domain user1.myapp.com.

The attacker has some JavaScript code hosted on user1.myapp.com:

document.cookie = "session_id=123456;domain=myapp.com";

The victim (an administrator of myapp.com) goes to the attacker's page and receives the cookie.

The admin later goes to members.myapp.com and the logs into their administrator level account. However, as the attacker has give the attacker their session ID (123456) in a cookie that can be read by members.myapp.com (as it was set at myapp.com level) the attacker is now logged in as the administrator. i.e. the attacker has managed to make the administrator share his session so when the administrator logs in, the attacker sharing his session is also logged in.

This is just one example of a cookie handling vulnerability. In this case the system should issue a new session cookie after login to prevent the session fixation attack.