Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSRF, CORS, and HTTP Security Headers Demystified

blog.vnaik.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: CSRF, CORS, and HTTP Security Headers Demystified

#11

Post by capableweb »

shartte wrote: post #6

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks. Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1). If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will…

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#12

Post by shartte »

capableweb wrote: post #11
shartte wrote: post #6

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks. Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1). If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will…

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

The sole reason really is that the contents of a HttpOnly cookie cannot be exfiltrated by an XSS-exploit, while a JWT stored in localStorage could be. This would probably only make a difference if the JWT either has a long lifetime, or is usable outside of the site's origin.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#13

Post by stock_toaster »

capableweb wrote: post #11
shartte wrote: post #6

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks. Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1). If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will…

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

As far as I know...

1. cookies can prevent js access (httpOnly flag)

2. cookies can enforce https only (Secure flag)

Re: CSRF, CORS, and HTTP Security Headers Demystified

#14

Post by lol768 »

shartte wrote: post #6

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks. Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1). If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will…

I believe originally (back in the early drafts of the spec) the concept of a "site" was significantly stricter (based on the origins matching), but it got watered down which was a real shame. I'm not sure why.

c.f. https://tools.ietf.org/html/draft-west-first-party-cookies-0... and https://tools.ietf.org/html/draft-west-first-party-cookies-0...

Excerpts (draft 2):

> If "document" is a first-party context, and "request"'s URI's origin is the same as the origin of the URI of the active document in the top-level browsing context of "document", then return "First-Party".

vs. (draft 3)

> A document is considered a "first-party context" if and only if the registerable domain of the origin of its URI is the same as the registerable domain of the first-party origin, and if each of the active documents in its ancestors' browsing contexts' is a first-party context.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#15

Post by cmeacham98 »

technojunkie wrote: post #3

This is good information, and I'd love to see a write up how Firefox, Chrome, Brave and other browsers can be set up to prevent some of this. For example, Firefox has both first-party isolation mode and now Total Cookie Protection, which isolates cookies and would thus likely prevent CSRF. However, I think first-party isolation causes CORS issues like when trying to pay with Paypal on another retail site.

> which isolates cookies and would thus likely prevent CSRF

CSRF is often done via redirecting you or submitting a form, both of which obviously completely bypass FPI and dFPI (i.e. the cookie part of Total Cookie Protection).

> I'd love to see a write up how Firefox, Chrome, Brave and other browsers can be set up to prevent some of this.

I only use firefox, you'll have to find information elsewhere for other browsers.

CSRF, XSS, Set-Cookie

Need to be fixed server-side, there is little to nothing you can do as the client. CSRF and XSS represent straight-up vulnerabilities in the website. Report to the developer and/or stop using the vulnerable website.

CORS

No additional work needed for security benefits, to reduce its ability to track you: https://addons.mozilla.org/en-US/firefox/addon/privacy-orien...

CSP, X-Frame-Options

You can achieve the same effect of whitelisting 3rd parties by using an extension such as uBlock Origin or uMatrix (warning: no longer in development) in default-deny mode.

HSTS

https://support.mozilla.org/en-US/kb/https-only-prefs

HPKP

Nobody uses this nowadays. Only semi-related, but you can turn on mandatory revocation checking (security.OCSP.require).

Referrer-Policy

    network.http.referer.XOriginPolicy
0=always (default), 1=only if base domains match, 2=only if hosts match

    network.http.referer.XOriginTrimmingPolicy
0=send full URI (default), 1=scheme+host+port+path, 2=scheme+host+port

These apply only to cross-origin requests but that's probably where you care about the referer. Note that the website's Referrer-Policy might override these, I haven't tested that.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#16

Post by lol768 »

stock_toaster wrote: post #13
capableweb wrote: post #11

Earlier quoted context omitted.

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

As far as I know... 1. cookies can prevent js access (httpOnly flag) 2. cookies can enforce https only (Secure flag)

I think 1 is the only real argument.. 2 seems less and less relevant with HSTS.

I suppose the other thing you can do with cookies is use cookie prefixes. __Host probably makes no sense in the context of localStorage/sessionStorage anyway though, since they're all tied to the exact domain.

Having HttpOnly set only buys you so much, too. Sure, you can't steal the session from an XSS vector but your code can still do AJAX queries as the victim, potentially set up a JavaScript shell that works whilst the tab is open...

Re: CSRF, CORS, and HTTP Security Headers Demystified

#17

Post by 1vuio0pswjnm7 »

"It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks."

"As an added bonus, many of the mitigations on this page can be applied at the proxy server (CSP, HSTS, HPKP) or network level (better server proxying to remove the need for CORS), and only the CSRF and XSS protections really need to be added to the application."

If I add a line to the localhost-bound forward proxy that the aplication uses so that "SameSite" is added to every cookie, then it appears the second statement is misleading.

As a user, I rely on a (forward) proxy. Much easier for me to focus on the proxy than trying to make sure every application^1 is doing the right things.

Both parties to an HTTP transaction can use proxies to execute mitigations. And as the author states, the ones he is mentioning are only some of the possibilities.

1. Especially ones that we do not compile from source and are distributed by "tech" companies that rely on online advertising as their main source of revenue. We users are not their customers, we are the guinea pigs.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#19

Post by livre »

capableweb wrote: post #11
shartte wrote: post #6

> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks. Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1). If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will…

What reason is there even to use Cookies anymore? Use LocalStorage instead and get better protection as it's not by default being sent around.

Cookies work when JavaScript is disabled or has failed to load (your basic functionality should work without it), localStorage doesn't. So unless we are talking about SPAs cookies are generally the better choice.
Post reply on HN