CSRF defense use case

Question

You have an embedded device that supports HTTP based web UI over private ip address.

Does it make sense to implement CSRF defense over HTTP(not HTTPS)?

Answer 1

If an HTTP request is capable of changing state, then it may need CSRF protection. Whether or not the request is encrypted at the transport layer has little to no relation to this.

Without CSRF protection, an attacker who convinces you to visit their website or even a single resource may be able to send requests to your embedded device and take control over it, if the victim's browser is properly authorized or there is insufficient or broken authentication. This happens regardless of whether HTTP or HTTPS are used.

Yes, ideally everything would be over HTTPS. However, the "best" option for most vendors right now is to ship embedded devices with self-signed certs which, other than being good for trust-on-first-use and thwarting passive sniffing, are not much better than plain HTTP in many scenarios. Often, the user will still get a certificate warning and click through it. Until this problem is solved, the HTTPS outlook on embedded devices is still dismal.

(Addressing your now-deleted edits) Indeed, XSS bypasses CSRF mitigations. However, the threat model seems a bit different here, since its way less likely for an adversary to be able to exploit an XSS in your embedded device than a CSRF issue, since they would have to get to the device in the first case.

Answer 2

Without CSRF defense, an attacker could forge an email (maybe with a decently targeted spoofed address) with a monitoring alert, telling you to check out because there's a critical issue. Inside the email, there could be a link to http://yourswitch/factory_reset.

Attack vectors may vary.

Unless you happen to use a default FQDN or IP address (say, the ubiquitous 192.168.1.1) for that device, this specific kind of attack would be pretty targeted. An attacker would have to craft a request to the switch which actually does something "interesting" (this requires knowing FQDN/IP and vendor/model to get a useful path) and send you this link in a way that doesn't raise too much your eyebrows (email from the Internet would be strange. Maybe something forging a no-reply monitoring email you use?).

As usual, it comes down to understanding your threat model and cost vs benefit of your countermeasures.

Answer 3

Yes.

In the case of a network switch or a router, typical attacks that it could suffer would be reconfiguration of the device (such as forwarding an internal port to the outside), changing the DNS it provides to malicious ones, etc. These actions should need authentication, but you should take into account that it could be using an unchanged default password, too.

(and yes, this kind of things do happen in the wild)

The fact that it is based on private address http://192.168.1.1 provides no protection, as the attack would be by a malicious web page, sending through the browser of a user inside the network a malicious request which -accepted due to the lack of CSRF protection- would misconfigure the switch.

Mozilla Firefox has had bug 354493 open for 14 years, which would avoid attacks from non-RFC-1918 to RFC 1918 addresses, but so far it hasn't been implemented.