it's one of my favourite interviews questions and very few people get it right.
Developers don't understand CORS (2019)
161–170 of 285 posts
Re: Developers don't understand CORS (2019)
#162Earlier quoted context omitted.
Ouch! Ok, I wasn't aware text/plain was also one of the whitelisted values and lets you do that. That looks pretty bad indeed.
Or good, depending on who you are. I find CORS to be pain in my butt by effectively preventing ad-hoc client-side browser tools from being able to use most APIs, and forcing me to do bullshit make-work involving a server side component and certificates just to work around this + HTTPS, at which point I may as well just have my "backend" shell out to `curl`, which happily doesn't care about any of that nonsense.
I mean, it still relies on a vulnerable configuration (not checking the content type)
For adhoc dev tools, you could also just disable CORS: https://berkkaraal.com/notes/other/chrome-disable-cors/
Re: Developers don't understand CORS (2019)
#163Earlier quoted context omitted.
Yes, but if ads do it, that would at worst make the ad server vulnerable, not your server.
You apparently understand less than me. The little I do understand is that CORS is protection for a site's user , not the site.
It's a protection of site's business model.
Re: Developers don't understand CORS (2019)
#164Earlier quoted context omitted.
Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)
Obviously JSON is a subset of text/plain, so I don't know what people were expecting? For text/plain to mean "plaintext, excluding any string that could possibly parse as any of the other named formats that have a plaintext representation"? Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?
I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request.
I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data
> Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?
For better or worse, yes, or at least as one layer. That's one of the rationales behind the "safe" requests AFAIK.
And this wouldn't be the first time, protocols are made intentionally incompatible on the wire, so an attacker can't smuggle one inside the other. That's the entire reason for WebSocket's weird handshake dance and the "xor encoding" it applies to messages from the client.
Re: Developers don't understand CORS (2019)
#165Earlier quoted context omitted.
Or good, depending on who you are. I find CORS to be pain in my butt by effectively preventing ad-hoc client-side browser tools from being able to use most APIs, and forcing me to do bullshit make-work involving a server side component and certificates just to work around this + HTTPS, at which point I may as well just have my "backend" shell out to `curl`, which happily doesn't care about any of that nonsense.
I mean, it still relies on a vulnerable configuration (not checking the content type) For adhoc dev tools, you could also just disable CORS: https://berkkaraal.com/notes/other/chrome-disable-cors/
> I mean, it still relies on a vulnerable configuration (not checking the content type)
Unless I'm misunderstanding the claim, that's not "vulnerable configuration", but extreme lunacy - basically treating parsing outcome as access control. "Did the payload parse correctly as JSON? No -> go away; Yes -> oh that must mean you're supposed to be here". I'm at a loss of words that this is even a problem in practice.
> For adhoc dev tools
There's a whole space between "adhoc" and "dev" tools, though, and this is what interests me the most. Yes, when I'm in full dev mode, I can make my computer do anything I need to. But more often than that, I'm just a user that wants to exercise some basic freedom of computing - to remove some toil or frustration from daily computing experience - without switching my hat from "user" to "developer". That's what CORS has been successfully defeating, by forcing any ad-hoc non-dev tool I could make for myself to require being in "developer mode" to use it.
Re: Developers don't understand CORS (2019)
#166Earlier quoted context omitted.
I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…
That's not quite correct. POST requests with certain Content-Type headers, such as text/plain or multipart/form-data, will still be allowed without any kind of preflight. If the web application doesn't check the Content-Type header strictly, then you've got a problem.
You're right, I forgot that form requests bypass the preflight.
Re: Developers don't understand CORS (2019)
#167Earlier quoted context omitted.
Obviously JSON is a subset of text/plain, so I don't know what people were expecting? For text/plain to mean "plaintext, excluding any string that could possibly parse as any of the other named formats that have a plaintext representation"? Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?
I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request. I guess the same trick might work with urlencoded forms, but it wouldn't work with multipart/form-data > Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"? For better or worse, yes, or at least as one layer. That's on…
> I wasn't aware that plaintext was one of the whitelisted types that are allowed without a preflight request.
Until now, I wasn't aware of that either. My response is about the fact you can massage the plaintext part to contain valid JSON somehow being a problem, one that apparently is a security issue in practice.
We're not talking about some clever polyglot quine like those COM executables that are somehow also valid Bash and C code and PDF files or something. text/plain is a superset of everything that can be represented by plain text, which includes approximately all code and data formats, JSON and XML included.
> And this wouldn't be the first time, protocols are made intentionally incompatible on the wire, so an attacker can't smuggle one inside the other.
I need to learn more about it, thanks for pointing it out.
Though at the surface, it reads to me like removing a feature. "Smuggling a protocol inside the other" sounds to me like an important feature, or perhaps more accurately, I find myself being part of the "attacker" population much more often than not. "Tunnel $whatever through HTTPS because corporate/ISP firewalls" is both a meme and success story for plenty a SaaS at this point.
Re: Developers don't understand CORS (2019)
#168Earlier quoted context omitted.
> The only thing blocked would be client side fetch. Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?
That’s… not what cors does? CORS will only block browser-mediated “non-simple” requests, they don’t prevent other systems from accessing it as long as they don’t use a browser (or disable CORS in a headless browser).
I'm pretty sure they understand that since they wrote that the resources will need to be proxied.
They just want to prevent hotlinking/leeching.
Re: Developers don't understand CORS (2019)
#169Earlier quoted context omitted.
It seems like nobody understands CORS. Including me TBH.
I don't understand it. And I'm a web developer. I don't understand the documentation, I don't understand the problem it's trying to solve and I don't understand how it's going about a solution of any problem. The closest I've come to an understanding is that it's meaningless make-work for a ledger of http calls that are not giving any security.
CORS allows JavaScript to make requests to different domains than the origin of the page. By default (without CORS), JavaScript can only communicate with the origin domain.
Re: Developers don't understand CORS (2019)
#170[dead]