meintechblog.de
8Feb/187

FHEM – csrfToken unkompliziert einrichten und nutzen

Mit dem Update von FHEM auf Version 5.8 wurde auch der csrf-Token als neues Sicherheitsfeature eingeführt, um ein potenzielles Einfalltor für Angreifer zu schließen. Gleichzeitig besteht jedoch auch die Notwendigkeit bestehende Konfigurationen anzupassen, sofern das FHEM-System weiterhin auf externe HTTP-Requests reagieren soll. Denn sonst geht erstmal gar nichts mehr, wie viele Anwender - wie ich - mal mehr oder weniger schmerzlich herausfinden mussten.

Welche Schritte notwendig sind, um eine neue bzw. bestehende Installation ausreichend per csrfToken abzusichern, wird in nachfolgendem Blogpost kurz erklärt. Eine Kurzanleitung, die schon lange auf meiner ToDO-Liste steht und die hoffentlich vielen Lesern weiterhilft.

csrf-Token setzen

Grundsätzlich gibt es zwei Möglichkeiten den csrf-Token zu nutzen.

Zum einen die dynamische Variante, bei der FHEM bei jedem Neustart einen neuen Token (im Endeffekt nur ein anderer Begriff für ein Passwort) vergibt, der dann von externen Applikationen jedes Mal abgeholt werden muss, bevor ein HTTP-Befehl mit korrektem Token/Passwort in Richtung FHEM abgesetzt werden kann. Ich denke diese Art ist vermutlich eher versierteren Anwendern zu empfehlen, je nach externer Anwendung ist dieses Vorgehen zudem gar nicht oder nur mit größerem Aufwand verbunden. Deshalb werde ich an dieser Stelle nicht weiter darauf eingehen, weiterführende Infos dazu im FHEM-Wiki.

Zum anderen die statische Variante, der Token wird also einmal fix in FHEM festgelegt. Also erstmal ein sicheres Passwort, bestehend aus Zahlen und Ziffern ausdenken, in diesem Beispiel Me1nT3chBl0g4Th3W1n. Ich würde dringend empfehlen auf Umlaute und Sonderzeichen zu verzichten, da sowas bei HTTP-Aufrufen sonst schneller zu Problemen führt als man csrfToken buchstabieren kann.

Mit dem FHEM-Kommandozeilenbefehl (oben in den Schlitz vom FHEM-Interface eingeben und mit Enter bestätigen)

wird der neu vergebene csrf-Token in die FHEM-Config geschrieben. Jetzt noch links auf "Save Config" klicken, dann ist der Token auch bei einem Neustart von FHEM dauerhaft gesetzt.

HTTP-Befehle um csrf-Token ergänzen

Bestehende und neue HTTP-Befehle in Richtung FHEM müssen dann natürlich noch um den eben gesetzten Token ergänzt werden.

Lautete der HTTP-Bequest zum Einschalten ("on") der "Lampe" bisher beispielsweise

http://user:pass@192.168.3.154:8083/fhem?cmd=set%20Lampe%20on

ergibt sich nun der neue um den csrf-Token ergänzte Befehl

http://user:pass@192.168.3.154:8083/fhem?cmd=set%20Lampe%20on&fwcsrf=Me1nT3chBl0g4Th3W1n

Und das war es auch schon mit dem csrf-Voodoo.

Aus meinem täglichen Leben

Ich selbst setze jede Menge HTTP-Befehle in Richtung FHEM ab. Die meisten kommen mittlerweile vom Loxone Miniserver, welcher entsprechende Steuerbefehle an die in FHEM verwalteten Devices ohne nennenswerten Zeitverzug weitergibt. In diesem Kontext habe ich gerade erst meine neue Multimediasteuerung fertiggestellt, wobei in FHEM nun u.A. sowohl eine VU+ Solo 4k (Affiliate-Link), ein Denon AV Receiver-X1400H (Affiliate-Link) als auch eine Logitech Harmony Elite (Affiliate-Link) samt Harmony Hub über die entsprechenden FHEM-Module eingebunden sind.

Eine mittlerweile doch recht umfangreiches Multimediasteuerung mit vielen automatisierten Regeln, bei der mir wieder klar geworden ist, wie vielseitig und unersetzlich FHEM doch über die Jahre für mich geworden ist, auch wenn ich das meiste "normale" (non-gimmik) Smart-Home-Geraffel aus Bequemlichkeit mittlweile lieber in Loxone umsetze. Es gibt aber einfach zu viele tolle Spielerein, die man nur bzw. so viel besser mit FHEM realisieren kann. Bald kommt nun auch das Modul für meinen mittlerweile nicht mehr wegzudenkenden Neato Botvac Connected (Affiliate-Link) dazu, der sogar eine Reinigungs-Map erzeugt, verrückt!

Vielleicht lässt sich die Map ja sogar easy in FHEM abrufen und ich kann auf die Neato-App komplett verzichten. Ich werde berichten.

Aber jetzt ist erstmal FHEM ein Stück sicherer. Check! Ob der csrfToken jetzt aus technischer Sicht wirklich notwendig ist oder nicht, darüber kann man lange diskutieren - muss man aber nicht. Mit FHEM ab Version 5.8 wird er nunmal standardmäßig gesetzt, was zumindest in ausgewählten Anwendungsfällen auch wirklich Sinn macht. Er tut ja auch nicht weh, lediglich die HTTP-Befehle werden noch etwas unhandlicher.

Wer gänzlich auf das Plus an Sicherheit verzichten möchte, kann den csrf-Token aber auch einfach deaktivieren. Dazu wird der FHEM-Kommandozeilenbefehl

attr WEB.* csrfToken none

genutzt. Aber dann kann FHEM aber technisch bspw. schon allein über manipulierte iFrames beim Surfen im Web ferngesteuert werden. Wie akut dieses Angriffsszenario wirklich ist, entzieht sich meiner Kenntnis. Dennoch empfehle ich den Einsatz des Token, denn umgekehrt er schadet ja auch nicht.

Smart Home Gear zu diesem Blogpost (Affiliate-Links)

Wir haben dir mit diesem Artikel weitergeholfen? Dann zeig dich erkenntlich und gib uns einen Kaffee aus. Vielen Dank schon mal!




Fragen zu FHEM? Unser neues E-Book hilft dir weiter!

Verpasse keine Inhalte mehr! Trage dich in unseren Newsletter ein und folge meintechblog auf Facebook oder Twitter.

Share Button
Jörg

Jörg

hat meintechblog.de ins Leben gerufen, um seine Technikbegeisterung und Erkenntnisse zu teilen. Er veröffentlicht regelmäßig Howtos in den Bereichen Smart Home und Home Entertainment. Mehr Infos
Jörg
Kommentare (7)
  1. Die Map von Neato lässt sich in der Tat abrufen, habe das in OpenHab implementiert. Schreib mir gern eine Mail, dann suche ich das mal raus bzw. ich versuche dran zu denken, wenn ich wieder am Rechner bin und poste es hier.

  2. Sehe ich das richtig: Das Passwort wird nun also immer im Klartext über jeden http-Aufruf mitgegeben? Wo ist denn da jetzt ein Zugewinn an Sicherheit, wenn einmal jemand im Netzwerk die Aufrufe mitgelesen hat (z.B. mittels Wireshark), dann hat er das Passwort und kann doch genauso Befehle erteilen wie bisher ohne csrf-Token auch, oder?!

    Vermutlich stehe ich irgendwo auf dem Schlauch... Sorry!

    • Jep, du siehst das schon richtig.

      Der csrf-Token deckt eben nur einen Teil potenzieller Sicherheitsrisiken ab, wenn bspw. beim Ansurfen einer manipulierten Website ein statischer URL-Befehl in Richtung FHEM abgesetzt wird, der das System schädigen soll. Viele FHEM-Anwender nutzen vermutlich keine User/Passwort-Kombination und da hilft der neue Token-Zwang zumindest diese Art Angriffe zu minimieren.

      So könnte ich es mir wenigstens ansatzweise erklären, ohne jedoch die Hintergründe zu kennen. Vielleicht steht im FHEM-Forum irgendwo mehr dazu...

      Grüße
      Jörg

    • Bei dem csrf-Token handelt es sich nicht um ein Passwort. Dies ersetzt auch keine Passwort-Absicherung. Vielmehr soll CSRF/XSRF Angriffen vorgebeugt werden. So könnte z.B. niemand mit einer präparierten Webseite eine Aktion in deinem FHEM ausführen.

      Das Problem wäre nämlich sonst: Dein Browser kennt Dein Passwort von fhem, Du hast Dich ja eingeloggt. Somit wird der BasicAuthentication-Header mit Benutzernamen und Passwort immer automatisch übermittelt.

      Baut nun jemand eine Webseite, welche dann einen iframe zu fhem enthält (z.B. ein 1x1 Pixel großer iFrame), könnte er dort eine URL hinterlegen. Sowas wie "set Haustuer open". Also durchaus Sicherheitsrelevante Dinge tun. Dein Browser öffnet nun diese Seite und führt die Anfrage im Hintergrund an fhem durch. Zack, deine Tür ist offen (als Beispiel).

      Dafür muss der Angreifer natürlich viel wissen. Also wie die IP zu deinem fhem im lokalen Netzwerk lautet, wie deine Geräte heißen (wobei man das auch über devspec mit TYPE=... umgehen könnte) und was für einen Typ sie haben. Generell könnte man natürlich beliebig viele iFrames einbinden, um die Trefferrate zu erhöhen.

      Aber das ist alles sehr konstruiert. Wie auch immer - der csrfToken soll genau dieses Vorgehen verhindern. Stimmt der Token nicht, wird die Aktion nicht ausgeführt. Egal ob Du erfolgreich eingeloggt wurdest oder nicht.

      Ich hoffe es ist klarer geworden :)

  3. Hallo Jörg, ich sehe diesen Artikel auch nicht als umfassendes Allheilkonzept gegen Angriffe von außen. Im Bereich Sicherheit sind ja viele einzelne Punkte zu betrachten. Dieser gehört definitiv dazu, genauso wie die Einrichtung eines Reverse Proxy im Artikel Geocaching. Genauso kann man sich die Frage stellen, ob eine Kommunikation nach außen immer über eine Portweiterleitung in der fritz.box laufen muss, oder Pushover und Amazon Echo nicht ein alternativer Weg wären. Nur welche Angriffspotentiale bestehen hierbei ? Gruß Axel

  4. Hallo,

    ich habe FHEM mit SmartVisu am laufen.
    Hier finde ich allerdings nichts, wie ich die Tokens senden/ergänzen kann.
    Hat hier schon jemand Erfahrungen gesammelt?

    Danke und Gruß
    Jens

  5. Hallo Jörg,

    schau dir mal für deinen BOTVAC dieses FHEM-Modul mal an:
    https://forum.fhem.de/index.php/topic,51713.0.html


Dein Kommentar

Trackbacks sind deaktiviert.