3 ms·
And https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...
by omgitsabird 5y ago
And https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...
- howdydoo 5y agoAre there any test pages where I can see if I'm vulnerable to this? I've been assuming that uMatrix prevents this, but this post is a good reminder to double-check
- westurner 5y agoAnd also "Private Network Access: introducing preflights" (2022) https://developer.chrome.com/blog/private-network-access-preflight/ https://developer.chrome.com/blog/private-network-access-pre... > Chrome is deprecating direct access to private network endpoints from public websites as part of the Private Network Access (PNA) specification. > Chrome will start sending a CORS preflight request ahead of any private network request for a subresource, which asks for explicit permission from the target server. This preflight request will carry a new header, `Access-Control-Request-Private-Network: true`, and the response to it must carry a corresponding header, `Access-Control-Allow-Private-Network: true` > The aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks. These attacks have affected hundreds of thousands of users, allowing attackers to redirect them to malicious servers. What would a browser setting to just block all PWA requests (`DENY * TO *` (to {192.168.0.1, .1.1, .100.1,}) - regardless of the appropriate new HTTP headers - actually prevent a normal user from doing?