3

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?

Gumbo
  • 643,351
  • 109
  • 780
  • 844
medBouzid
  • 7,484
  • 10
  • 56
  • 86

1 Answers1

6

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.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • Thank you for your answer, I accepted your answer but I still don't understand well what do mean by " if they are any coookie handling vulnerabilities on members.myapp.com" ! I will be thankful if you can explain it more :) Thanks – medBouzid Mar 23 '15 at 20:09
  • @medBo: No problem. Example added. – SilverlightFox Mar 24 '15 at 09:59
  • @SliverlightFox thank you so much for the explanation, In ruby on rails, when I am logged in on memebers.myapp.com then I go to myapp.com I noticed that I am no more logged in because it can't read the cookie from members.myapp.com (they have different scope), also for the log-in I am using just "session" which is crypted by default in rails. is that not sufficient to protect me against that ? – medBouzid Mar 24 '15 at 12:06
  • also I found this post which seems similar to my situation (do you think the answer is correct): http://security.stackexchange.com/questions/15734/is-my-current-method-of-handling-session-cookies-insecure – medBouzid Mar 24 '15 at 12:16
  • @medBo: I'm afraid not. It is the attacker that is setting the cookie at `.myapp.com` level. When the web server reads the cookie it cannot read the domain for the cookie so it will not know it is an attacker set cookie. In this instance you need to create a new session ID after login. – SilverlightFox Mar 24 '15 at 12:17
  • Humm interesting. even I am not sure I understand 100% but I think I've got some clarification and I will for sure go check some security course to understand more so I can protect my app. just I am wondering how some known websites (which allow users to add custom html) do to protect their sites. – medBouzid Mar 24 '15 at 12:30