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

CORS is not meant to secure an API endpoint

nikofischer.com

Post reply on HN
Print view View original

71–80 of 162 posts

Re: CORS is not meant to secure an API endpoint

#71

Post by brabel »

JanSt wrote: post #19
vbezhenar wrote: post #11

Earlier quoted context omitted.

You can do anything until I close a page. Stealing cookie might allow you to continue after that.

I will have done anything I want to within one second of you logging in. There is no need for later attacks

But the window of opportunity is dramatically reduced if you can only launch your attack while the user is actively using the victim's site.

It's the same reason OAuth uses expiring tokens. If you think that doesn't help and you're surely smarter than the whole security community who has been developing these standards for decades, please write a specification yourself and let us review it to see how great that is.

Re: CORS is not meant to secure an API endpoint

#72

Post by fivea »

iqanq wrote: post #69
fivea wrote: post #64

Earlier quoted context omitted.

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Your personal assertion that CORS somehow decreases se…

If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

> If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

No, not really. Your simplistic example fails to acknowledge that your same-site "lock with no keys" model rendered same-origin-policy completely unusable in projects that fall beyond the scope of a personal hobby project, which left the whole world with no alternative to turn it off. CORS recognizes the absurdity of implicitly assuming that the same origin is the only possible and conceivable safe origin, or even that a site has a single origin.

Therefore, your comparison would actually be between an old lock which was no longer usable and thus forced everyone to go around with no locks, or a lock designed around one of the world's most basic requirements and thus made it possible for the old lock concept to be applicable.

Re: CORS is not meant to secure an API endpoint

#73

Post by eurasiantiger »

iqanq wrote: post #69
fivea wrote: post #64

Earlier quoted context omitted.

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Your personal assertion that CORS somehow decreases se…

If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

A lock with no keys can still be opened with a lockpick or just brute force.

Re: CORS is not meant to secure an API endpoint

#74

Post by pshc »

iqanq wrote: post #69
fivea wrote: post #64

Earlier quoted context omitted.

> CORS does not protect anything from anyone. The same-origin policy stops code from one site reading resources from another site. CORS selectively removes that protection – it decreases security. This comment comes off as either disingenuous or needlessly contrarian, and in the process tries to make points that fall somewhere between completely wrong and miopic. Your personal assertion that CORS somehow decreases se…

If you have a lock with no keys, it is secure, since it can't be opened. As soon as you have one key, the lock is less secure, because now the lock can be opened.

If you have a lock with no keys, it's a non-starter; the door has no purpose. You'd be better off sealing the entrance with bricks.

If you offer a website with an API then CORS is an enhancement in that you're helping protect users from getting owned or hijacked. Alternatively if you can't stomach the risk, you could take down your API, which is about as useful as solving a math equation by multiplying both sides by zero.

Re: CORS is not meant to secure an API endpoint

#75

Post by goto11 »

JanSt wrote: post #31
goto11 wrote: post #27

Earlier quoted context omitted.

It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.

The request does not send resource/cookie data if CORS does not explicitly relax the SOP. CORS does not protect!

A cross-origin POST request can be initiated using a HTML form and does send cookies. CORS provides a safer alternative.

Re: CORS is not meant to secure an API endpoint

#76

Post by jesstaa »

valzam wrote: post #40

If my API doesn't use cookies, is there any reason for me to not fully enable CORS on the server? I.e. using JWT in a typical SPA API scenario.

If you have any unauthenticated routes that you don't want arbitrary websites calling.

> using JWT in a typical SPA API scenario. Is this typical? It's a pretty horrible setup. Cookies have a lot of great features that 'store a JWT in LocalStorage' just doesn't have.

Re: CORS is not meant to secure an API endpoint

#77

Post by pshc »

hsbauauvhabzb wrote: post #57

Why the hell does CORS only support exactly one origin domain or wildcard? Such a silly decision to not allow comma separated values or wildcard subdomains.

Good question... most likely an oversight, or maybe it's to discourage lazy server operators from packing every response's headers with 50 origins.

Re: CORS is not meant to secure an API endpoint

#78

Post by goto11 »

iancarroll wrote: post #33
goto11 wrote: post #27

Earlier quoted context omitted.

It is more complex than that, because certain kinds of cross-site requests has always been allowed. GET and POST requests are allowed, but PUT and DELETE is not. For POST requests you can send the request but not access the result. So CORS can be used to increase protection, by disabling cross-site POST requests, but it can also be used to decrease protection for other requests.

This isn't fully accurate -- you can never prevent cross-site POST requests from being initiated, with or without CORS. For example, CORS is never involved in requests from submissions (which can be triggered via JavaScript). Really CORS cannot be used to lock anything down. The behavior of a server not implementing CORS has the same end result as a server trying to be as restrictive as possible. Both would not send…

> Really CORS cannot be used to lock anything down.

Lets say you have a legitimate website with uses form POST's or GET's to implement cross-site requests to some service on a different domain, authenticated through a cookie. This is vulnerable to cross-site request forging. Changing this to use fetch with CORS can protect against this kind of attack, since the service can now ensure the request is initiated from a legitimate origin.

It is just important to understand what CORS protect against and what it doesn't protect against. You can always forge a request to look exactly like a CORS-compliant request from a legitimate origin - but you still wouldn't have the necessary authentication cookie. If the attacker have somehow gotten access to the users cookie, then there is no need for request-forging in the first place, the attacker can just directly log into the service. If the users browser is compromised it is the same. So CORS protect against the specific scenario where a malicious site visited by a legitimate user forges a request to a legitimate site, misusing the authentication cookie associated with the legitimate domain. In this scenario, the CORS header will indicate the origin of the malicious site, and the server will be able to reject the request.

Re: CORS is not meant to secure an API endpoint

#79

Post by jefftk »

egberts1 wrote: post #65

CORS is about making the web browser behave in a certain manner, and not the web site, and not the end-user. Once fully understood, it is useless mechanism of security theater.

It is not useless, because there is information that the browser has and that it is trusted to protect. Consider a server that returns JSON in response to a POST request, and what JSON it returns depends on the user's cookie. Properly configured CORS headers allow the JSON to be read by some origins and not others.

An attacker with curl will not have the user's cookie and an attacker with a malicious website will not have the right origin.

Post reply on HN