1

Consider the standard CSRF protection of a Ruby on Rails application: a CSRF token is embedded in the HTML page, while at the same time stored encrypted as part of the session cookie. When making a request, the embedded token is sent along the cookie, and the server can then check whether they match.

Suppose now to open the same application in two separate browser tabs. They will have different CSRF tokens and as such different session cookies. However, when I make post requests there are no CSRF issues.

This raises the question: what is the scope of a browser cookie? If the scope were global (i.e. valid across different browser tabs), then as soon as I opened the second tab the first session cookie would have been overwritten (as they come from the same origin and have the same key). But I can make POST requests from the first tab, and they do not fail, implying that each tab has its own set of cookies.

On the other hand, if I log in in one tab and open a second one, I obviously have an application session in the second tab too, implying that cookies are shared across browser tabs.

So then, what is the true "scope" of a browser cookie?

Improve this question
3

... two separate browser tabs. They will have different CSRF tokens and as such different session cookies.

They don't.
The same cookie is used whenever you access the same site within the same browser, i.e. the scope of the cookie is not the current tab but the current browser.

That's why it is usually also impossible to login into the same site with the same browser at the same time. There are browser extensions to limit the scope of the cookie to the current tab in order to make multi-login possible but by default the scope is the current browser.

To be more precise: if you switch to a different browser you have a different context for cookies. If you switch to a different browser profile you get also a different context. Same when switching to private mode. But if you switch only to a different tab or window then you have the same context.

Note that a cookie might be additionally restricted by the path on the site using a path argument and might also include subdomains using the domain argument. See the section "Scope of cookies" at MDN:HTTP cookies for more details.

Improve this answer
6
  • Unless i am overlooking something, they really do have different CSRF tokens, it is visible in the markup as a meta tag (for Rails applications that is). Or am i missing something trivial? – daniel f. Jul 12 '18 at 13:25
  • @danielf.: They will have the same session cookie. However, I think that Steffen Ullrich's answer partially answer your post, perhaps an addendum regarding the use of CSRF tokens in cookies could be added to explain the difference and why the scenario you describe happens. – Yuriko Jul 12 '18 at 13:36
  • @Yuriko: i guess then the question is more about how Ruby on Rails handles CSRF token. Thank you both for your input. – daniel f. Jul 12 '18 at 14:00
  • @danielf.: trying some ruby on rails using application like airbnb.com I get the same _csrf_token in all tabs on the same browser. – Steffen Ullrich Jul 12 '18 at 14:01
  • @SteffenUllrich if I open the exact same page, then yes, the tokens are the same. However if i open different pages of the same application, the token differs. I opend two different projects in gitlab, the tokens are different, and POST requests go through on both tabs. I guess my understanding of how CSRF protection in Ruby on Rails works is still not complete. – daniel f. Jul 12 '18 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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