Ich wünsche mir das die FHEM User etwas aufmerksamer werden

Thorsten Pferdekaemper · 03 März 2017, 22:59:18

Zitat von: Puschel74 am 03 März 2017, 22:46:12Machst 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

Puschel74 · 03 März 2017, 23:05:45

Zitat von: Thorsten Pferdekaemper am 03 März 2017, 22:59:18
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.

Zitat von: Thorsten Pferdekaemper am 03 März 2017, 22:59:18
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.

Christoph Morrison · 04 März 2017, 01:13:15

Zitat von: Thorsten Pferdekaemper am 03 März 2017, 13:30:24
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.

Code Auswählen

<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:

Code Auswählen


<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.

Thorsten Pferdekaemper · 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
Code Auswählen Erweitern
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

JoWiemann · 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

Thorsten Pferdekaemper · 04 März 2017, 09:15:54

Zitat von: Thorsten Pferdekaemper am 04 März 2017, 08:16:28Wenn 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à:

Code Auswählen


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?

Zitat von: JoWiemann 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?!

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

rudolfkoenig · 04 März 2017, 09:33:34

ZitatBraucht man dafür nicht auch noch Access-Control-Allow-Origin?

Das kommt nur, wenn man Origin im Header gesendet hat:

Code Auswählen

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

Thorsten Pferdekaemper · 04 März 2017, 09:40:13

Zitat von: rudolfkoenig am 04 März 2017, 09:33:34
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

klaso · 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

Christoph Morrison · 04 März 2017, 16:22:20

Zitat von: Thorsten Pferdekaemper am 04 März 2017, 09:40:13
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:

Code Auswählen

<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:

Code Auswählen

Refused to set unsafe header "Origin"

Thorsten Pferdekaemper · 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

Christoph Morrison · 04 März 2017, 17:23:12

Zitat von: Thorsten Pferdekaemper 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?

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:

Code Auswählen

$ 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:

Code Auswählen

$ 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!

ZitatIch 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.

betateilchen · 04 März 2017, 18:40:57

Zitat von: rudolfkoenig am 03 März 2017, 10:40:42
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...