3 ms·
Every one of your threat vectors listed would be prevented by appropriate browser origin policies (which already exist for existing protocols). The only slight
by lucideer 4y ago
Every one of your threat vectors listed would be prevented by appropriate browser origin policies (which already exist for existing protocols).
The only slight exception might be fingerprinting, as new APIs always extend this surface area somewhat, but not in the way you're describing (enumeration of local network devices) given aforementioned origin policies.
- iancarroll 4y agoHow do you enforce an origin policy on raw TCP? CORS/SOP are heavily built on HTTP semantics, and you cannot easily map this back to raw TCP sockets. Even just allowing a TCP socket to the page origin's IP address is unsafe, because it might be a CDN and allow skipping CORS for other sites.
- lucideer 4y agoTrue, it wouldn't be as straightforward as HTTP, as there would need to be new semantics (e.g. a handshake protocol for locally-cached IP allowlists or similar), but I guess my general point here is that the gp cited a large list of vectors that are all essentially the same problem & could be tackled with a single targetted (very conceivable) solution. Any new such solution would of course come with its own incorrect-implementation dangers - increased attack surface is increased attack surface. The sibling commenter rightfully points out these are still a potential issue with HTTP (servers not checking Host). But spec-wise a solution is still very doable.
- benmmurphy 4y agoBrowser origin policies are difficult to use to protect something that listens to an IP address rather than a host due to DNS rebinding. This can happen implicitly if the victim service doesn’t check the host header. This is already a big problem with HTTP but with UDP or raw TCP there is no host header so anything that trusted the network would be broken.