Hallo zusammen,
würde gerne ein set Befehl über einen Browser aufruf vom PC aus zum schalten eines Dummy nutzen. Habe per Suche gefunden das es generell geht und habe auch einige Beispiele die ich gefunden habe in verschiedenen Versionen ausprobiert, bekomme aber immer nur eine leer Seite zurück, nicht mal eine Fehlermeldung oder so. Evtl. ist es auch ein Problem das mein WebInterface Passwortgeschützt ist ? Dazu habe ich nichts gefunden gehabt. Bisher habe ich ausprobiert
http://ip:8083/fhem?cmd.dummy=set%20dummy%20on&XHR=1
http://ip:8083/fhem?cmd.dummy=set%20dummy%20on
http://ip:8083/fhem?cmd=set%20dummy%20on
Jeweils alle auch zum test mal mit voran gesetztem user:pass@
Funktioniert aber alles nicht, jemand eine Idee ?
Danke
FHEM Weboberfläche öffnen, linke Seite unteres drittel Log anschauen. Das letzte was ausgegeben wurde steht immer an unterster Stelle.
Stichwort CSRF Token
Gesendet von iPhone mit Tapatalk
Was sagt fheminfo?
Gruß Otto
Zitat von: Ma_Bo am 02 März 2017, 19:53:02
Stichwort CSRF Token
Gesendet von iPhone mit Tapatalk
Ja das wird wohl das Problem sein. Aber lass ihn bitte erstmal lernen wie und wo er solche Fehlerinfos her bekommt. :D
Zitat von: CoolTux am 02 März 2017, 19:59:34
Ja das wird wohl das Problem sein. Aber lass ihn bitte erstmal lernen wie und wo er solche Fehlerinfos her bekommt. :D
Mach ich doch, ist doch nur ein Hinweis nach dem er suchen soll.
Sonst hätte ich ihm doch geschrieben, dass er im LOG File nachschauen soll, dann steht dort der Fehler mit dem CSRF Token und dann kann er zu den zahlreichen Beiträgen, die es zu dem Thema gibt, sich etwas passendes raussuchen.
Ich hätte ihm ggfs. dazu geraten den CSRF Token über das attr <WEB> csrfToken zu deaktivieren (nein hätte ich doch nicht), dann hättest du geschrieben, dass es wesentlich bessere Methoden gibt als dem Einbrecher den Schlüssel in Geschenkpapier mit Blümchen zu präsentieren... ;)
ABER ich habe ja nix davon geschrieben und somit muss er selber suchen...
So und jetzt Popcorn raus und ab dafür...
Grüße Marcel
##### Edit1
Ich möchte hier NIEMANDEM auf den Schlips treten, das ist lediglich Spaß und sollte keinesfalls angreifend auf irgendjemanden wirken.
##### Edit2
Edit1 wurde nur zur Sicherheit geschrieben.
Er hat gelernt ;)
FHEMWEB WEB CSRF error: fhem_36141658639512.9 ne fhem_404723355188017. For detals see the csrfToken FHEMWEB attribute
-> https://forum.fhem.de/index.php?topic=67477.0
attr WEB csrfToken none
-> success
Danke !
;D
So und jetzt du CoolTux :)
Zitat von: Ma_Bo am 02 März 2017, 20:07:52
Mach ich doch, ist doch nur ein Hinweis nach dem er suchen soll.
Sonst hätte ich ihm doch geschrieben, dass er im LOG File nachschauen soll, dann steht dort der Fehler mit dem CSRF Token und dann kann er zu den zahlreichen Beiträgen, die es zu dem Thema gibt, sich etwas passendes raussuchen.
Ich hätte ihm ggfs. dazu geraten den CSRF Token über das attr <WEB> csrfToken zu deaktivieren (nein hätte ich doch nicht), dann hättest du geschrieben, dass es wesentlich bessere Methoden gibt als dem Einbrecher den Schlüssel in Geschenkpapier mit Blümchen zu präsentieren... ;)
ABER ich habe ja nix davon geschrieben und somit muss er selber suchen...
So und jetzt Popcorn raus und ab dafür...
Grüße Marcel
Hallo Marcel,
Zu meiner Verteidigung möchte ich kurz anmerken das der Kollege auf den Du Dich beziehst die 8083 mit none konfiguriert hat. Das ist im Normalfall die Admin Webinstanz. Sonst hätte ich bisschen lockerer reagiert. ;D
Aber manchmal muss man die User erziehen. Es geht leider in bestimmten Fällen nicht anders. Hast ja bestimmt selber mit bekommen was gerade wegen CSRF hier los ist.
Grüße
Zitat von: CoolTux am 02 März 2017, 20:14:18
Hallo Marcel,
Zu meiner Verteidigung möchte ich kurz anmerken das der Kollege auf den Du Dich beziehst die 8083 mit none konfiguriert hat. Das ist im Normalfall die Admin Webinstanz. Sonst hätte ich bisschen lockerer reagiert. ;D
Aber manchmal muss man die User erziehen. Es geht leider in bestimmten Fällen nicht anders. Hast ja bestimmt selber mit bekommen was gerade wegen CSRF hier los ist.
Grüße
Hab ich und das ganze sehe ich genau wie du !
Deshalb ist das hier auch alles nur als Spaß gemeint. ;)
Zitat von: nerothos am 02 März 2017, 20:08:46
Er hat gelernt ;)
FHEMWEB WEB CSRF error: fhem_36141658639512.9 ne fhem_404723355188017. For detals see the csrfToken FHEMWEB attribute
-> https://forum.fhem.de/index.php?topic=67477.0
attr WEB csrfToken none
-> success
Danke !
Ich kann verstehen das Du den leichten Weg gegangen bist. Aber bedenke. Gerade wegen solcher Geschichten wie du sie machst. Also Schaltbefehle aus dem Browser heraus würde dieser Token eingeführt. Du benutzt zum steuern die Hauptwebinstanz mit Vollzugriff. Einzig positive, Passwortschutz.
Vorschlag. Zweite Webinstanz, sich über allow informieren und wie man es am besten konfiguriert. Zusätzlich festen Token als minimale CSRF Sicherung.
Zitat von: Ma_Bo am 02 März 2017, 20:16:16
Hab ich und das ganze sehe ich genau wie du !
Deshalb ist das hier auch alles nur als Spaß gemeint. ;)
Kam auch so bei mir an. Alles schick.
Ich habe das nur für einen speziellen Fall. Mein Pi ist aber nicht im Internet frei gegeben. Ich habe einfach das fhem Passwort mit in den HTML Aufruf gepackt. Wenn ich das hier so lese, ist das bestimmt nicht so eine gute Idee? Aber wie gesagt, beide Geräte sind nur im eigenen Netzwerk.
Gesendet von meinem Wileyfox Swift mit Tapatalk
https://de.m.wikipedia.org/wiki/Cross-Site-Request-Forgery
Deine Entscheidung. Ich habe mein bestes getan.
Grüße
Vielen Dank CoolTux für den Hinweis, verstehe ich, hast du recht, Sicherheit geht vor!
Aktuell habe ich es auch wieder aktiviert, wollte damit gestern auch erst mal was testen... dazu ist es denke ich der richtige weg bevor ich mir viel mühe mache alles korrekt und so sicher wie mögloch zu konfigureren um dann fest zu stellen das was ich vor habe geht gar nicht... generell steure ich mein Fhem nicht per Web Befehlen.... egal
Eine Frage zum Passwortschutz hätte ich aber noch, da ich den HTML Aufruf gestern nach deaktiveren des Tokens von meinem Browser aus gemacht habe mit dem ich schon autentifiziert war habe ich keine Abfrage nach Passwort bekommen... ist die Autentifizierung mit vorangestelltem user:pass@ denn richtig oder geht das nicht oder anders ?
Guten Morgen,
Das sollte meines Wissens nach so gehen. Die Syntax für https und http Aufrufe stimmt jedenfalls so.
Grüße
Zitat von: CoolTux am 03 März 2017, 08:15:51
Guten Morgen,
Das sollte meines Wissens nach so gehen. Die Syntax für HTTPSRV und http Aufrufe stimmt jedenfalls so.
Grüße
Warum hast du zu meinem Beitrag : "Deine Entscheidung. Ich habe mein bestes getan" geschrieben ?
Oder war das nicht für mich ? Ich hatte ja auch geschrieben, das ich username und passwort mit in die URL gepackt habe und gefragt ob das Ok ist.
Zitat von: ArduPino am 03 März 2017, 16:57:46
Warum hast du zu meinem Beitrag : "Deine Entscheidung. Ich habe mein bestes getan" geschrieben ?
Oder war das nicht für mich ? Ich hatte ja auch geschrieben, das ich username und passwort mit in die URL gepackt habe und gefragt ob das Ok ist.
https://forum.fhem.de/index.php/topic,68314.msg598003.html#msg598003
Für Dich relevant ist der Teil was CSRF eigentlich ist.
Hier mal ein Beispiel zur Ausnutzung.
https://forum.fhem.de/index.php/topic,68314.msg598070.html#msg598070
Ach so, ok, Danke !
Ich hatte noch eine ältere FHEM Version und nun ein Update gemacht.
LOG voll mit diesem csrfToken Einträgen.
Habe dann mal die verlinkten Beiträge gelesen.
Ok, es gibt diese Sicherheitslücke wenn da eine Böse Seite im Browser ist.
Jetzt wird aber einfach diesen "attr WEB csrfToken none" gesetzt...und dann ?
In FHEM 5.8 ist also eine Änderung vorgenommen worden, die die Sicherheit erhöht bzw. dieses "Böse Seite im anderen Tab" Problem löst.
Woher kommen denn nun diese LOG Einträge überhaupt ? Und warum ist dieses attribut nicht schon nach dem Update gesetzt...machen ja anscheinend eh alle die das nun im LOG stehen haben.
Zitat von: ArduPino am 03 März 2017, 20:03:04
Ich hatte noch eine ältere FHEM Version und nun ein Update gemacht.
LOG voll mit diesem csrfToken Einträgen.
Habe dann mal die verlinkten Beiträge gelesen.
Ok, es gibt diese Sicherheitslücke wenn da eine Böse Seite im Browser ist.
Jetzt wird aber einfach diesen "attr WEB csrfToken none" gesetzt...und dann ?
In FHEM 5.8 ist also eine Änderung vorgenommen worden, die die Sicherheit erhöht bzw. dieses "Böse Seite im anderen Tab" Problem löst.
Woher kommen denn nun diese LOG Einträge überhaupt ? Und warum ist dieses attribut nicht schon nach dem Update gesetzt...machen ja anscheinend eh alle die das nun im LOG stehen haben.
Sie machen es weil sie es nicht besser wissen. Sie haben auf dem Handy Tasker und greifen mit http request aufrufen auf ihr fhem zu. Andere verwenden diverse Frontends die noch nicht so weit sind. Dashboard oder TabletUI. Wobei TabletUI in Version 2.6 seit heute Morgen das komplett unterstützen sollte. Wir haben die Nacht da was gemacht.
Im Grunde musst Du nur überlegen was Du noch hast was eventuell auf Dein FHEMWEB zugreifen tut.
Ok, Tablet UI müsste ich dann mal aktualisieren...oder geht das automatisch beim normalen Update von fhem ?
Ich habe nur noch eine IP Camera. An die sende ich von FHEM per "GethttpFile" einige Werte und rufe von FHEM aus Werte von der Cam mit HTTPMod ab.
Zu FHEM selber wird nichts gesendet.
Schaltet dieses attribut denn diese neue Sicherheitsmaßname ab oder werden nur die Fehlermeldungen unterdrückt ?
Ich habe noch für meine Amazon Dash Buttons dieses "dasher" laufen. Da weiß ich aber gar nicht wie das ganze überhaupt funktioniert.
Also am besten prüfen was die Fehler verursacht und dann auf Updates warten ?
Abfragen von fhem aus zu anderen Geräten sind egal. Es geht um ?cmd Aufrufe als http request.
TabletUI ist nicht Bestandteil von FHEM. Keine Ahnung wie Du das installiert hast. Das musst Du bitte selber wissen.
CSRF auf none gesetzt für die entsprechende Webinstanz deaktiviert die Tokensicherheit.
Juhu ! Lag nur am Tablet Ui !
Und noch mal Juhuu.... sieht jetzt total anders aus ! Icon- und Textgrößen total verdreht :P
Egal, das hat man schnell wieder eingestellt.
Gute Gelegenheit das Design etwas zu überarbeiten.
Jetzt habe ich doch ein Problem und zwar mit meinem Amazon Dash Button.
Um diese abzufragen benutze ich dasher https://github.com/maddox/dasher (https://github.com/maddox/dasher)
Nun habe ich wieder diese csrf Meldung im Log, wenn ich das crfsToken Attribut unter WEB lösche.
Es gibt ja aber noch ein WEBTablet.
Dort habe ich kein Passwort angelegt und das benutze ich auch nicht für Konfigurationen. Portweiterleitungen gibt es auch keine.
In diesem FHEMWEB habe ich nun das attrib csrfToken none gesetzt.
Wäre das ok ?
Wenn nicht, kann man denn ein Token mit übertragen in einem HTTP Aufruf ? Oder wie löst man das ?
Das ist ein sehr guter Ansatz. Du kannst einen festen Token noch nehmen und diesen im Aufruf mit senden
https://wiki.fhem.de/wiki/CsrfToken-HowTo
Ok, vielen Dank !
Guten Morgen,
für die kurze Zwischenfrage möchte ich kein extra Thema öffnen.
Ich habe vor, den csrf token zu nutzen und nicht wie alle anderen einfach zu deaktivieren. Allerdings, selbst wenn ich einen festen einstelle, um so wieder http request von meinem Loxone zu FHEM senden zu können, funktioniert dies nicht mit der Anstellung des Token. Das ist ja hier (https://wiki.fhem.de/wiki/CsrfToken-HowTo#csrfToken_abschalten) ja ganz gut beschrieben.
Ich stelle quasi das WEB attribut auf einen festen Token alá " attr WEB.* csrfToken <beliebige Folge aus Zeichen und Zahlen>".
Doch FHEM nutzt, auch nach einem shutdown restart, immer noch eigene Tokens.
Zitat von: Breaked am 05 März 2017, 09:48:10
Guten Morgen,
für die kurze Zwischenfrage möchte ich kein extra Thema öffnen.
Ich habe vor, den csrf token zu nutzen und nicht wie alle anderen einfach zu deaktivieren. Allerdings, selbst wenn ich einen festen einstelle, um so wieder http request von meinem Loxone zu FHEM senden zu können, funktioniert dies nicht mit der Anstellung des Token. Das ist ja hier (https://wiki.fhem.de/wiki/CsrfToken-HowTo#csrfToken_abschalten) ja ganz gut beschrieben.
Ich stelle quasi das WEB attribut auf einen festen Token alá " attr WEB.* csrfToken <beliebige Folge aus Zeichen und Zahlen>".
Doch FHEM nutzt, auch nach einem shutdown restart, immer noch eigene Tokens.
Moin,
nur zur Sicherheit nachgefragt, Du machst nach einem attr WEB.* csrfToken <beliebige Folge aus Zeichen und Zahlen> vor dem shutdown restart auch ein save?
Mir ist das nämlich komischerweise bei meinen Tests auch immer passiert.
Edit: Gerade probiert, Du hast Recht, der gesetzte Token hält nur bis zum nächsten shutdown restart. Er wird für das WEB sofort aktiv, bleibt als Attribute auch stehen, aber FHEM generiert nach shutdown restart einen neuen.
Bei einem selbst definiertem WEB funktioniert auch der gesetzte Token dauerhaft, so hatte ich gestern nämlich auch getestet.
Aus meiner Sicht ist dies nicht permanente Verhalten nur beim WEB 8083 so. bei 8084 und 8085 funktioniert es auch mit gesetztem Token.
Gruß Otto
Hey Otto,
danke für deine Antwort.
Puh, ich war mir davor eigentlich sicher, dass ich vor dem restart ein save mache, aber jetzt wo du es erwähnst... :P Werde es gleich nochmals testen.
Edit: Allerdings bearbeite ich i.d.R. die cfg direkt und mache dann natürlich "save config".
Dank deiner Test bestätigt sich, dass ich nicht ganz auf den Kopf gefallen bin.
Ggf. werde ich dann mir die Mühe machen müssen, eine Eigenständige Instanz auf einem anderen Port für meine Loxone-Steuerung zu öffnen und diese dann mit einem fixen Token zu versehen.
Eine andere Lösung für die Problematik kommt mir gerade nicht in den Sinn.
Es wäre halt schön gewesen, wenn ich die dynamischen Tokens weiter nutzen könnte und trotzdem meine HTTP Request ohne Probleme ausführen kann. Eventuell ist aber auch sonst noch niemand auf das Problem gestoßen.
EDIT2: Bis die ganze Problematik um die CSRF Token und der Ansteuermöglichkeit für einen cmd Befehl gelöst ist, habe ich nun doch kurzen Prozess gemacht und die Funktion deaktiviert. Wäre der riesige Zeitaufwand nicht nötig, würde ich dieses Sicherheitsfeature sicherlich nutzen, doch derzeit klammere ich das Ganze lieber doch noch aus.
Zitat von: Breaked am 05 März 2017, 16:59:27
Ggf. werde ich dann mir die Mühe machen müssen, eine Eigenständige Instanz auf einem anderen Port für meine Loxone-Steuerung zu öffnen und diese dann mit einem fixen Token zu versehen.
Hi Breaked,
Aber das das wäre aus meiner Sicht die beste Lösung ich habe das hier exakt beschrieben. -> https://wiki.fhem.de/wiki/CsrfToken-HowTo#API_Web
Da kannst Du die Standard WEBs mit dynamischen Token nutzen, und brauchst bei Deiner Steuerung gar nichts umzubauen, außer den Port.
Gruß Otto
Das sieht nach einer guten Lösung aus, aber grundsätzlich möchte ich es ja schon nutzen. Geht aber derzeit wahrscheinlich nicht anders zu lösen.
Zitat von: CoolTux am 02 März 2017, 20:20:10
Vorschlag. Zweite Webinstanz, sich über allow informieren und wie man es am besten konfiguriert. Zusätzlich festen Token als minimale CSRF Sicherung.
Kannst du das ein wenig genauer beschreiben, was du mit "allow informieren" meinst? Auch die ideale Konfig. würde mich interessieren. Seit durch mein Handy zwei weitere, offene WEB Instanzen habe, grummelt mir der Bauch...
// edit: du meinst das allowFrom Attribut, richtig?
Gruß
Ronny
Hallo Ronny,
Schau mal hier, da ist ganz gut beschrieben
https://wiki.fhem.de/wiki/FHEMWEB#Sicherheit
Grüße
Leon
Hallo!
Ich wärme mal dieses alte Thema mal auf.
Werte von Geräten auslesen und auch setzen klappt ganz gut.
Nun würde ich aber gerne alle Geräte in einem Raum auflisten, damit ich weiß, was in diesem Raum vorhanden ist um dann die entsprechenden Geräte abfragen zu können.
Ist sowas möglich?
Hintergrund: ich steuere die Heizung mit Max!-Thermostaten direkt über den Cube, der ja alle Räume organisiert.
Da die original Firmware aber Grütze ist möchte ich auch diese Cubes umflashen. Dann müsste FHEM die Räume organisieren.
Die Steuerung erfolgt über PHP. Ein Belegungsplan wird abfragt, dann die Raumtemperaturen ermittelt und zum passenden Zeitpunkt die Thermastate auf die Wunschtemperatur setzt.
Gruß,
Burkhard