3 ms·
CORS is not in the hands of the user. I don’t want a CORS policy authorizing access to my intranet or localhost.
by souterrain 6y ago
CORS is not in the hands of the user. I don’t want a CORS policy authorizing access to my intranet or localhost.
- oplav 6y agoIf the user decides to run a service on their intranet or localhost with a wide open CORS policy, isn't that their choice? Forgoing CORS and making all inter domain requests user opt-in would make the web experience a lot worse, IMO. Making all intranet or localhost requests user opt-in seems less disruptive.
- souterrain 6y agoHowever, TCP sockets can't publish CORS policies. In the case of scanning, a CORS denial can still reveal information about the user's internal network, as a CORS denial is a different result than a network timeout or a TCP RST.
- kevingadd 6y agoCORS is set by the target, so localhost CORS policy is directly in the hands of the user. intranet CORS policy is set by whoever operates that intranet service
- souterrain 6y agoYou’re right; a bit of a brain fail there for me. Still, doesn’t mitigate attacks against non-HTTP speakers.
- johncolanduoni 6y agoIt does in the sense that you won’t be able to control the websockets payload, so the target server generally won’t respond. The problem here is that the information leak is happening prior to any data being sent over TCP, so the fact that the server will drop the connection as invalid doesn’t help.