[jjeaff]

Would this not also require some sort of exploitable CORS vulnerability?

[chopin]

CORS prevents the JS from seeing the result but it doesn't prevent the sending of the request.

This is one of the reasons my internal network is not 192.168.1.1/24 and the router is not 192.168.1.1.

[spartas]

> This is one of the reasons my internal network is not 192.168.1.1/24 and the router is not 192.168.1.1.

Do you also disable WebRTC on all clients on your network? An attacker (or script) may be foiled by your non-standard gateway network, but your work in obfuscating the router is wasted if they can get at your client IP address.

[kbenson]

Doesn't CORS generally send an OPTION request first to see if the target site even allows the requests, thus preventing this? That's what I've seen when trying to work around browser CORS limitations.

[upheaval7276]

only for ajax requests that are not "simple", that is requests that cannot be sent w/out JavaScript. The sending of this OPTIONS request is referred to as a pre-flight. A more through description at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

[foxylion]

You can also just do a normal form post request into an invisible iframe that is generated by the attacker's javascript.

[singron]

You can submit forms without CORS as long as there is no CSRF protection. I don't know what CSRF protection is being used.

[peeters]

Depends on the attack and the vulnerability. The article does say this:

> The attacks work when routers use weak administrative passwords and are vulnerable to CSRF attacks.

Which implies that a cross site request is being made. So e.g. you put a hidden form in a netf1ix.com page whose action is at some URL on the router. The user ends up accidentally posting data to that URL which is not affected by CORS and same-origin.

[jtaft]

Normal form posts don't require pre-flight requests. DNS rebinding attacks can be used too.