Live data from Hacker News

CSRF, CORS, and HTTP Security Headers Demystified

blog.vnaik.com

41–44 of 44 posts

Re: CSRF, CORS, and HTTP Security Headers Demystified

#41
post #24

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 a…

It sounds a bit like the no-cors request that lets you see if the resource was available but won't let you see anything?

I nearly tried to use it once to try and see if a react app was on an intranet or not, but the client decided they didn't want it.

Re: CSRF, CORS, and HTTP Security Headers Demystified

#42

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

http://webkit-cors-vulnerability.trentalancia.com/

https://web.archive.org/web/20171213011409/http://webkit-cor...

Re: CSRF, CORS, and HTTP Security Headers Demystified

#43
post #27
post #21

Earlier quoted context omitted.

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?

Why do you need to run that on the client? And even if you do need to run it on the client for some reason, GitHub has APIs that you could use which have an allow-all CORS policy (as all APIs do).

CORS is defending against a particular class of attack, which is indistinguishable from the scenario you outlined: evilexample.com wants to get access to your private repos on GitHub (which can be reached purely through GET requests).

Re: CSRF, CORS, and HTTP Security Headers Demystified

#44
post #43
post #27

Earlier quoted context omitted.

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?

Why do you need to run that on the client? And even if you do need to run it on the client for some reason, GitHub has APIs that you could use which have an allow-all CORS policy (as all APIs do). CORS is defending against a particular class of attack, which is indistinguishable from the scenario you outlined: evilexample.com wants to get access to your private repos on GitHub (which can be reached purely through GET…

The post I was replying to seemed to be saying that invoking multiple services from the client is "a sign of how ludicrous front end development has gotten."

> Why do you need to run that on the client?

Because it's a good idea (less wasteful) to do that on the client. Rather than wasting bandwidth rerouting it via my own server.

Post reply on HN