FHEMWEB WEB CSRF error

Begonnen von HCS, 18 Februar 2017, 20:45:44

Vorheriges Thema - Nächstes Thema

HCS

Ich habe (nur auf einem meiner Test-Systeme) den Effekt, dass z.B. ein
192.168.31.18:8083/fhem?cmd=reload 36_LaCrosseGateway.pm&detail=LGW212
mit einer leeren html-Seite endet und dieser Log-Eintrag entsteht:
FHEMWEB WEB CSRF error:  ne fhem_68465911005880.9

Hat jemand einen Tip, woran das liegen könnte oder wo ich mit dem Forschen ansetzen sollte?

rudolfkoenig

Ab featurelevel 5.8 ist csrfToken in FHEMWEB per Voreinstellung aktiv.

Damit weigert sich FHEMWEB Befehle auszufuehren, wenn das fwcsrf Parameter nicht das richtige Token enthaelt.
Man kann es mit "none" abstellen, siehe auch commandref. Das Token wird im HTTP-Header und im body als Attribut ausgeliefert, wenn die Seite von FHEMWEB generiert wird.

HCS

Danke. So geht es.
Jetzt fange ich auch langsam an, die Diskussion im "Vorbereitung auf FHEM 5.8 Release" thread wirklich zu verstehen :)

betateilchen

Zitat von: HCS am 18 Februar 2017, 21:46:10
Danke. So geht es.

Wie geht es? Hast Du das token mit "none" abgeschaltet oder hast Du einen Link generiert, der einen Befehl ausführt?
Ich stehe nämlich grade vor dem Problem, dass in meinen InfoPanels die Buttons nicht mehr funktionieren.

http://fhem-rpi3:8083/fhem?XHR=1&cmd=set%20az_Verteiler%20toggle
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

csrfToken habe ich vor 18 Monaten eingebaut, man haette es nur aktivieren muessen. Selbst nach meiner "Drohung" hat es kaum einer gemacht, und jetzt funktionieren so "exotische" Dinger wie Tablet-UI, Dashboard und InfoPanel nicht. Wehe, wenn jemand wieder mit der Idee von Developer und Stable-Release kommt.

betateilchen

Du hast vor 18 Monaten was eingebaut, was ausser Dir wenige Entwickler überhaupt verstanden haben.

Und ich habe mich ja nicht beschwert - ich bin ja bereit, mein InfoPanel entsprechend anzupassen. Aber dabei hilft mir Dein letzter Beitrag nicht wirklich weiter. Gestern habe ich bereits eine Änderung eingebaut, um den automatischen refresh in InfoPanel wieder zum Laufen zu bringen. Das habe ich wenigstens noch verstanden

Aber wie muss jetzt so ein Link aussehen, um ein cmd= auszuführen?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HCS

Zitat von: betateilchen am 20 Februar 2017, 20:27:40
Wie geht es? Hast Du das token mit "none" abgeschaltet oder hast Du einen Link generiert, der einen Befehl ausführt?
Habe es schlicht und schmerzfrei mit none abgeschaltet. Dann muss ich mein ganzen "Entwickler-Helferlein-Links" nicht ändern.

Wenn ich das nicht völlig falsch verstehe, ist es ein Sicherheitsfeature, das man braucht oder (wie ich) nicht und dann halt abschaltet.

rudolfkoenig

ZitatAber wie muss jetzt so ein Link aussehen, um ein cmd= auszuführen?

http://fhem-rpi3:8083/fhem?XHR=1&cmd=set%20az_Verteiler%20toggle&fwcsrf=<csrfToken>

betateilchen

Danke. Hatte ich vorhin schon erfolglos so probiert, aber jetzt klappt das.

button 13 0 0 158 78 5 5 {"http://fhem-rpi3:8083/fhem?XHR=1&amp;cmd=set%20az_Drucker%20toggle".$FW_CSRF} {"Drucker"}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Schlimbo

Hallo zusammen,
Ich hatte auch das Problem, dass meine Steuerung über die Android App Tasker nicht mehr funktioniert hatte.
Nach ein wenig Recherche im Internet und ein wenig try&error bin ich dann dahinter genommen wie es funktioniert.

Werte von FHEM las ich über HTTP GET aus:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1
Meine Steuer Befehle setzte ich über HTTP POST ab:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1

Um den CSRF Token zu bekommen führe ich jetzt eine HTTP GET aus.
Aus der Antwort suche ich mir im Header die Zeile X-FHEM-csrfToken: fhem_xxxxxxxxxxx heraus und Speicher den Token in eine Variable.
GET muss dann wie folgt erweitert werden:
http://<fhemIP>:8083/fhem?cmd=xmllist%20<device>%20&XHR=1&fwcsrf=<token>
Und bei HTTP POST:
http://<fhemIP>:8083/fhem?cmd=set%20<device>%20<befehl>&XHR=1&fwcsrf=<token>

Dank Tasker ist das zum Glück kein Problem, eine kleine Routine einzubauen, die den Token aus dem Header extrahiert, so dass er für weiter POST und GET Befehle genutzt werden kann.

Probleme sehe ich aber bei anderen Anwendungen, die über HTTP URLs FHEM steuern/triggern, wie zum Beispiel der Alarm Server bei Webcam's http://wiki.instar.de/index.php/Alarm_Server_Funktion
Hier führt denke keine Möglichkeiten am deaktivieren von csrfToken vorbei.

Oder kennt hier jemand eine andere Möglichkeit?

Gruß Schlimbo

KernSani

Hi,

ich bin aktuell etwas zurückhaltend mit einem update, da offensichtlich einige Module und Funktionen mit dem Token (noch) nicht zurecht kommen.
Aus meiner Sicht würde es Sinn machen:

  • In einem zentralen Forumseintrag (oder evtl. Wiki) eine Übersicht zu erstellen, welche Module aktuell nicht mit CSRF können, evtl. mit Verweis auf Forumsbeitrag in dem Workaround/Stand der Anpassung (durch Mainainer) kommuniziert wird
  • EIn kleines How-To mit den Optionen, wie Bastellösungen csrfToken nutzen/umgehen können

Denkt ihr das würde Sinn machen? Ich würde dann heute Abend mal anfangen die Wiki-Liste zu basteln... 

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

betateilchen

Zitat von: KernSani am 21 Februar 2017, 15:40:51
Denkt ihr das würde Sinn machen?

Nein.

Zitat von: KernSani am 21 Februar 2017, 15:40:51
Ich würde dann heute Abend mal anfangen die Wiki-Liste zu basteln... 

Bitte nicht. So eine Liste kann nie wirklich aktuell sein und verwirrt mehr, als dass sie nützt.

Einfach ein paar Tage Geduld haben, die meisten Entwickler sind ja schon dabei, ihre Module entsprechend anzupassen (sofern nicht ohnehin schon geschehen)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KernSani

Zitat von: betateilchen am 21 Februar 2017, 19:23:50
Bitte nicht. So eine Liste kann nie wirklich aktuell sein und verwirrt mehr, als dass sie nützt.
Bei genauerem Nachdenken stimme ich dir zu... mein Gedanke war, jeden Abend durch die changelogs der betroffenen Module zu gehen und die Liste entsprechend zu aktualisieren. Mittlerweile halte ich das selbst für keine so gute Idee mehr.

Einen Wiki-Artikel, wie Shellskripte etc... an das token kommen fände ich aber immernoch hilfreich...

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

sinus61

Ich habe in einem Logfile eines Dummy das Attribut eventOnThreshold auf 1 gesetzt. Jetzt bekomme ich immer wenn in das Log geschrieben wird 2 Fehlermeldungen im Fhem Log:

2017.02.23 14:15:11 3: FHEMWEB WEB CSRF error:  ne fhem_38545271019889.6. For detals see the csrfToken FHEMWEB attribute
2017.02.23 14:15:17 3: FHEMWEB WEB CSRF error:  ne fhem_38545271019889.6. For detals see the csrfToken FHEMWEB attribute


Wenn ich eventOnThreshold lösche geht es ohne Fehler. Kann man das irgendwie abstellen ohne in WEB das Attribut auf none zu setzen?

rudolfkoenig

ZitatIch habe in einem Logfile eines Dummy das Attribut eventOnThreshold auf 1 gesetzt.
Ich hoffe nur fuer Demozwecke, sonst ist das nur eine sinnlose FHEM-Quaelerei.

ZitatJetzt bekomme ich immer wenn in das Log geschrieben wird 2 Fehlermeldungen im Fhem Log
Aus theoretischen  Gruenden halte ich die Ursache-Wirkung fuer ausgeschlossen, aber nur um auf Nummer sicher zu gehen: habe dummy angelegt, FileLog dazu, Attribut gesetzt, dummy Event erzeugt -> keine Fehlermeldung.
Ja, Datei wird geschrieben, und es werden 2 Events produziert, eins fuer dummy, eins fuer FileLog.