2

On the client side, a http request sent from webpage A that targets website B will cause all cookies belonging to Website B to be sent to B (even when A does not belong to B).

I do not understand why the cookies behavior has been designed this way. Isn't it obviously insure and the root reason behind CSRF (cross-site request forgery)?

I know nowadays "same-site cookie" is on the way. But I want to know what was the motivation of the old insecure design.

  • i don't see how it's insecure given the other protection mechanisms in place; they've always said to use POST for anything half-way important. – dandavis Apr 17 '17 at 22:06
  • @dandavis: CSRF attacks aren't prevented by using POST. An attacker could create an auto-submitting form pointing to the vulnerable page. – Benoit Esnard Apr 17 '17 at 22:08
  • @BenoitEsnard: true, but that's a much harder attack than a mere link-based one i could link from here and have stopped by POST requirements. My main point still stands: there's plenty of arrows in the W3 quiver to prevent such things. How many breaches are done by user agents that respect such rules (as opposed to CURL et al)? CSRF is one of the most-understood attacks, and the least-useful in that it's trivial to prevent. – dandavis Apr 17 '17 at 22:19
2

According to Wikipedia, the concept of cookies comes from Lou Montulli in June 1994. The HTTP protocol was still very young.

Since HTTP lacks some fundamental security features, such as encryption, I guess security wasn't their priority. I also doubt that any of the people working at that time could have anticipated that HTTP would be so wildly used nowadays, even by evil actors.

It's way easier to look back at all the vulnerabilities / specs flaws we found in the latest 20 years, that to anticipate them all in the first place.

As you've said, the SameSite cookie attribute is on the way to fix that flaw. Until its support by browsers, developers should use standard CSRF mitigations techniques.

  • samesite cookies would kill advertiser spying, so as long as your browser's maker sells ads (3/4 do), don't hold your breath on this getting implemented. – dandavis Apr 17 '17 at 22:05
  • @dandavis: Well, Google sells a lot of ads, and have implemented it more than a year ago, so I guess it's just a matter of time before other browser vendors do the same. But you're right, we'll need to support older browsers for years before migrating. – Benoit Esnard Apr 17 '17 at 22:14
  • well that's good news (to me) about google. i'm not sure about how it handles WebWorkers, but the rest seemed to be a good idea... – dandavis Apr 17 '17 at 22:28
-1

If I got it right, it's about 3rd. party cookies. This approach is specially perfect for advertising sites for instance(not only them)

As a page of domain A has a data of domain B, the resource(let say an image) is respond with a cookie(B set cookie for it).
Now when you go to domain C which has another resource from domain B, here domain B can identify you visited the domain A too.

Some browsers support disabling 3rd. party cookies, but not enabled by default(not sure)

Whenever any request is made for a domain X, all of the cookies will be sent with the request of course by browser.

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.