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

31–40 of 44 posts

Re: CSRF, CORS, and HTTP Security Headers Demystified

#31

Post by bugmen0t »

hsbauauvhabzb wrote: post #29
lol768 wrote: post #14

Earlier quoted context omitted.

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 "reques…

Any good references on the definition? I’ve always found it awkward.

The concept of a Site is defined here https://html.spec.whatwg.org/multipage/origin.html#sites

It's basically an origin, but disregarding subdomains.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#32

Post by stephenmcirl77 »

myfonj wrote: post #30

> access-control-allow-origin: The list of origins allowed to make requests. Is it really a list? AFAIK, and according to MDN: "Only a single origin can be specified." https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

Yep, that's correct. Only a single origin is supported. The implementation on the backend server/proxy may use a lookup list, and return the specified origin if that exists in the list. As called out in the post too, * is a valid one (as is null) but is not recommended.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#33

Post by rndgermandude »

myfonj wrote: post #30

> access-control-allow-origin: The list of origins allowed to make requests. Is it really a list? AFAIK, and according to MDN: "Only a single origin can be specified." https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

You're correct, it's not a list. A browser will sent an Origin header during the OPTIONS preflight that the server can check and then return back that value in an Access-Control-Allow-Origin response header, or it can return * without any checks if e.g. it's a public API endpoint anyway and expected to be hit by fetch/XHR traffic from all kinds of places.

Non-browser clients (and browser for non-CORS and/or "simple" requests) will not usually send any CORS headers and preflight requests, so you should account for that when building a web API. Non-browser clients can of course just fake any browser header and request they want, so the Access-Control headers are NOT a substitute for real access control/authentication.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#34

Post by goto11 »

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 are sent with the first request, so the site can customize the response based on user ID. If the site uses local storage to identify the user , it will first have to send some bootstrap page which loads the id and sends it back. Much more cumbersome.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#35

Post by rndgermandude »

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.

Other than the security implications of HttpOnly (and what it means for XSS), it's also convenience, and works well for small values you want to send with every request anyway, such as user session ids of logged in users and other forms of access tokens[0]. Your frontend code does not have to keep track of such values itself in localStorage (and maintain things like expiration) and it does not have to manually stuff it into each request itself, and so on.

localStorage and IndexedDB on the other hand are most useful for frontend only stuff that the server doesn't need to ever see, and for large chunks of data that you do not want to send with every request, and app-domain specific caches that would be awkward to implement using regular browser caches or ServiceWorkers.

[0] For example, cloudflare implements their "browser checks" anti-DDOS-protections by setting some token in a cookie so your browser isn't hit with that check page on every navigation (at least in theory, TOR users and a lot of VPN users have different experiences). Since the browser will automatically manage and maintain such a cookie, the actual websites behind cloudflare do not need any changes whatsoever to their code.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#36

Post by johncolanduoni »

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)

Local storage is per-origin, so anything set on an https page for a certain domain will not be readable on an http page and vice-versa.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#37

Post by hnra »

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.

Doesn't local storage imply JS? How would you serve client with JS disabled?

Re: CSRF, CORS, and HTTP Security Headers Demystified

#38

Post by tehbeard »

lol768 wrote: post #14
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 "reques…

> but it got watered down which was a real shame. I'm not sure why.

I think (and this might just be an old wive's tale) it was related to the browser connection limits being per domain, and so subdomains + looser cookie origins was a band aid for it.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#39

Post by evanspa »

> Note that CORS preflight requests are not made for GET HEAD POST requests with default headers.

I really wish the author included an explanation for this. What are "default headers"? What special header(s) needs to be on the request in order for a preflight request to be made?

Re: CSRF, CORS, and HTTP Security Headers Demystified

#40

Post by horsawlarway »

evanspa wrote: post #39

> Note that CORS preflight requests are not made for GET HEAD POST requests with default headers. I really wish the author included an explanation for this. What are "default headers"? What special header(s) needs to be on the request in order for a preflight request to be made?

If you're genuinely interested, MDN has some pretty great documentation on the subject.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

For your specific question, this is the relevant section of the above link

----

Apart from the headers automatically set by the user agent (for example, Connection, User-Agent, or the other headers defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as a “CORS-safelisted request-header”, which are:

Accept

Accept-Language

Content-Language

Content-Type (but note the additional requirements below)

Post reply on HN