1

Do 3rd party cookies open up the possibility of CSRF where it may not exist? I was looking at a blog post as well as an IETF draft on same-site cookies that make it seem like 3rd party cookies could make CSRF happen.

My confusion - CSRF happens when session cookies are present during an update request to the web application. Is this because session cookies could be 3rd party cookies? For CSRF to happen, you would still need a) the correct request structure b) session cookies. How do 3rd party cookies help CSRF? The only angle I can think of is that the "third party" would have probably CORS whitelisted the "first party" as a legal requestor domain. If the third party relies solely on Same Origin Policy for CSRF mitigation, then it might be in trouble.

Any possible attack scenarios would be highly appreciated!

  • Why do you think that session cookies cannot also be third-party cookies? Third-party cookies are just any cookies associated with a domain other than the one you're currently on. – Xiong Chiamiov Jan 13 '17 at 16:17
  • Ah! So the reason 3rd party cookies help with CSRF is because they could also be session cookies? But even then, how is it different from my already having an session token from a previously open session? I have also made an edit to better fit this scenario. – katrix Jan 13 '17 at 16:27
  • Current browsers don't really understand the difference between 1st and 3rd party cookies. This makes CSRF attacks possible - although most apps have server-side protections. The original cookie RFC from 1997 mentions "Embedded or inlined objects may cause particularly severe privacy problems..." but this was mostly ignored until the same-site proposal in 2016. – paj28 Jan 13 '17 at 17:02
  • But other than where the request emanates from, I'm not able to find a difference between 1st and 3rd party cookies. Could you please provide an attack scenario for CSRF with 3rd party cookies? – katrix Jan 13 '17 at 17:05
  • 1
    That is the difference. Scenario: you visit an attackers web page, it submits a form to your back with malicious transaction details. – paj28 Jan 13 '17 at 17:57
1

CSRF attacks happen by making legitimate requests to your site, but without the permission of the user.

A standard example is a bank transfer. You are logged into mybank.com. When using that site, you can submit a form to transfer money. Now, you visit malicious-site.com, and in the background the page submits a hidden version of that transfer form; your browser makes the request to mybank.com and sends any mybank.com cookies along with it, and as a result you've transferred money without ever realizing it.

Your browser doesn't know which cookies contain website session data; it just sends all matching ones along with every request.

Similarly, "third-party cookies" are defined as any cookie that belongs to a domain other than the one you're currently visiting.

The current third-party cookie setting in browsers is aimed at privacy, and thus regulates setting cookies. That is, if you load example.com and it makes a request to cool-analytics.com, that secondary request is not allowed to set any new cookies.

The proposed SameSite attribute is instead aimed at preventing CSRF, and thus affects when third-party cookies are sent. In the above bank example, either value (Lax or Strict) would send the request to mybank.com without any of the cookies stored in your browser for that domain that have that attribute set; the result would be that your bank wouldn't recognize your account, and thus would deny the transfer.

  • So in the example you gave above, CSRF could happen (in the absence of Samesite) if example.com was evil and a CSRF payload was sent to mybank.com? – katrix Jan 13 '17 at 19:38
  • Yes, assuming SameSite and other prevention techniques are all absent. – Xiong Chiamiov Jan 13 '17 at 19:52
2

I interpret your question as "By setting my browser to accept third party cookies, am I making myself more vulnerable to a CSRF attack?"

The answer is no. A CSRF attack, also known as "session riding," involves leveraging a cookie that already exists, e.g. a session cookie for a site that you are logged into. It does not involve creating new cookies; in fact, the attacker in a CSRF scenario has no idea what the cookie value is (which is why he must ride on someone else's cookie), and therefore has no means of setting one.

The main risk with third party cookies has to do with privacy. The ability for a site to set a third party cookie means that the first party can tell a third party where you have visited-- for example, Amazon can tell a marketing aggregator that you have browsed a specific product, and that aggregator can then cause ads for that product to appear on Facebook or other sites. This has considerable "creepiness" factor, although there is no actual communication between Amazon and Facebook, and no actual information is being stolen by a third party that wasn't invited to do so by one of the first parties.

  • That was my understanding too. But then I saw the IETF draft for SameSite cookiees (link in question) and I got confused when I saw that the proposed SameSite cookie flag could thwart CSRF – katrix Jan 13 '17 at 18:45

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.