demo · v146

CSRF Attack Simulator

The drive-by router takeover. Walk through the attack chain on a vulnerable home router and watch where Chrome 146's local network access prompt severs it.

Educational simulation. All requests in this demo are simulated in-page — no real network access happens. The point is to visualise the steps of the classic CSRF chain that the Local Network Access permission interrupts.

Chrome 146 behaviour:

attacker page (public)

https://looks-legit.example/article

Innocuous-looking content. Hidden JS issues a request to the user's home router admin endpoint, riding on whatever cookies the router set when the user last visited 192.168.1.1.

target (private)

http://192.168.1.1/admin/dns?primary=6.6.6.6

A typical home-router admin endpoint that accepts authenticated GETs to change DNS. No CSRF token, no CORS preflight — and the auth cookie is still valid.

User opens looks-legit.example in a tab.
Page script calls fetch('http://192.168.1.1/admin/dns?primary=6.6.6.6').
Browser checks: target is in private address space, request initiator is public.
Local Network Access permission check.
Request reaches the router. Auth cookie attached.
Router accepts. DNS is set to attacker server.

Click "Run the attack" to step through the chain.

two permissions, not one

Chrome 145 split the restriction into two distinct permissions:

local-network — public origin → private IP (10/8, 172.16/12, 192.168/16, RFC 1918)
loopback-network — public or private origin → loopback (127/8, ::1, *.localhost)

This matters because the two surfaces have different risk profiles: loopback is reachable only from the same machine (often dev servers and platform agents), private addresses are reachable across the LAN. Granting one doesn't grant the other.

two permissions, not one

see also