[HN Gopher] CSRF, CORS, and HTTP Security Headers Demystified
___________________________________________________________________
CSRF, CORS, and HTTP Security Headers Demystified
Author : tonyjstark
Score : 99 points
Date : 2021-04-29 18:31 UTC (4 hours ago)
(HTM) web link (blog.vnaik.com)
(TXT) w3m dump (blog.vnaik.com)
| shartte wrote:
| > 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
| still be sent for requests initiated from b.company.com
| lol768 wrote:
| 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.
| capableweb wrote:
| 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.
| shartte wrote:
| 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.
| stock_toaster wrote:
| As far as I know...
|
| 1. cookies can prevent js access (httpOnly flag)
|
| 2. cookies can enforce https only (Secure flag)
| lol768 wrote:
| 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...
| IncludeSecurity wrote:
| Trying to demystify CORS in a couple of paragraphs....good luck
| with that! I think 200 page book would still be too short to
| demystify it. It's a crazy topic
| arcbyte wrote:
| I never understood the difficulty with CORS. It's dirt simple:
| don't send requests across domain names. And if you do, make
| sure you return header(s) from the target resource to
| specifically allow the origin to request it.
|
| All the difficulty seems to be people trying to do crazy,
| esoteric things there's no good reason to be doing in the first
| place.
| politician wrote:
| There's a lot of arcana that you're skipping over. It's easy
| to get CORS partially working on your development machine
| only to watch it fail in production or only fail on certain
| browsers or certain ports. There's silly things that need to
| happen if your application receives traffic from multiple
| domains. Our CORS middleware is ~100 LOC.
| capableweb wrote:
| > Our CORS middleware is ~100 LOC
|
| What?! For responding to OPTIONS requests and setting the
| right header on responses from your backend?
|
| I don't really see the problems you're citing to be a cause
| of "complexity in CORS" either, but more not having a
| proper development setup or similar. CORS is specifically
| about domains. As long as you set the frontend domain as
| accepted origin in your responses from the backend (and
| respond to OPTIONS), you're good to go.
| blacktriangle wrote:
| I wouldn't call trying to write a web app that aggregates
| across multiple services on the client-side doing something
| crazy.
| capableweb wrote:
| But what does that have to do with CORS? If you're just
| writing the client-side code (what runs in the browser),
| then you have no control over 3rd party origins, hence
| either you can use their API or not. Unless you write your
| own backend also, and then supporting CORS is trivial.
| 1vuio0pswjnm7 wrote:
| "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
| to pay their bills. We users are not their customers, we are the
| guinea pigs.
| technojunkie wrote:
| 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.
| cmeacham98 wrote:
| > 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.
| kevin_thibedeau wrote:
| > However, I think first-party isolation causes CORS issues
| like when trying to pay with Paypal on another retail site.
|
| Generate URLs with a time limited token as query param. No
| cookies needed.
| lemarchr wrote:
| Great overview with a minor nit-pick; it's Cross-Origin
| _Resource_ Sharing rather than _Request_ Sharing. It describes a
| server 's willingness to share its resources across origins. The
| client's request isn't the thing being shared.
___________________________________________________________________
(page generated 2021-04-29 23:00 UTC)