Autor Thema: Ich wünsche mir das die FHEM User etwas aufmerksamer werden  (Gelesen 2016 mal)

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Guten Morgen liebe FHEM User und FHEM Mitstreiter,

Aus aktuellem Anlass habe ich beschlossen einen Wunsch an die FHEM User zu äußern.
Worum geht es. Ganz klar, es geht um das featureLevel 5.8 was vor ein paar Tagen aktiviert wurde. Was war passiert? Einige Funktionen, welche bereits seit Monaten oder gar einem Jahr in FHEM Schlummern wurden mit dem umschalten auf das featureLevel 5.8 als Standard aktiviert. Unter anderem gehörte dazu der csrf Token. Und hier gab es nun mit einigen ThirdPart Anwendungen und Lösungen (eigene get cmd Aurfufe, Taskerautomatisierungen) Probleme, weil diese nicht mehr einfach einen ?cmd Befehlsaufruf zu ließen.
Doch warum wurde das gemacht und was genau ist CSRF? Die meisten User haben sich nicht mal die Mühe gemacht zu schauen was CSRF eigentlich ist. Nein sie haben lieber das ganze deaktiviert und meinten dann na ich bin doch in meinem eigenen Netzwerk oder ich benutze ein VPN. NEIN!! Das hat damit rein gar nichts zu tun. Auch im eigen Netzwerk und über VPN ist der Angriff möglich.
Bitte bitte informiert Euch doch bei so wichtigen Dingen wie Sicherheit erstmal was genau das was hier erwähnt wurde bedeutet.

Doch was mich noch viel mehr ärgert. Es wird in diesen Foren Thread und Seitenweise darüber diskutiert das FHEM nur für interne Netze sicher ist und das sowas ja gar nicht geht und was man da machen kann. Es werden Empfehlungen und Anleitungen gegeben wie man einen ReverseProxy mit Passwort oder gar Zertifikat aufbaut, es werden VPN Lösungen präsentiert ABER WENN dann wirklich eine Sicherheitslösung angeboten wird für einen tatsächlich Sicherheitsrelevanten Bereich dann wird dieser einfach abgeschalten nur weil man zu faul ist sich darüber zu Informieren.
Es ist egal ob Ihr VPN habt oder ob Ihr in Eurem eigenen Netz seit. Im einfachsten Fall reicht es aus das Ihr einen zweiten Tab im Browser habt und eine Seite Aufruft die Schadcode enthält und schon kann auf den ersten Tab zugegriffen werden wo FHEM WEB gerade offen ist und ein CMD ausgeführt werden. (ACHTUNG ERKLÄRUNG WURDE MIT ABSICHT EINFACH GEHALTEN.)
Wenn sich also Rudi und die anderen Entwickler die Mühe machen so ein sinnvolles Sicherheitsfeature ein zu bauen, dann benutzt es doch bitte.

Und bitte bitte Informiert Euch mehr bei wichtigen Themen. Gerade wenn es um Sicherheit geht. Wir können nicht jeden einzelnen User erklären wie die Welt funktioniert, soviel Zeit haben wir einfach nicht. Oder FHEM bleibt auf der Strecke und kümmern uns darum Euch zu erklären über das hier und jetzt und was Schrödingers Katze damit zu tun hat.



Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
Gefällt mir Gefällt mir x 5 Zustimmung Zustimmung x 7 Liste anzeigen

Offline Thyraz

  • Full Member
  • ***
  • Beiträge: 332
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #1 am: 03 März 2017, 10:03:07 »
Ich denke das Problem ist, dass nicht jeder User hier das nötige KnowHow hat um das für seine Use-Cases umzusetzen.
Man hat ja selbst in vielen Modulthreads gesehen, dass auch der eine oder andere Modul-Developer kurz etwas ratlos da stand.

Evtl. sollte man im 5.8 Ankündigungsthread noch Best-Practice Beispiele und Tipps verlinken?
(Und eben auch genau deine Hinweise, dass das temporäre Abschalten auch in privaten Netzen ein Sicherheitsproblem ist.)
Also Aufruf über Shell, Web, etc.
Welche Möglichkeiten hab ich das ganze dennoch recht gut abzusichern, wenn ich für einen Use Case keine dynamischen Token rausbekomme, usw.

Gibt ja mittlerweile viele gute Beiträge, verteilt über diverse Threads.
Von Rudi hab ich z.B. gestern glaub irgendwo einen Einzeiler gesehen, um den Token auf Shell Ebene zu ziehen.
Von dir kam glaub auch irgendwo ein guter Tip, notfalls ein eingeschränktes Webdevice dazu zu verwenden, ggf. mit festem Token (besser als keiner).


Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #2 am: 03 März 2017, 10:07:30 »
Ich kann verstehen das nicht jeder das nötige KnowHow hat, aber darum geht es auch nicht. Wenn ich etwas lese von Sicherheit und Sicherheitstoken sollte bei jedem erstmal die Aufmerksamkeitssynapsen anspringen. Gerade wenn ich eine Hausautomatisierung habe. Es sollte versucht werden im Selbststudium heraus zu finden worum es genau geht.
Immerhin schaffen diese Leute es ja auch einen technischen Artikel/Anleitung um zu setzen (VPN/ReverseProxy).
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
Informativ Informativ x 1 Liste anzeigen

Offline mahowi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 661
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #3 am: 03 März 2017, 10:13:01 »
Wobei es auch generell um die Aufmerksamkeit der User geht, bzw. darum erstmal nach Antworten zu suchen. Als debian.fhem.de nicht erreichbar bzw. nicht mehr über https erreichbar war, gab es dazu gefühlte hundert Threads mit genau denselben Fragen.
CUBe (MAX): HT, WT+, FK, EcoTaster | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #4 am: 03 März 2017, 10:17:26 »
Hi,
ich frage mich, ob das dieselben Leute sind. Ich meine die, die sich über ReverseProxy, HTTPS etc. Gedanken machen und solche, die das Token abschalten. (Ich habe übrigens auch immer noch so meine Probleme, zu verstehen, warum der Token das ganze sicherer macht. Es wird vielleicht ein klein wenig komplizierter, aber möglich ist der Angriff doch immer noch, oder?)   
Von wegen Aufregung und Upgrade auf 5.8: Hier frage ich mich, ob die Leute das auch bei anderer Software so machen. Also z.B. den Upgrade auf Windows 10 an dem Tag, an dem es verfügbar ist, und am besten noch auf dem Rechner, auf dem ich meine Rechnungen schreibe. Das macht doch eigentlich auch keener, oder?
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #5 am: 03 März 2017, 10:35:57 »
Muß mich entschuldigen. Heute Morgen war ich nicht Aufmerksam  ::)
Habe das jetzt mal in das Ansatzweise richtige Forum verschoben.

@Thorsten
Ein Angriff ist irgendwie immer möglich. Machen wir uns nichts vor, es wird nie 100% Sicherheit geben. Aber diese eine kleine Token erhöht den Schutz vor einem Möglichen CSRF Angriff enorm.
Du findest sehr gute Beispiele auf der verlinkten Wikiseite unter Beispiele.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16439
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #6 am: 03 März 2017, 10:40:42 »
Zitat
Ich habe übrigens auch immer noch so meine Probleme, zu verstehen, warum der Token das ganze sicherer macht. Es wird vielleicht ein klein wenig komplizierter, aber möglich ist der Angriff doch immer noch, oder?

Es geht darum, dass man auf einer Seite wie meinFhemBlog.de oder gar forum/wiki.fhem.de ein Boesewicht N "Bilder" reinstellt ala:
<img src="http://192.168.178.1+N:8083/fhem?cmd=set .* off">

Wenn der Benutzer im Browser die FHEMWEB-Seite irgendwann nach dem Browser Start aufgerufen hat (das FHEMWEB Tab kann inzwischen schon zu sein), dann ist der Zugriff auf FHEMWEB von der Boesewicht-Seite moeglich, da der Browser basicAuth gemerkt hat. VPN/reverseProxy mit Zertifikat ist egal, auch dass ich FHEMWEB nur von Zuhause aufrufe.

Ab 5.8 werden FHEM Befehle nur mit einem gueltigen csrfToken ausgefuehrt, d.h. das Obige funktioniert nicht.

Die "boese" Seite kann mW nicht an das csrfToken kommen, da diese von einer anderen Domain (== URL) stammt, und aktuelle Browser es nicht zulassen, dass man per JS solche Daten analysiert, sei es aus einem iFrame oder per XHR. ES SEI DENN man erlaubt das explizit in FHEMWEB via das CORS Attribut.
D.h. mit CORS ist dieser Angriffstyp schwerer geworden, ohne CORS unmoeglich.

Wenn ich was falsch verstanden habe, dann bitte mich  (dringend) korrigieren :)
Gefällt mir Gefällt mir x 1 Informativ Informativ x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #7 am: 03 März 2017, 10:44:50 »
So in der Art habe ich das auch verstanden. Gibt im Netz einige Beispiele/Szenarien für eine solche Manipulation/Angriff.

Ich denke das die User genau das erwartet hätten, eine solche Erklärung im Informationsthread zu 5.8. Gut kann man machen, aber ich finde immer noch das auch die User in der Pflicht sind. Fehlt eine solche Erklärung sollte man sich informieren.
« Letzte Änderung: 03 März 2017, 10:48:04 von CoolTux »
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Online KölnSolar

  • Hero Member
  • *****
  • Beiträge: 1495
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #8 am: 03 März 2017, 10:56:17 »
Hi Leon,
erst mal die Frage: Warum stellst Du den Beitrag ins Subforum zum CUL-Development  ::)
Ein newbie hätte sich dafür schon einen Rüffel eingefangen.  ;) Zeigt aber vermutlich nur, wie sehr Du Dich geärgert hast  :'(

Ansonsten gebe ich Dir einerseits Recht, muss Dir aber insofern widersprechen, dass es eben eine Menge User gibt, die sicherlich schon alleine beim Lesen des Ankündigungsthreads und der Stichwörter "pearlSyntaxCheck" und "CSRFToken" dicht gemacht haben. Es gibt eben die User, die ihren WLAN-Schlüssel und Routerzugangsdaten immer noch im Auslieferungszustand haben. Die selben Menschen möchten aber auch gerne FHEM nutzen. Und, wenn dann noch als Lösung eines Problems vorgeschlagen wird: Es gibt ein Attribut, mit dem sich die Probleme abstellen lassen ? ! ? ! ? ! Was wollen wir dann von den Nicht-ITlern anderes erwarten, als dass das Attribut gesetzt wird und diese eigentlich falsche Vorgehensweise sich auch noch wie ein Virus in der Community ausbreitet ?

Ich bin daher der Meinung, dass bei solchen besonderen Themen wie Sicherheit etc. anders verfahren werden muss.
1. Das Abschalten über ein Attribut darf überhaupt nicht kommuniziert werden !
2. Anstatt die Änderung technisch korrekt zu beschreiben, sollten die denkbaren(ja und man kann als Entwickler nicht an alles denken) in ihren Symptomen beschrieben und Lösungsmöglichkeiten beschrieben werden. So etwas fehlte in der Ankündigung völlig.
3. Und dann sollte es ein vorübergehendes Unterforum für die Fälle geben, denen die vorgedachten Symptom- und Lösungsbeschreibungen nicht geholfen haben. Und dort stelle ich mir die Zugriffsberechtigungen dann etwas anders als üblich vor. Jeder kann ein Thema eröffnen. Zu diesem Thema können aber nur der TE selber und User mit "übergreifenden" Zugangsberechtigungen" antworten, also User, die auch wirklich wissen wovon sie reden, wie im konkreten Fall: Du, Rudi, Udo, Andre..... Landet dann doch unvermeidbar eine Fragestellung in einem anderen Unterforum können unsereiner auf das spezielle Subforum und die dortigen Beiträge verweisen(und mehr sollte man dann auch nicht mehr machen). (Ob so was in unserem Forum realisierbar ist, weiß ich natürlich nicht.)

Und mal allgemein: Insgesamt wird meines Erachtens das Thema Sicherheit etwas zu stiefmütterlich behandelt. Ich nenn hier mal nur kurz als Stichwort "Alexa", Port am Router öffnen und dann ?????

Grüße Markus

Edit: Zwischenzeitlich gab es einige Antworten, aber ich belasse meinen Post ohne darauf einzugehen  ;)
« Letzte Änderung: 03 März 2017, 10:58:24 von KölnSolar »
RPi3/2 Jessie-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3980
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #9 am: 03 März 2017, 10:57:01 »
wenn jemand die Zeit und Lust hat dann kann "er||sie" im wiki(?) eine demoseite aufsetzen:

als html quellcode einfüggen:

<img src="http://192.168.178.1:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.2:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.3:8083/fhem?cmd=set .* off">
...

<img src="http://192.168.178.252:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.253:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.254:8083/fhem?cmd=set .* off">

vg
joerg

edit:

beliebig per js  (XMLHttpRequest) zu verfeinern. Local netmask, andere ports etc ... wird für user die es "erleben" sicher unterhaltend ... ;)
« Letzte Änderung: 03 März 2017, 11:02:05 von herrmannj »
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse
Informativ Informativ x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #10 am: 03 März 2017, 11:06:15 »
Die "boese" Seite kann mW nicht an das csrfToken kommen, da diese von einer anderen Domain (== URL) stammt, und aktuelle Browser es nicht zulassen, dass man per JS solche Daten analysiert, sei es aus einem iFrame oder per XHR. ES SEI DENN man erlaubt das explizit in FHEMWEB via das CORS Attribut.
D.h. mit CORS ist dieser Angriffstyp schwerer geworden, ohne CORS unmoeglich.
Diesen Zusammenhang hatte ich tatsächlich bisher nicht gesehen. Danke, mit dieser Erklärung wird es klar.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #11 am: 03 März 2017, 11:09:06 »
1. Das Abschalten über ein Attribut darf überhaupt nicht kommuniziert werden !
Meiner Meinung nach ist das Vorgehen in dieser Hinsicht bisher richtig. Ich würde es so machen:
  • Release 5.7: Token einbauen, aber per Default abgeschaltet lassen.
  • Release 5.8: Den Default ändern, aber abschaltbar machen
  • Release 5.9: Nicht mehr abschaltbar.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 1079
  • Hausaufgaben schon gemacht?
    • Perpetual beta
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #12 am: 03 März 2017, 11:10:25 »
Von wegen Aufregung und Upgrade auf 5.8: Hier frage ich mich, ob die Leute das auch bei anderer Software so machen. Also z.B. den Upgrade auf Windows 10 an dem Tag, an dem es verfügbar ist, und am besten noch auf dem Rechner, auf dem ich meine Rechnungen schreibe.
Gehört eigentlich nicht so richtig in diesen Thread, aber ich habe da mal eine Verständnisfrage dazu, da offensichtlich auch andere hier im Forum ein derartiges Verständnis von dem update haben.

Diese Sichtweise deckt sich nämlich nicht mit dem, was ich bisher zu updates innerhalb FHEM verstanden hatte:
- Wir gehen bei Problemlösungen grundsätzlich davon aus, dass der User ein aktuelles FHEM hat. Da gibt es aber eigentlich kein Nebeneinander von 5.7 und 5.8 (anders als bei Win7 und Win10, wo beide aktuell sein können), sondern nur genau ein aktuelles Modul xx_MODUL.pm. Das Verhalten des Moduls kann dann über den eingestellten FeatureLevel eingestellt werden, wobei ein "Downgrade" eigentlich nicht wirklich zu empfehlen ist, weil man sonst möglicherweise sicherheitsrelevante Dinge "nebenbei" ausschaltet und das dann ggf. vergißt bzw. gar nicht mitbekommt.
- Hat man ein Problem mit einem Modul, hat man also eigentlich keine Wahl als (mindestens) dieses Modul auf einen (idR.) aktuellen Stand zu bringen und sollte das auch tun.

Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?

Und mal allgemein: Insgesamt wird meines Erachtens das Thema Sicherheit etwas zu stiefmütterlich behandelt.
Stimme zu, möchte aber anmerken, dass das imo deutlich besser geworden ist!

Gruß, Beta-User
Ubuntu 16.04@ARM-TV-Box | ConfigDB | VCCU | MySensors seriell (2.1.1) | DS18B20@MySensors | Milight@ESP-GW | SIGNALduino

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #13 am: 03 März 2017, 11:25:19 »
Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?
Meiner Meinung nach sollte ein "Normaluser" tatsächlich dafür sorgen, dass alles auf dem neusten Stand ist. Problematisch wird es halt dann, wenn das Problem im Produktivsystem auftritt und ansonsten alles rund läuft. Ich würde da nicht immer pauschal zum "update" raten.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #14 am: 03 März 2017, 11:25:36 »
Gehört eigentlich nicht so richtig in diesen Thread, aber ich habe da mal eine Verständnisfrage dazu, da offensichtlich auch andere hier im Forum ein derartiges Verständnis von dem update haben.

Diese Sichtweise deckt sich nämlich nicht mit dem, was ich bisher zu updates innerhalb FHEM verstanden hatte:
- Wir gehen bei Problemlösungen grundsätzlich davon aus, dass der User ein aktuelles FHEM hat. Da gibt es aber eigentlich kein Nebeneinander von 5.7 und 5.8 (anders als bei Win7 und Win10, wo beide aktuell sein können), sondern nur genau ein aktuelles Modul xx_MODUL.pm. Das Verhalten des Moduls kann dann über den eingestellten FeatureLevel eingestellt werden, wobei ein "Downgrade" eigentlich nicht wirklich zu empfehlen ist, weil man sonst möglicherweise sicherheitsrelevante Dinge "nebenbei" ausschaltet und das dann ggf. vergißt bzw. gar nicht mitbekommt.
- Hat man ein Problem mit einem Modul, hat man also eigentlich keine Wahl als (mindestens) dieses Modul auf einen (idR.) aktuellen Stand zu bringen und sollte das auch tun.

Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?
Stimme zu, möchte aber anmerken, dass das imo deutlich besser geworden ist!

Gruß, Beta-User

Puh, das ist jetzt nicht ganz so einfach zu erklären. Es gibt nicht wirklich Versionen bei FHEM. Es gibt nur Zustände
1. Es gibt immer einen Tagesaktuellen Stand. Damit die User die auf fhem.de landen nicht denken hier passiert ja gar nichts wenn sie sehen das das letzte Packet von vor 2 Jahren ist, wird alle ~~~halbe Jahre ein Packet geschnürt und bereitgestellt. Dieses Packet bekommt eine Versionsnummer welche die des featureLevels entspricht und das Packet ist auf das featureLevel eingestellt.

2. Es werden im laufe der Entwicklung neue Funktionen in die Kernkomponenten von FHEM eingebaut. Diese werden von Testern getestet. Wenn besondere Sachen Einzug halten welches grundlegende FHEM Schnittstellen betrifft, so wird den Modulentwicklern Zeit gegeben Ihre Module entsprechend an zu passen. FHEM hat eine Umfangreiche API womit man sich sehr viel Eigenentwicklung spart und sich auf die Grundfunktion seines Modules konzentrieren kann. Wird die API geändert oder Erweitert muß der Modulentwickler aber seine Module anpassen.
Und genau das Zeitgeben erfolgt über die Freischaltung von sogenannten featureLevels.
« Letzte Änderung: 03 März 2017, 11:27:11 von CoolTux »
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 1079
  • Hausaufgaben schon gemacht?
    • Perpetual beta
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #15 am: 03 März 2017, 11:48:10 »
Danke für die Klarstellungen.
Dass es neben der aktuellen Version immer die Möglichkeit gibt, Module von updates auszuschließen und/oder die Entwicklerversionen einzuspielen, war schon klar, aber im Kern gibt es also für den normalen Anwender nur die eine aktuelle Version, und es ist auch (wieder nur der Tendenz nach) empfehlenswert, diese zu nutzen.

Da es neulich zum Thema debian-Paket ja auch schon einige reichlich schräge und mehrfache Posts gab:
Die update- und FeatureLevel-Systematik scheint bei weitem nicht jedem User geläufig zu sein, selbst wenn manche hier das bereits zum 2. oder 3. Mal mitmachen. Mal wieder ein Wunsch dazu: Hier wären eine systematische Darstellung im Wiki evtl. hilfreich. Sofern es sowas bereits geben sollte: Es steht jedenfalls nicht an prominenter Stelle, mindestens bei den FAQ hätte ich es vermutet oder als Link in den Änderungshinweisen oben rechts auf den Forumsseiten (jedenfalls manche Leute lesen sowas ;), @Thorsten: manche warten bei entsprechenden Warnsignalen dann auch erst mal ab bis die ersten Bauchschmerzen vorbei sind).

Gruß, Beta-User
Ubuntu 16.04@ARM-TV-Box | ConfigDB | VCCU | MySensors seriell (2.1.1) | DS18B20@MySensors | Milight@ESP-GW | SIGNALduino

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1324
  • Wuppertaler Wimpelbeauftragter
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #16 am: 03 März 2017, 11:51:22 »
wäre es da nicht sinnvoll ein eigenes Unterforum unter FHEM einzurichten?

ohne Rudis Beispiel:
<img src="http://192.168.178.1+N:8083/fhem?cmd=set .* off">
war mir Inhaltlich zwar schon klar geworden aber zu Abstrakt um einen direkten Praxisbezug herzustellen :-(

Nach dem Beispiel muss ich Millionär geworden sein, so wie die Groschen gefallen sind
Jetzt auf nem I3 und primär Homematic

kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #17 am: 03 März 2017, 11:59:42 »
Naja ich finde das ja auch total lieb von Rudi das so klar zu stellen. Aber seien wir mal ehrlich, es handelt sich hierbei um einen Exploit. Also quasi eine fertig zusammengebaute, geladene und entsicherte Waffe. Mal kurz drüber nachdenken bitte.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #18 am: 03 März 2017, 12:04:44 »
Naja ich finde das ja auch total lieb von Rudi das so klar zu stellen. Aber seien wir mal ehrlich, es handelt sich hierbei um einen Exploit. Also quasi eine fertig zusammengebaute, geladene und entsicherte Waffe. Mal kurz drüber nachdenken bitte.
https://www.amazon.de/Physiker-Eine-Kom%C3%B6die-zwei-Akten/dp/3257230478
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3980
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #19 am: 03 März 2017, 12:23:41 »
Naja ich finde das ja auch total lieb von Rudi das so klar zu stellen. Aber seien wir mal ehrlich, es handelt sich hierbei um einen Exploit. Also quasi eine fertig zusammengebaute, geladene und entsicherte Waffe. Mal kurz drüber nachdenken bitte.
imho mehr als völlig in Ordnung!

Ist doch usus das man die Existenz einer Bedrohung demonstriert. Und es ist eben *kein* exploit weil fhem im Auslieferungszustand das Token setzt. Rudi demonstriert WAS passieren kann (da geht noch mehr ;) ) wenn man das token auf "none" setzt. Wir haben ja auch einige threads hier die den Tenor setzen "wozu das denn?".-> Qed !

vg
joerg
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Thyraz

  • Full Member
  • ***
  • Beiträge: 332
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #20 am: 03 März 2017, 12:37:56 »
Naja ich finde das ja auch total lieb von Rudi das so klar zu stellen. Aber seien wir mal ehrlich, es handelt sich hierbei um einen Exploit. Also quasi eine fertig zusammengebaute, geladene und entsicherte Waffe. Mal kurz drüber nachdenken bitte.

Den Enthusiamus in allen Ehren, aber wie viele Monate bzw. Jahre gab es das Feature schon in FHEM bevor es mit FeatureLevel 5.8 per Standard gesetzt wurde?
Und nun mal Hand hoch wie viele das schon lang vor 5.8 händisch bei sich aktiviert hatten. :P
Strecken da außer Rudi noch ein paar? ;)

Dafür finde ich den aufgeregten Tonfall mit dem hier Neulinge in manchen Threads angegangen werden schon etwas fragwürdig.

Man stelle sich vor, man macht ein Update und plötzlich funktioniert die gesamte Bedienoberfläche, welche die Familie benutzt nicht mehr (z.B. FTUI) oder Ähnliches.
Das ich hier dann erstmal einen schnellen Fix suche ist doch durchaus verständlich.
(Auch wenn ich bei sowas normal eher den Weg eines Restores meinem FHEM Updates wählen und dann bei etwas mehr Freizeit Ursachenforschung betreiben würde.)

Wenn derjenige dann liest, dass das Feature schon seit Ewigkeiten ausgeschaltet existiert, dann hätte ich auch wenig Bauchschmerzen das Ganze nochmal ein paar Tage zu deaktiveren.
Nicht jeder im Forum kann soviel Zeit in sein Smart Home stecken wie viele von uns das tun.

Ich äußere hiermit zusätzlich zum Wunsch nach mehr Aufmerksamkeit der User noch den Wunsch nach mehr Gelassenheit im Umgang miteinander ;)

Wie gesagt, wenn zu Beginn schon eine etwas ausführlichere Erklärung zum Ganzen existiert hätte wären evtl. weit weniger Frage gekommen.
Denn den rot angepinnte Thread werden schon sehr viele davor angeklickt haben...
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #21 am: 03 März 2017, 12:51:09 »
Dafür finde ich den aufgeregten Tonfall mit dem hier Neulinge in manchen Threads angegangen werden schon etwas fragwürdig.

Da gehe ich mit und fühle mich auch persönlich zu Recht angesprochen. Aber eventuell warst Du oder der andere gerade der 12 mit dem 7 Thread der das selbe Symptom hatte. Irgendwann ist das bisschen viel. Und ja ich hätte auch einfach weiter schalten können und nichts schreiben. Bei FTUI zum Beispiel ist die Fehlermeldung oder das Fehlerbild in der Tat nicht eindeutig.
An anderer Stelle hingegen findet man Hinweise im Log, aber es wird sich nicht die Mühe gemacht mal zu schauen. Wenn ich eigene Implementierungen verwende bin ich dafür verantwortlich wenn ich Probleme habe und Fragen dazu ein exaktes Fehlerbild dar zu stellen und wenigstens ins Log zu schauen. Viele taten es nicht. Da gab es Leute mit einer eigenen Webseite wo man denkt ok bisschen KnowHow scheint da zu sein.
Es gibt ein Punkt bei ein und dem selben Fehlerbild wo man sich den folgenden User erziehen muß. Wenigstens ein bisschen. Und niemand wird beleidigt oder unter der Gürtellinie attackiert. Es wird nur ein bisschen der Ton schroff oder es werden Metaphern verwendet damit es Bildlicher dargestellt wird.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #22 am: 03 März 2017, 13:08:11 »
@rudi: mit dem token sollte so ein angriff über wiki oder forum nicht mehr möglich sein. für externe seiten für die jemand die komplette seite unter kontrolle hat lässt sich das problem so glaube ich aber nicht lösen. es sind ja die cors header der haupt seite relevant. und dort kann jemand durchaus die eigenen seite oder dem eigenen js code erlauben eine verbindung zu fhem aufzubauen.

die cors header solle ja verhindern das durch einen link der auf einer seite eingebettet ist die seite selber kompromittiert wird. nicht umgekehrt.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 3980
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #23 am: 03 März 2017, 13:12:41 »
@rudi: mit dem token sollte so ein angriff über wiki oder forum nicht mehr möglich sein. für externe seiten für die jemand die komplette seite unter kontrolle hat lässt sich das problem so glaube ich aber nicht lösen. es sind ja die cors header der haupt seite relevant. und dort kann jemand durchaus die eigenen seite oder dem eigenen js code erlauben eine verbindung zu fhem aufzubauen.

die cors header solle ja verhindern das durch einen link der auf einer seite eingebettet ist die seite selber kompromittiert wird. nicht umgekehrt.
...  hmm, gute idee. Du könntest recht haben.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #24 am: 03 März 2017, 13:30:24 »
die cors header solle ja verhindern das durch einen link der auf einer seite eingebettet ist die seite selber kompromittiert wird. nicht umgekehrt.
Das wirft die Frage auf, woher die aufgerufene Seite (also FHEMWEB) überhaupt weiß, dass es von einem Skript aufgerufen wurde oder von einem Browser. Ok, theoretisch ist da eine Browserkennung, aber die kann man ja einfach "simulieren".
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16342
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #25 am: 03 März 2017, 13:36:15 »
das weiß sie nicht. und eine browsererkennung lässt sich umgehen.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #26 am: 03 März 2017, 13:40:12 »
das weiß sie nicht. und eine browsererkennung lässt sich umgehen.
Das meinte ich ja mit "simulieren".
Ich habe den Eindruck, dass der CSRF-Angriff durch das (oder den?) Token zwar (viel?) schwieriger wird, aber nicht unbedingt unmöglich.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8623
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #27 am: 03 März 2017, 13:45:36 »
Aber ist es nicht besser den Schlüssel im Garten zu vergraben als ihn im Schloß stecken zu lassen? Von daher ist es eine gute Lösung.    :D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #28 am: 03 März 2017, 13:57:30 »
Aber ist es nicht besser den Schlüssel im Garten zu vergraben als ihn im Schloß stecken zu lassen? Von daher ist es eine gute Lösung.    :D
Du hast ja Recht. Die meisten Diebstähle lassen sich ja auch verhindern, wenn der Dieb länger als 2 Minuten braucht, um ins Haus zu kommen. Ich will ja nur die Zusammenhänge verstehen.
Außerdem: Manchmal ist es auch besser, den Schlüssel stecken zu lassen. Das war mal in Nizza so. Da gab es so viele eingeschlagene Autoscheiben, dass man besser den Schlüssel hat stecken lassen. Dann kommen die Diebe zwar auch ins Auto, aber nachher ist wenigstens nichts kaputt.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9787
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #29 am: 03 März 2017, 22:46:12 »
Zitat
Außerdem: Manchmal ist es auch besser, den Schlüssel stecken zu lassen. Das war mal in Nizza so. Da gab es so viele eingeschlagene Autoscheiben, dass man besser den Schlüssel hat stecken lassen. Dann kommen die Diebe zwar auch ins Auto, aber nachher ist wenigstens nichts kaputt.
Also so frei nach dem Motto - ich lass den Haustürschlüssel stecken (weil ja rundherum eingebrochen wird) - dann ist zwar die Tür noch ganz aber das Haus dennoch leer.
Machst du das in echt auch ???

Ich überleg grad was die Versicherung dazu sagt (nein ich überleg nicht wirklich weil ich mir denken kann was die sagen wird).
Edith: Traurig wenn die Argumente in diese Richtung gehen das der Einbrecher so wenig wie möglich an Schaden anrichten muss um an sein Objekt der Begierde zu kommen.
« Letzte Änderung: 03 März 2017, 22:52:00 von Puschel74 »
Cubietruck als Server mit DBLog
CUNO für FHT80B und FS20, HM-Lan, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #30 am: 03 März 2017, 22:59:18 »
Machst du das in echt auch ???
Natürlich hat man das Auto vorher leergeräumt, so dass es nichts zu holen gab.
Bevor jetzt der nächste Einwand kommt: Nein, das ist nicht wirklich mit dem, was eigentlich in diesem Thread diskutiert wird, vergleichbar.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9787
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #31 am: 03 März 2017, 23:05:45 »
Natürlich hat man das Auto vorher leergeräumt, so dass es nichts zu holen gab.
Das heisst der Dieb hat dann zur Not das leere Auto kurzgeschlossen und mitgenommen?
Ich denke mal dem war es egal das es leergeräumt war - zur Not hatte er ja das Auto noch.

Bevor jetzt der nächste Einwand kommt: Nein, das ist nicht wirklich mit dem, was eigentlich in diesem Thread diskutiert wird, vergleichbar.
Du hast damit angefangen.
« Letzte Änderung: 03 März 2017, 23:07:54 von Puschel74 »
Cubietruck als Server mit DBLog
CUNO für FHT80B und FS20, HM-Lan, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline jeschkec

  • Jr. Member
  • **
  • Beiträge: 70
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #32 am: 04 März 2017, 01:13:15 »
Das wirft die Frage auf, woher die aufgerufene Seite (also FHEMWEB) überhaupt weiß, dass es von einem Skript aufgerufen wurde oder von einem Browser. Ok, theoretisch ist da eine Browserkennung, aber die kann man ja einfach "simulieren".
Gruß,
   Thorsten

Das CSRF-Token hilft gegen CSRF-Angriffe über GET und POST, zum Beispiel gegen den folgenden. CORS-Checks kommen hier gar nicht zum Tragen.
<img src="http://fhem.example:8083/fhem?cmd=set%20WZ_Lampe%20on" width=0 height=0>
Vernünftig gesetzte CORS-Header dagegen helfen gegen CSRF-Angriffe über JavaScript, z.B. über XHR:
<script>
function request() {
var x = new XMLHttpRequest();
x.open("POST","http://fhem.example:8083/fhem",true);
x.setRequestHeader("Content-Type", "text/plain; charset=UTF-8");
x.send("cmd.wz_lampe=set%20wz_lampe%20off");
}
</script>
<body onload="request()">

Die Browserkennung ist kein Bestandteil der CORS-Checks. CORS definiert Ausnahmen in der SOP. Würde der Request von nicht von fhem.example kommen (fhem.example ist in Access-Control-Allow-Origin erlaubt), würde der XHR nicht ausgeführt. Außer natürlich man setzt Access-Control-Allow-Origin auf * (jeder Host) und deaktiviert damit effektiv die SOP. Dein Browser weiß, ob er diesen Request machen darf oder nicht, wenn er CORS/SOP implementiert hat. FHEM weiß davon nichts, sondern schickt nur Header.

CSRF-Token = FHEM prüft ob das Token korrekt ist.
CORS/SOP = Der Browser prüft ob der Request erlaubt ist.
2 FHEM auf Raspberry π, 3 FB (7490, 6490), 120 HomeMatic-Devices, 5 Echo Dot, MQTT
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #33 am: 04 März 2017, 08:16:28 »
Hi,
danke für die Erklärung. Es wird jetzt immer klarer. (Gell, Leon, ich bin sehr aufmerksam!)
Also der Browser versucht, einen vor einem "bösen Skript" zu schützen, während das CSRF-Token einen vor einem "bösen Link" schützt. Für letztere kann man ja schlecht eine SOP (Same Origin Policy) vorgeben.
CORS (Cross-Origin Resource Sharing) bedeutet jetzt, dass die potentiell angegriffene Website (also in unserem Fall FHEMWEB) erlauben kann, die SOP zu verletzen, indem immer (?) ein entsprechender CORS-Header mitgeschickt wird. Damit kann man dann z.B. einem UI, das auf einem anderen Rechner läuft, den Zugriff auf FHEMWEB erlauben. (FTUI im Standard ist das soweit ich verstehe egal, da es normalerweise von der selben "Domain" und demselben Port kommt wie FHEMWEB.)
Soweit so gut. Die nächste Frage drängt sich jetzt aber auf:
Aus der Doku von FHEMWEB:
Zitat
◦CORS
 If set to 1, FHEMWEB will supply a "Cross origin resource sharing" header, see the wikipedia for details.
...also schauen wir mal Wikipedia:
Zitat
Access-Control-Allow-Origin: http://foo.example
Fehlt da nicht was bei FHEMWEB? Wenn man nur CORS pauschal ein- und ausschalten kann, dann handelt man sich doch wieder ein Sicherheitsrisiko ein. Na gut, es gibt auch noch allowFrom, aber wäre es nicht besser, wenn man bei CORS (auch) die Liste der erlaubten <domain>:<port> angibt? ...oder wird das implizit schon gemacht?

Gruß,
    Thorsten
 
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline JoWiemann

  • Tester
  • Hero Member
  • ****
  • Beiträge: 1764
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #34 am: 04 März 2017, 09:03:41 »
Hm, mal ne Anmerkung. Selbst ein hochgradig aufmerksamen FHEM User würde unter dem Thread Titel keine Sicherheitsdiskussion vermuten, die auch noch sachlich und Informativ geführt wird. Bekommen wir das irgendwie geheilt, bzw. die wichtigen Ergebnisse nicht besser im Wiki zusammengefasst und einen Hinweis in der Commandref aufgenommen?!


Grüße Jörg

Gesendet von iPhone mit Tapatalk
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (493.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #35 am: 04 März 2017, 09:15:54 »
Wenn man nur CORS pauschal ein- und ausschalten kann, dann handelt man sich doch wieder ein Sicherheitsrisiko ein. Na gut, es gibt auch noch allowFrom, aber wäre es nicht besser, wenn man bei CORS (auch) die Liste der erlaubten <domain>:<port> angibt? ...oder wird das implizit schon gemacht?

Ich habe mal nachgeschaut, was das Attribut CORS tatsächlich macht. Et voílà:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin, Authorization, Accept
Access-Control-Allow-Methods:GET POST OPTIONS
So ganz 100% verstehe ich das nicht. Das bedeutet doch im Prinzip, dass damit GET,POST,OPTIONS von überall erlaubt wird.
Das mit den Credentials verstehe ich nicht (trotz https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS). Braucht man dafür nicht auch noch Access-Control-Allow-Origin? ...oder gilt das nur bei "preflighted" requests?

Hm, mal ne Anmerkung. Selbst ein hochgradig aufmerksamen FHEM User würde unter dem Thread Titel keine Sicherheitsdiskussion vermuten, die auch noch sachlich und Informativ geführt wird. Bekommen wir das irgendwie geheilt, bzw. die wichtigen Ergebnisse nicht besser im Wiki zusammengefasst und einen Hinweis in der Commandref aufgenommen?!
Ich stimme da voll zu, aber versteht das wirklich jemand auf einer Ebene, dass er (oder sie) es auch schlüssig erklären kann und es mit dem zusammenpasst, was das System tatsächlich tut? Für mich sieht es bisher nicht so aus. Das kann sich aber noch ändern...

Gruß,
   Thorsten


RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16439
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #36 am: 04 März 2017, 09:33:34 »
Zitat
Braucht man dafür nicht auch noch Access-Control-Allow-Origin?
Das kommt nur, wenn man Origin im Header gesendet hat:

my @origin = grep /Origin/i, @FW_httpheader;
$FW_headerlines = (AttrVal($FW_wname, "CORS", 0) ?
              (($#origin<0) ? "": "Access-Control-Allow-".$origin[0]."\r\n").
...

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #37 am: 04 März 2017, 09:40:13 »
Das kommt nur, wenn man Origin im Header gesendet hat:
Das verstehe ich jetzt aber gar nicht. D.h. die potentiell angreifende Seite schickt "Origin" im Header und daraufhin bekommt sie den Zugriff erlaubt? Das kann doch irgendwie nicht sein...
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline klaso

  • Full Member
  • ***
  • Beiträge: 124
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #38 am: 04 März 2017, 10:32:10 »
Es wird für fhemuser sicherlich nicht einfacher, wenn man weiterhin die Empfehlungen liest
https://forum.fhem.de/index.php/topic,16503.msg598710.html#msg598710
Da wird auch eine klare Linie benötigt, so wie niemand in der cfg wurschteln soll, soll auch keinem geraten werden, die sicherheitsmerkmale auszuhebeln.
Habe vollstes Verständnis für diesen Wunsch, viele machen sich wirklich nicht die mühe, nur ansatzweise mal nach Ursache/Wirkung/lösung zu suchen.....stattdessen wird neuer Thread erstellt.......übersichtlicher werden die Forumsbeiträge dann auch nicht, wenn man zu ein und dem selben problem unzählige Einträge findet, da leiden auch wir fhemuser selbst darunter.........quasi der Schuss ins Knie
VG
Klaso
PS: in dem oben genannten Artikel ist wenigstens noch ein Hinweis drin, bzgl. rückgängig machen
« Letzte Änderung: 04 März 2017, 10:34:12 von klaso »
Raspberry Pi 2 B+; Software: Raspbian Jessie, Fhem 5.8
ZWave, Enocean, FBAHAHTTP, ENIGMA2
Barebone mit openmedivault und Fhem5.8, MySQL, MyObis, VBUS LAN-Adapter in Fhem, Homematic CCU2; Jeelink mit TX29IT, HMCCU: Schnittstelle CCU2 - FHEM

Offline jeschkec

  • Jr. Member
  • **
  • Beiträge: 70
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #39 am: 04 März 2017, 16:22:20 »
Das verstehe ich jetzt aber gar nicht. D.h. die potentiell angreifende Seite schickt "Origin" im Header und daraufhin bekommt sie den Zugriff erlaubt? Das kann doch irgendwie nicht sein...

Prinzipiell hättest du Recht, gehörte nicht zur CORS-Implementierung, dass der Browser Origin über XHR nicht erlaubt:
<script>
function request() {
var x = new XMLHttpRequest();
x.open("POST","http://fhem.example.org:8086/fhem",true);
x.setRequestHeader("Content-Type", "text/plain; charset=UTF-8");
x.setRequestHeader("Origin", "example.org");
x.send("cmd.wz_lampe=set%20WZ_Lampe%20on");
console.log(x.responseText);
}
</script>
<body onload="request()">

Resultat in console.log:
Refused to set unsafe header "Origin"
2 FHEM auf Raspberry π, 3 FB (7490, 6490), 120 HomeMatic-Devices, 5 Echo Dot, MQTT

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3851
  • Finger weg von der fhem.cfg
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #40 am: 04 März 2017, 16:35:37 »
Hi,
jetzt wird's für mich noch ein bisschen unverständlicher. Wofür ist "Origin" denn dann gut?
...und wie genau funktioniert der Mechanismus bei FHEMWEB? Wird durch CORS = 1 tatsächlich jeder Ursprung erlaubt?
Ich habe versucht, das ganze durch das zu verstehen, was ich per google gefunden habe, aber anscheinend habe ich von dem ganzen Security-Gedöns so wenig Ahnung, dass ich da fast nichts verstehe. Z.B. klingt die Erklärung von "Access-Control-Allow-Credentials" für mich so, als ob man dadurch sogar noch mehr erlaubt. Das kann aber irgendwie auch wieder nicht sein.
Gruß,
   Thorsten
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline jeschkec

  • Jr. Member
  • **
  • Beiträge: 70
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #41 am: 04 März 2017, 17:23:12 »
Hi,
jetzt wird's für mich noch ein bisschen unverständlicher. Wofür ist "Origin" denn dann gut?

Um ein Loch in die SOP zu machen, wenn du "ressource sharing" betreiben möchtest. Per default macht dein Browser das nicht. Setzt du CORS auf 1, werden entsprechende Header geschickt:

$ curl -H "Origin: example.org" -D- "http://fhem.example:8083/fhem?cmd=set%20wz_lampe%20off&fwcsrf=csrf_155305163753975"
HTTP/1.1 302 Found
Content-Length: 0
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: GET POST OPTIONS
Access-Control-Allow-Headers: Origin, Authorization, Accept
Access-Control-Allow-Credentials: true
Access-Control-Max-Age:86400
Access-Control-Expose-Headers: X-FHEM-csrfToken
X-FHEM-csrfToken: csrf_155305163753975
Location: /fhem?fw_id=

Setzt du CORS auf 0 (oder gar nicht), werden folgende Header geschickt:

$ curl -H "Origin: example.org" -D- "http://fhem.example:8083/fhem?cmd=set%20wz_lampe%20off&fwcsrf=csrf_155305163753975"
HTTP/1.1 302 Found
Content-Length: 0
X-FHEM-csrfToken: csrf_155305163753975
Location: /fhem?fw_id=

Die CORS-Unterstützung aktiviert also die entsprechenden Header und damit darf dann auch jede Applikation zugreifen, die irgendwie einen Origin-Header geschickt bekommt. Origin-Header werden bei verschiedenen Aktionen gesendet, die typischerweise von einem Browser veranlasst werden, z.B. beim Einbinden von Fonts oder natürlich XHR.

Zitat
...und wie genau funktioniert der Mechanismus bei FHEMWEB? Wird durch CORS = 1 tatsächlich jeder Ursprung erlaubt?

Wenn CORS in FHEM aktiviert wird, wird jeder Request bedient, der einen Origin-Header sendet, da die Domain im Origin-Header lediglich zurückgesendet wird.

Wer also CORS nicht unbedingt haben muss (weil er kein ressource sharing macht), sollte tunlichst das Attribut CORS auf 0 bzw. gar nicht setzen!

Zitat
Ich habe versucht, das ganze durch das zu verstehen, was ich per google gefunden habe, aber anscheinend habe ich von dem ganzen Security-Gedöns so wenig Ahnung, dass ich da fast nichts verstehe. Z.B. klingt die Erklärung von "Access-Control-Allow-Credentials" für mich so, als ob man dadurch sogar noch mehr erlaubt. Das kann aber irgendwie auch wieder nicht sein.

Du hast es verstanden. Default ist über die SOP jedes ressource sharing verboten (whitelist approach). Über CORS kann man diese Whitelist um Ausnahmen erweitern.
2 FHEM auf Raspberry π, 3 FB (7490, 6490), 120 HomeMatic-Devices, 5 Echo Dot, MQTT

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 13023
  • Probleme sind auch keine Lösung.
Antw:Ich wünsche mir das die FHEM User etwas aufmerksamer werden
« Antwort #42 am: 04 März 2017, 18:40:57 »
Es geht darum, dass man auf einer Seite wie meinFhemBlog.de oder gar forum/wiki.fhem.de ein Boesewicht N "Bilder" reinstellt ala:

Nachdem wir das ja nun durch das Token unterbunden haben, besteht ja doch noch Hoffnung, dass man hier in Forumbeiträgen irgendwann wieder Bilder einbinden darf...  8)
Aus technischen Gründen befindet sich die Signatur auf der Rückseite dieses Beitrages.
Gefällt mir Gefällt mir x 3 Zustimmung Zustimmung x 1 Liste anzeigen