151–160 of 162 posts
Earlier quoted context omitted.
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.
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…
> You and fivea are conflating functionality with security. fivea wasn't conflating functionality and security. They were saying that a world without CORS would be a world where those rights are always granted.
Or a world where those rights are never granted.
Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people believe that CORS is intended to "lock things down" vs. "open them up". They don't understand that it's opt-in or the default behavior without it.
But, it's a matter of fact that usage of CORS presents risks vs the default policy, and those risks must be considered. That's really the point vs the idea that CORS has no utility.
It's worth noting too that, strictly speaking, there are frequently workarounds to the default policy that don't require CORS, some of which are arguably more secure by way of being less prone to configuration errors.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> You and fivea are conflating functionality with security. fivea wasn't conflating functionality and security. They were saying that a world without CORS would be a world where those rights are always granted.
> a world without CORS would be a world where those rights are always granted. Or a world where those rights are never granted. Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people beli…
Okay, sure, there's a semantics question and also some people are just confused.
So here is where I took issue: Yes, many confused people are conflating functionality and security. But while fivea/pshc's words might accidentally encourage that confusion, they were not confused, and were not conflating the two.
Earlier quoted context omitted.
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…
There's a while saying dedicated to it, "lock them up and throw away the key".
Earlier quoted context omitted.
> a world without CORS would be a world where those rights are always granted. Or a world where those rights are never granted. Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people beli…
> Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people believe that CORS is intended to "lock things down" vs. "open them up". They don't understand that it's opt-in or the default beha…
Probably more semantics. I don't claim to know what's in fivea/pshc's heads or whether they themselves are confused. I was speaking to my observation that their comments merged the two issues.
You may prefer phrasing like, "their words might accidentally encourage confusion" versus "conflation". I'd say conflation is the mechanism there, but OK.
Or you might prefer I specifically clarify "their comments conflated the two" vs "they conflated the two".
OK.
Earlier quoted context omitted.
> Which of those you conclude is a matter of semantics, and this interpretability contributes to the confusion around what CORS actually does. It's that confusion which another commenter was addressing [0] and that my comments sought to support/clarify. You may be unaware that some people believe that CORS is intended to "lock things down" vs. "open them up". They don't understand that it's opt-in or the default beha…
> while fivea/pshc's words might accidentally encourage that confusion, they were not confused, and were not conflating the two. Probably more semantics. I don't claim to know what's in fivea/pshc's heads or whether they themselves are confused. I was speaking to my observation that their comments merged the two issues. You may prefer phrasing like, "their words might accidentally encourage confusion" versus "conflat…
So their comments did not conflate, but might accidentally cause future conflation, so it's reasonable to reply to make the difference extra clear, but I don't think it's reasonable to accuse them of conflation.
Earlier quoted context omitted.
> while fivea/pshc's words might accidentally encourage that confusion, they were not confused, and were not conflating the two. Probably more semantics. I don't claim to know what's in fivea/pshc's heads or whether they themselves are confused. I was speaking to my observation that their comments merged the two issues. You may prefer phrasing like, "their words might accidentally encourage confusion" versus "conflat…
Here's how I see the difference: They made a definite distinction between the two, but if someone read too fast they might miss the distinction. So their comments did not conflate, but might accidentally cause future conflation, so it's reasonable to reply to make the difference extra clear, but I don't think it's reasonable to accuse them of conflation.
It happens. Thanks for clarifying.
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…
> You and fivea are conflating functionality with security. fivea wasn't conflating functionality and security. They were saying that a world without CORS would be a world where those rights are always granted.
We’ve already seen a world without CORS, and that didn’t happen. Cross-origin restrictions were brought in almost immediately after the introduction of JavaScript and existed for over a decade before CORS was introduced.
Earlier quoted context omitted.
> 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. Bluntly, your response is the one coming off as needlessly argumentative, and the parent comment made plenty of sense to me. I don't think it's disingenuous to clearly explain the difference between the Same-Origin Policy and CORS, and to emphasize…
Actually, I agree with OP. Grandparent's phrasing: > All of this is completely wrong. Is not only needlessly argumentative but also wrong itself. The 3rd point they include as "completely wrong" is not wrong, and they end up just rephrasing it later in their correction.
It is:
> With cURL, no CORS takes effect, so the attacker has direct access with the full rights of the user.
The attacker has direct access with the full rights of the user because this is not a situation where one origin is making a request for a resource from another origin, so there’s nothing that says this shouldn’t happen. It’s got absolutely nothing to do with CORS at all.