The attacks CSRF (Cross-Site Request Forgery) exploit the trust that a web application places in requests from authenticated users’ browsers. These types of attacks occur when an authenticated user (that is, already logged in) performs unwanted actions on an application to which he or she is connected. All without being absolutely aware of it.
The scheme used in some rather common cyber attacks assumes that the user has carried out the login on a certain website vulnerable to CSRF attacks. The victim then accesses a malicious web page, hosted for example on a completely different domain name. The site set up by the attacker also carries out actions richieste HTTP/HTTPS towards the vulnerable site, taking advantage of the fact that the user already has an active authenticated session.
Devices connected to the local network can be attacked via the Web: here’s how
The firewall present on most routers and the use of NAT (Network Address Translation) they do yes i local devicesconnected in LAN, are not directly reachable from remote hosts connected to the Internet.
However, there is an important exception that Google developers have decided to focus on: imagine a website that, for example, uses the HTML tag iframe to call the interface of a local device via HTTP/HTTPS. So think of a malicious site that uses code similar to the following:
<iframe href="https://admin:[email protected]/set_dns?server1=xyz.xyz.xyz.xyz"></iframe>In some cases the WebRTC protocol or other mechanisms could “spill” thelocal IP address of the remote device. From there, an attacker could estimate the IP address of routers, access points, or other devices connected to someone else’s LAN.
It is still possible for the attacker to insert HTML code into his own iframe references to a set of local IP addresses or mnemonic addresses commonly used to manage a wide range of devices (ICANN wants to replace them with the .internal TLD). For example, if there was a vulnerability that, as in the example given above, would allow modificare server DNS by sending a simple HTTP/HTTPS request, an attacker could redirect all domain name resolution requests, made by all clients connected downstream of the router, towards a resolver DNS under his control. The Holy Grail, in short, of those who implement it phishing attacks.
Chrome will protect users from remote attacks targeting devices connected to the local network
Since the described CSRF attacks are not at all unusual, Google has decided to do Chrome in such a way reduce risks for users.
In situations similar to those presented in the previous paragraph, Chrome will show users a I notify informing what is happening and asking whether the connection to local devices should be authorized or blocked. If there is no response, your Google web browser will automatically block any connection attempts to local resources.
At the moment, however, Google points out that any reloading of the web page (reload) will result in the request being approved as the connection request would be treated as coming from a local IP to another local IP.
However, the technicians of the Mountain View company are also discussing this particular aspect: in the end, in fact, the next versions of Chrome could to block Even the requests after reload of the page, if Private Network Access had already denied them previously (display of error code BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS).
We would like to point out that the innovation is currently under discussion and that it could be implemented in the next stable versions of Chrome. In the meantime, the advice is obviously to install the latest firmware versions on local devices (in particular all those that integrate server functionality).
Credit immagine in apertura: iStock.com – Microsoft Bing Image Creator.