81–90 of 162 posts
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
I found comparing CORS with CSP helpful in understanding both concepts: https://stackoverflow.com/a/50726191/1472186 (I wrote the answer)
Also, like others have pointed out, CORS or CSP depends on the client (browser) to enforce it. So it doesn't protect against attacker with customized clients.
Earlier quoted context omitted.
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 l…
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)
Earlier quoted context omitted.
> 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 l…
AFAIR it’s never the server that rejects the request in a CORS scenario: The server indicates what origins are allowed to call the API and the browser cancels the request on behalf of the user if called on a website that’s not on the allowed list. The server canceling the request based on a header would be insecure since the client can send arbitrary headers.
Otherwise a malicious site could just forge the Origin header in the preflight request.
Earlier quoted context omitted.
although browsers only accept a single origin domain or wildcard as cors header, the server can trivially handle the multi domain use case. on preflight request, check the location header in the request, and if it belongs to a defined whitelist, set the cors header on the response to that domain or subdomain. I don't know the why, but I can imagine that since there is a reasonable work around, browser implementers pe…
I understand how it works, but adding unnecessary conditional server side logic to fix a limited spec is a poor solution.
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.
Earlier quoted context omitted.
AFAIR it’s never the server that rejects the request in a CORS scenario: The server indicates what origins are allowed to call the API and the browser cancels the request on behalf of the user if called on a website that’s not on the allowed list. The server canceling the request based on a header would be insecure since the client can send arbitrary headers.
JavaScript in an uncompromized browser cannot send arbitrary headers. See: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_... Otherwise a malicious site could just forge the Origin header in the preflight request.
CORS is supposed to secure the user’s data. You are NOT supposed to send global server-side data (like secret keys to third party services) through CORS.
Consider that any user data shown “publicly” to all other authenticated users (eg user icon via Facebook’s API) can be used to deanonymize that user, because someone can just create a fake account, exfiltrate the images, and do a reverse image search.
But the author is right, CORS is just one part of the equation. Together with SRI, they can definitely make secure cross-chain interfaces.
The actually insecure alternative back in the day was JSONP. Read my stackoverflow answer from OVER 10 YEARS AGO: https://stackoverflow.com/a/5447005