3 ms·
Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will cert
by jabbany 5y ago
Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. It's the same reason you cannot embed an Ajax request in your blog to query someone's bank account's API. In order for information to be made available to the external site, the service has to cooperate with the remote site already.
In fact, even CSRF is mostly due to the server misusing HTTP. Look at the example in the W3C doc, where the remote site has a hidden frame/resource that hits local servers. Well guess what, GET requests should not change state, so changing some DNS configuration via a GET request is already doing it wrong.
There's no inherent reason an intranet site should be treated any differently from an Internet site. At best the current argument is that "intranet sites are more likely to be hacky and poorly implemented", but that should reflect more on those devices/services on the intranet than anything else.
- cygx 5y agoIf intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. You use connection timing for that, cf https://nullsweep.com/why-is-this-website-port-scanning-me/ https://nullsweep.com/why-is-this-website-port-scanning-me/
- jabbany 5y agoAgain, not an issue with local network vs Internet. You can do the same fingerprinting to check for connection ability against Internet sites too... If anything this is a bug with WebSockets and its cross-origin implementation. The existing cross-origin request specs already specify that there should not be information being leaked about the target resource unless cross-origin was allowed. Iframes don't let you time how long the thing inside loads anymore, img also stopped making this available, same for things like AJAX, and so should it be for websockets too. If indeed the only information the scan is gleaning is based on timing then it's no different from the other JS timing attacks (some of the early ones could expose arbitrary slices of ram!)--- it's a bug and should be fixed as such. When you say doing private/public IP filtering is to fix this kind of issue, then what's really being said is "I still want websockets fingerprinting and port scanning to _work_, just not with any internal network IPs".