CSRF-Verteidigungs-Anwendungsfall
Sie haben ein eingebettetes Gerät, das eine HTTP-basierte Web-Benutzeroberfläche über eine private IP-Adresse unterstützt.
Ist es sinnvoll, CSRF-Verteidigung über HTTP (nicht HTTPS) zu implementieren?
Antworten
Wenn eine HTTP-Anfrage den Status ändern kann, benötigt sie möglicherweise CSRF-Schutz. Ob die Anfrage auf der Transportschicht verschlüsselt ist oder nicht, hat damit wenig bis gar nichts zu tun.
Ohne CSRF-Schutz kann ein Angreifer, der Sie zum Besuch seiner Website oder sogar einer einzelnen Ressource überredet, möglicherweise Anfragen an Ihr eingebettetes Gerät senden und die Kontrolle darüber übernehmen, wenn der Browser des Opfers ordnungsgemäß autorisiert ist oder eine unzureichende oder fehlerhafte Authentifizierung vorliegt. Dies geschieht unabhängig davon, ob HTTP oder HTTPS verwendet werden.
Ja, im Idealfall läuft alles über HTTPS. Die derzeit „beste“ Option für die meisten Anbieter besteht jedoch darin, eingebettete Geräte mit selbstsignierten Zertifikaten auszuliefern, die, abgesehen davon, dass sie bei der ersten Verwendung vertrauen und passives Sniffing verhindern, in vielen Fällen nicht viel besser sind als einfaches HTTP Szenarien. Häufig erhält der Benutzer dennoch eine Zertifikatswarnung und klickt sich durch. Bis dieses Problem gelöst ist, sind die HTTPS-Aussichten auf eingebetteten Geräten immer noch düster.
(Bezieht sich auf Ihre jetzt gelöschten Änderungen) In der Tat umgeht XSS CSRF-Minderungen. Das Bedrohungsmodell scheint hier jedoch etwas anders zu sein, da es für einen Angreifer viel weniger wahrscheinlich ist, dass er in der Lage ist, ein XSS in Ihrem eingebetteten Gerät auszunutzen, als ein CSRF-Problem, da er im ersten Fall an das Gerät gelangen müsste.
Ohne CSRF-Verteidigung könnte ein Angreifer eine E-Mail (vielleicht mit einer anständig gezielten gefälschten Adresse) mit einer Überwachungswarnung fälschen, in der Sie aufgefordert werden, dies zu überprüfen, da ein kritisches Problem vorliegt. In der E-Mail könnte sich ein Link zu http://yourswitch/factory_reset befinden.
Angriffsvektoren können variieren.
Sofern Sie nicht zufällig einen Standard-FQDN oder eine IP-Adresse (z. B. die allgegenwärtige 192.168.1.1) für dieses Gerät verwenden, wäre diese spezielle Art von Angriff ziemlich zielgerichtet. Ein Angreifer müsste eine Anfrage an den Switch erstellen, der tatsächlich etwas „Interessantes“ tut (dies erfordert die Kenntnis von FQDN/IP und Anbieter/Modell, um einen nützlichen Pfad zu erhalten) und Ihnen diesen Link auf eine Weise senden, die nicht zu viel erhöht Ihre Augenbrauen (E-Mail aus dem Internet wäre seltsam. Vielleicht verwenden Sie etwas, das eine No-Reply-Überwachungs-E-Mail fälscht?).
Wie üblich kommt es darauf an, Ihr Bedrohungsmodell und das Kosten-Nutzen-Verhältnis Ihrer Gegenmaßnahmen zu verstehen.
Ja.
Im Falle eines Netzwerk-Switches oder eines Routers wären typische Angriffe, denen er ausgesetzt sein könnte, die Neukonfiguration des Geräts (z. B. die Weiterleitung eines internen Ports nach außen), die Änderung des von ihm bereitgestellten DNS auf böswillige usw. Diese Aktionen sollten erforderlich sein Authentifizierung, aber Sie sollten berücksichtigen, dass es auch ein unverändertes Standardpasswort verwenden könnte.
(und ja, solche Dinge passieren in freier Wildbahn)
Die Tatsache, dass es auf der Privatadresse basierthttp://192.168.1.1bietet keinen Schutz, da der Angriff von einer böswilligen Webseite erfolgen würde, die über den Browser eines Benutzers innerhalb des Netzwerks eine böswillige Anfrage sendet, die – aufgrund des fehlenden CSRF-Schutzes akzeptiert – den Switch falsch konfigurieren würde.
Mozilla Firefox hat seit 14 Jahren den Fehler 354493 offen, der Angriffe von Nicht-RFC-1918- auf RFC-1918-Adressen verhindern würde, aber bisher wurde er nicht implementiert.