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

21–30 of 44 posts

Re: CSRF, CORS, and HTTP Security Headers Demystified

#21

Post by arcbyte »

blacktriangle wrote: post #7
arcbyte wrote: post #4

Earlier quoted context omitted.

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.

I wouldn't call trying to write a web app that aggregates across multiple services on the client-side doing something crazy.

That's very crazy. The fact that you don't think it's crazy is a sign of hoe ludicrous front end development has gotten.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#22

Post by izolate »

> The reason access-control-allow-origin cannot be '' when access-control-allow-credentials is set is to prevent developers taking the shortcut of adding a and then forgetting about it altogether - this behaviour forces developers to think about how their API is going to be consumed.

Instead developers take the shortcut of creating middleware that captures the Origin header in the request and mirrors it into the response, effectively creating the same insecure ruleset.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#23

Post by LegionMammal978 »

As I understand it, the main purpose of CORS is to prevent information from being leaked by domains other than the current one using JavaScript, since the browser will always send those domains' cookies in all requests. In that case, why doesn't JavaScript have a method of sending a request without any cookies? Would it still somehow vulnerable to CSRF attacks? Is there simply no demand for the feature? Are there other issues with the concept that I don't know about? (The main context of this is from an attempt to create a client-side JavaScript application which calls a certain public API, which turned out to be impossible since it did not implement CORS headers.)

Re: CSRF, CORS, and HTTP Security Headers Demystified

#24

Post by saurik »

LegionMammal978 wrote: post #23

As I understand it, the main purpose of CORS is to prevent information from being leaked by domains other than the current one using JavaScript, since the browser will always send those domains' cookies in all requests. In that case, why doesn't JavaScript have a method of sending a request without any cookies? Would it still somehow vulnerable to CSRF attacks? Is there simply no demand for the feature? Are there oth…

I totally agree with you. That said, there are people who disagree with both of us and believe that it is reasonable for people to use IP-address-based authorization schemes--which, for avoidance of doubt, might simply be "I am behind a firewall (but all the IP addresses behind my firewall are public addresses, and so cannot be disallowed for this purpose by IETF CIDR)"--and so keep insisting that you should not be able to use a script on a website to "port scan" behind someone's firewall and attack their other half-protected file servers, computers, and printers. This is then why a mechanism actually does exist to say "send a request without cookies"... but it is only for a GET and, this being the key limitation, the script isn't allowed to see the value of what was returned or even if it succeeded or failed (although I can't for the life of my find any documentation on this right now despite swearing I was just trying to use this last week before realizing the response body limitation). Otherwise, this whole thing always feels like some half-assed attempt at DRM :/.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#25

Post by 1vuio0pswjnm7 »

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

What are these "default" headers. I have seen access-control-allow- response headers when making HTTP requests. I do not send unnecessary headers. Perhaps some of the ones I do not send are considered "default".

"Thus CORS is a way of selectively loosening security not of tightening it."

Proxy config I use scrubs all CORS headers. As the author states, CORS is irrelevant outside the browser. I make most HTTP requests outside the ("modern") browser anyway.

"Overall, as the web grows in terms of features and complexity, the attack surface also grows correspondingly large."

Job security for some people, I guess.

Apparently there is no sufficient incentive to simplify things (by subtraction not addition).

Re: CSRF, CORS, and HTTP Security Headers Demystified

#27

Post by jeswin »

arcbyte wrote: post #21
blacktriangle wrote: post #7

Earlier quoted context omitted.

I wouldn't call trying to write a web app that aggregates across multiple services on the client-side doing something crazy.

That's very crazy. The fact that you don't think it's crazy is a sign of hoe ludicrous front end development has gotten.

If I'm writing say a code editor on example.com, is it "crazy" that I'd want to fetch a list of projects from GitHub.com?

What are you saying?

Re: CSRF, CORS, and HTTP Security Headers Demystified

#29

Post by hsbauauvhabzb »

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…

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