3

I am reading another answer on this website.

It says:

Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered your password before submitting the form.

I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

Community
  • 1
Jake
  • 1,095
  • 3
  • 12
  • 20

3 Answers3

4

I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

Tabs are not isolating entities. That is, cookies are shared between every window a browser has open, including all tabs on those windows. The only exception to this are private/incognito windows. Therefore, if a tab open on evil.com makes an AJAX request to facebook.com, your auth cookies from facebook.com will be sent along with the request. The Same Origin Policy prevents evil.com from reading the response from facebook.com as the domains do not match.

The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

CSRF protection should only prevent unsafe methods - actions with side effects. That is:

the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

So if the site has been implemented with respect to this convention, CSRF protection should only be active for POSTs (technically PUT and DELETE too, but these are rarely used).

As said, the SOP does not stop requests from being made, only the responses from being read. Even with the SOP, evil.com could make a POST request to facebook.com's "Delete Account" page, and if the user was logged in to Facebook, cookies would be sent.

However, if Facebook have implemented CSRF protection using tokens on the Delete Account page then a CSRF token will need to be submitted with this POST. evil.com can make a GET request to facebook.com to the page containing the CSRF token. However, the SOP prevents the response from being read. The SOP protects Facebook's CSRF tokens and prevents CSRF attacks from happening when protected by tokens.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • What is the reasoning for "Therefore, if a tab open on evil.com makes an AJAX request to facebook.com, your auth cookies from facebook.com will be sent along with the request. " I.e. why is it a good idea to, by default, send all the cookies with a request to origin A, even though that request was originated by origin B? – Derek Sep 28 '16 at 05:05
  • 2
    Because it'd break things if we suddenly changed the standard and browser behaviour. See [this answer](http://stackoverflow.com/a/37590970/413180), particularly about a new solution to this, Same Site Cookies. – SilverlightFox Sep 28 '16 at 14:13
  • Is it correct?? ---------- But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case? ------------------------ In this case SOP helps as if there was no SOP evil.com can make request to facebook.com, and would read the responses to know the CSRF Tokens, and therefore rendering them useless. I hope it is clear – Suraj Jain May 28 '18 at 12:53
  • @SurajJain: Yes, the SOP will prevent CSRF tokens from being read cross-domain. – SilverlightFox May 29 '18 at 13:02
  • I did not knew I commented on both of your answer, you write good answer. Thanks it helped me a lot. I have many doubts, can we chat?? – Suraj Jain May 29 '18 at 16:50
  • @SilverlightFox Also security.stackexchange.com/a/72569/166709, this answer first attack example isn't it wrong 'But because of the SOP, the browser prevents this request from being made.' Because SOP never stops the request to be made only the responses we cannot read. – Suraj Jain May 29 '18 at 16:51
1

The malicious domain cannot access the facebook account from a different tab because SOP prevents scripts, which the browser knows came from evil.com, from accessing properties and methods of scripts coming from victim.com .

The problem is that since HTTP is stateless, if a script from evil.com running on your browser were to issue a request to a service on victim.com, the service would see a request coming from your browser (not "a tab on your browser"), and would maybe honor it. To prevent this, the site determines that it will honor the request only if complete with a secret token which the site itself sent to the browser, and which (due to the SOP) is not accessible to any other tab except the one displaying the victim site.

If there was SOP, but no CSRF, and all necessary information (user id, etc.) was available to the evil site either directly or through simple brute forcing, then the evil site could make the browser send to the victim server a command which would be obeyed (for example "add overlord@evil.com to the trusted administrators group").

So you might say that SOP is what makes CSRF work.

LSerni
  • 22,521
  • 4
  • 51
  • 60
  • even without SOP, a response (maybe containing a token) from a server would go to requesting page, not visible to all tabs right ? – Jake Feb 08 '15 at 23:02
  • Same tab, yes. As for it not being visible... that depends on the browser architecture. Whether its Javascript engine allows access to a windows array. Chances are that it would. – LSerni Feb 09 '15 at 06:51
  • @LSerni If chances are it would, then CSRF tokens are of no use right?? As we can get CSRF token that way. – Suraj Jain May 28 '18 at 12:48
  • @SurajJain unless you had SOP. That's why I said that SOP is what makes CSRF work. – LSerni May 28 '18 at 13:02
  • Oh, Yeah right. Also https://security.stackexchange.com/a/72569/166709, this answer first attack example isn't it wrong 'But because of the SOP, the browser prevents this request from being made.' Because SOP never stops the request to be made only the responses we cannot read. – Suraj Jain May 28 '18 at 13:06
0

Because of the way CSRF protection is implemented (e.g. as a hidden form value that is set by the server) if an evil origin can read responses your browser receives from facebook.com it would be able to submit a form to facebook with the correct CSRF token, thus bypassing any of facebook's CSRF protection. Since the same origin policy prevents other domains from reading your browser's responses from facebook.com, this attack is, by default, not possible.

Jon
  • 226
  • 1
  • 5