3 ms·
If you can't control the lan server, like in zoom case, cors won't save you. In fact it did not save you a bit in this case.
by felipelemos 7y ago
If you can't control the lan server, like in zoom case, cors won't save you. In fact it did not save you a bit in this case.
- icebraining 7y agoWho is "you" here? The user? Zoom?
- felipelemos 7y agoYou is you. The user. I do not control the zoom local server, and I do not control what the zoom server answer as the cors header. Having cors enabled in my browser do not save me from anything in this case.
- danielparks 7y agoWhat do you mean about the “zoom case?” Zoom did control the localhost server, and setting a CORS header would have helped mitigate the attack.
- felipelemos 7y agoZoom did control the localhost server, you did not. If zoom made the localhost server answer the cors header with '*', what you can do?
- danielparks 7y agoAh, gotcha.
- iameli 7y agoPerhaps I should have said "The solution to this problem is _properly-implemented_ CORS." My point is that browsers already have a mechanism for mitigating this particular problem and I don't think the additional proposed mitigation (restricting browser access to localhost/LANs) would break a lot of legitimate usage without much benefit. There's only so much browsers can do to mitigate hostile code running on the machine. CORS won't save me if Zoom decided to wipe my hard drive, you know?
- danielparks 7y agoHmm… servers on localhost could be required to have CORS headers. That also makes it much harder to extract interesting information from non-HTTP servers running on localhost.