4 ms·

This context was incredibly useful; thank you. Am I missing something or is this transaction actually a browser being the deciding factor for whether or not th

by _eht 7y ago

This context was incredibly useful; thank you. Am I missing something or is this transaction actually a browser being the deciding factor for whether or not the request gets sent? If that’s true, couldn’t a nefarious browser decide when to push a request and completely ignore the OPTIONS header?

philjackson 7y ago
You're correct, the browser is the safety net when it comes to CORS.
jrochkind1 7y ago
Yes, and that is a very important point you noticed. Both CORS and CSP are for guarding against malicious code on the web, being executed by non-malicious standards-following browsers used by non-malicious users. (the user is in fact who is being attacked). I think is frequently confused, and it leads to a mistake in the other direction, people thinking CORS or CSP can guard against malicious user-agents operated by malicious users. It is not for that!
minhazm 7y ago
Yeah that's correct, CORS is a browser feature. If you had a nefarious browser installed it could indeed defeat CORS, but at that point you already have a nefarious browser and CORS is the least of your concerns. CORS prevents a malicious site from exfiltrating/accessing data using the access you have, for example an internal site that is on your computer's network but the malicious website's servers can't directly access.
giaour 7y ago
Safari used to let you turn off CORS checks in the developer tools menu.
tgsovlerkhgsel 7y ago
Of course, anyone can use netcat to send any kind of request. However, this attack is most useful if you can get the victim's browser to send the request for you, because that way, you can get it to include the victim's authentication cookies. If you as the attacker send the request yourself, you don't have the cookies. If you make the victim's browser send it, you either can't make them use a nefarious browser, or you already won since you have code execution on the victim's machine.
goto11 7y ago
Sure, but then again a nefarious browser could just record and broadcast all your interaction (including password etc) with bank.com directly. No web standard can protect you from a nefarious browser, since the browser could just decide to not follow the standard.

by _eht 7y ago

philjackson 7y ago

You're correct, the browser is the safety net when it comes to CORS.

jrochkind1 7y ago

Yes, and that is a very important point you noticed. Both CORS and CSP are for guarding against malicious code on the web, being executed by non-malicious standards-following browsers used by non-malicious users. (the user is in fact who is being attacked). I think is frequently confused, and it leads to a mistake in the other direction, people thinking CORS or CSP can guard against malicious user-agents operated by malicious users. It is not for that!

minhazm 7y ago

Yeah that's correct, CORS is a browser feature. If you had a nefarious browser installed it could indeed defeat CORS, but at that point you already have a nefarious browser and CORS is the least of your concerns. CORS prevents a malicious site from exfiltrating/accessing data using the access you have, for example an internal site that is on your computer's network but the malicious website's servers can't directly access.

giaour 7y ago

Safari used to let you turn off CORS checks in the developer tools menu.

tgsovlerkhgsel 7y ago

Of course, anyone can use netcat to send any kind of request. However, this attack is most useful if you can get the victim's browser to send the request for you, because that way, you can get it to include the victim's authentication cookies. If you as the attacker send the request yourself, you don't have the cookies. If you make the victim's browser send it, you either can't make them use a nefarious browser, or you already won since you have code execution on the victim's machine.

goto11 7y ago

Sure, but then again a nefarious browser could just record and broadcast all your interaction (including password etc) with bank.com directly. No web standard can protect you from a nefarious browser, since the browser could just decide to not follow the standard.