[peterwwillis]

Assuming you could exploit the browser's JS to submit such a request (I thought I remembered seeing a security feature of modern browsers to prevent this?) and assuming the web interface requires no authentication, you would only be able to enable WAN HTTP access. The telnet and ssh still appear to be LAN-only. And you still need the serial number to generate a password (does the web interface even show that?). I don't see a viable drive-by attack vector other than malware.

edit It does look like telnet can be accessed via WAN, which is pretty bad.

[rogerbinns]

There is a same origin policy and CORS. Sometimes cross site stuff is supposed to work (JSONP). In some cases the request is made to the non-origin site, and the response is then blocked based on returned headers. That however doesn't stop the request's side effects. A few years ago there were a round of hacks against many home routers doing this, exploiting vulnerabilities in their web admin interfaces. I stand by my first sentence in my first comment.

[amjo324]

Yes, this class of web vulnerability is called Cross-Site Request Forgery or CSRF (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...). The Same Origin Policy (SOP) prevents one domain from receiving the HTTP responses for requests it sends to other domains. As you suggest however, the request itself can sometimes be enough to cause adverse side effects on the target server (that may be beneficial to an attacker).

It continues to be a common security issue among web applications and is why all sensitive actions should be protected with unique anti-CSRF tokens (most good development frameworks provide support for this).

If you need to relax SOP restrictions between sites you control, the modern and recommended way is via Cross Origin Resource Sharing or CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...).