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

141–150 of 162 posts

Re: CORS is not meant to secure an API endpoint

#141

Post by deckard1 »

JanSt wrote: post #6
outsidein wrote: post #2

What is missing is a guide how to replace the bad pattern bey a good one. Add a function that the user can login, create his individual API key, and store in a a secure way on his client (e.g. any credential store)

httpOnly secure same-site cookie. Even storing a session token in localStorage is not a problem if you‘re protected against xss (if your not, nothing else will protect you anyway)

probably worth mentioning is Chrome last year started assuming a default SameSite cookie of "Lax", rather than the previous default of "None".

Let's just say, certain people were caught with their pants down on that one. Notably, Amazon. If you go to watch the bonus content for The Expanse on Prime Video, you will notice that it does not work in Chrome but works fine in Firefox (as of a few weeks ago, at least).

If your site depends on SameSite None, you need to explicitly set it now.

Re: CORS is not meant to secure an API endpoint

#142

Post by FpUser »

JanSt wrote: post #55
goto11 wrote: post #54

Earlier quoted context omitted.

It was not possible to initiate a PUT or DELETE request from browsers until XMLHttpRequest with same-origin-policy was introduced.

That doesn't matter at all in a security context. POST can (and is used) for everything DELETE and PUT are used. Adding DELETE and PUT did not relax anything. The only question is whether requests are restricted (i.e. in terms of sending resources like cookies).

One can use GET as well. It is up to whatever sits behind the browser to interpret request and it can do as pleases. I personally use JSON based RPC in my apps.

Re: CORS is not meant to secure an API endpoint

#143

Post by pictur »

HL33tibCe7 wrote: post #34

Having read the original article ( https://designkojo.com/post-drupal-using-jsonapi-vuejs-front... ), it’s quite clear that the author doesn’t know enough about what he’s talking about to write these kinds of posts. I wouldn’t usually say this, but on security-critical topics like this, winging it just isn’t good enough. People will be misled by this article.

Ignorance is the greatest wisdom. I would love to hear the comments of the owner of this article on many issues in person

Re: CORS is not meant to secure an API endpoint

#144

Post by systemvoltage »

goto11 wrote: post #9

CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side. CORS protect against the scenario where a malicious site tricks an…

> CORS protect against the scenario where a malicious site tricks an unmodified browser to make a cross-site request to a legitimate site. If the user has an authentication cookie for the legitimate site, the cookies will be sent along with the request. So the malicious site can perform transactions in the legitimate site on behalf of the user, despite not having direct access to the authentication cookie.

Can you please give an example of this?

Re: CORS is not meant to secure an API endpoint

#145

Post by earthboundkid »

systemvoltage wrote: post #144
goto11 wrote: post #9

CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side. CORS protect against the scenario where a malicious site tricks an…

> CORS protect against the scenario where a malicious site tricks an unmodified browser to make a cross-site request to a legitimate site. If the user has an authentication cookie for the legitimate site, the cookies will be sent along with the request. So the malicious site can perform transactions in the legitimate site on behalf of the user, despite not having direct access to the authentication cookie. Can you pl…

You are logged into example.com and see a page from evil.com in an ad iframe on a third site. Evil.com tells the browser to post example.com/transfer-money?dest=badguy.

Re: CORS is not meant to secure an API endpoint

#146

Post by zdragnar »

systemvoltage wrote: post #144
goto11 wrote: post #9

CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side. CORS protect against the scenario where a malicious site tricks an…

> CORS protect against the scenario where a malicious site tricks an unmodified browser to make a cross-site request to a legitimate site. If the user has an authentication cookie for the legitimate site, the cookies will be sent along with the request. So the malicious site can perform transactions in the legitimate site on behalf of the user, despite not having direct access to the authentication cookie. Can you pl…

It is a solution for AJAX requests to the same problem that CSRF tokens solve for html forms.

Imagine a user is logged into facebook, and visits legitimate website X, which has been hacked to inject malicious script Y.

Malicious script Y makes a bunch of API calls to Facebook; since the user has been logged in, the Facebook cookies are sent along with the request by the browser. Malicious site Y could delete your posts, make you join pro-Nazi pages, or exfiltrate your network.

With CORS in place, the requests would be denied, because API requests can be set up to reject any requests that are not from a specific list of domains.

This is a bad example, because Facebook doesnt rely just on cookies, and in fact does have an SDK for making API requests from third party sites. The principle remains, however, if that were not the case, then CORS would be one possible remedy to the problem.

Re: CORS is not meant to secure an API endpoint

#147

Post by notreallyserio »

2bitencryption wrote: post #135

Ah, CORS. One of those rare topics to fall under the category of: "I have no idea how it works. I run into an issue with it. I spend all day researching, reading documentation, blog posts, etc, explaining it. I finally come to some understanding. Three weeks later, start the process again." To my weak-minded brain, the sticking point always comes down to: CORS/SOP is a policy enforced by the browser , correct? The cl…

In addition to what jordanlev said: the server tells the client that the origin the client sent is allowed. It's basically a boolean but for some reason the access-control-allow-origin header specifies an origin URL.

Re: CORS is not meant to secure an API endpoint

#148

Post by icedchai »

TheCoelacanth wrote: post #137
icedchai wrote: post #111

Earlier quoted context omitted.

In your scenario, the attacker with the web site could simply proxy requests to that CORS "protected" end point (through their own web site, on the back end.) That would allow them to read the JSON response, and deliver it to the browser with alternate headers.

In that case, the attacker's endpoint will be on a different domain than your endpoint, so the cookie from your domain won't be included in the request.

That is true! But if they find some other vuln that gets them the cookie perhaps the proxy could still be of use.

Re: CORS is not meant to secure an API endpoint

#149

Post by unclebucknasty »

TheCoelacanth wrote: post #134
unclebucknasty wrote: post #122

Earlier quoted context omitted.

> All browser users would be worse off without CORS. You and fivea are conflating functionality with security. Yes, it may be functionally desirable for an app to allow cross-origin requests, as enabled by CORS. But, you're granting permissions, and that is opening things up, possibly making them less secure. I think great-grandparent's point highlighting this is worth making, given that there is so much confusion ar…

The three pillars of security are confidentiality, integrity and availability . Letting people have access to things that they are supposed to have access to is part of security. You don't get perfect security just by denying everyone access to everything.

Agreed.

Re: CORS is not meant to secure an API endpoint

#150

Post by hsbauauvhabzb »

withinboredom wrote: post #86
hsbauauvhabzb wrote: post #68

Earlier quoted context omitted.

I understand how it works, but adding unnecessary conditional server side logic to fix a limited spec is a poor solution.

Just imagine having everyone’s localhost and whatever other development sites exist bloating the header of GitHub’s API

Just imagine accidentally reflecting every origin as a wildcard because you misconfigured your dynamic acal response headers to reflect whatever the current origin is.
Post reply on HN