Deaktivierung von CORS **nicht** empfehlen

[liske]

Vielen Dank für das Projekt :+1:

Meines Erachtens ist es keine gute Idee zu Empfehlen die CORS-Einstellung von Nightscout zu deaktivieren - damit wird es Anfällig für Angriffe. Mit NS alleine lässt sich das nicht wirklich lösen, da idR. aber noch ein Webserver vor der NS-Instanz läuft kann man diesen dafür nutzen. Für Apache HTTPD z.B. so: https://github.com/liske/cgm-remote-monitor-docker/blame/master/README.md#L39-L43

Im Beispiel wird der Access-Control-Allow-Origin-Header immer auf die eigentliche Basis-URL der NS-Instanz gesetzt - außer die Anfrage kommt vom nightscout reporter - dann wird der Header entsprechend geändert.

[quizzmaster]

Das ist etwas, was man Martin für 10be vorschlagen könnte. Für alle Heroku Instanzen ist das vermutlich nicht praktikabel, da dort kein Reverse Proxy davor sitzt, an den man heran kommt

[zreptil]

Sorry, ich stehe gerade etwas auf dem Schlauch. Worum geht es hier genau? Was soll bei Nightscout Reporter geändert werden? Die Entscheidung CORS zu verlangen ist eine Sache des Servers, auf den per Script zugegriffen wird. Ich wüsste wirklich nicht, was bei Nightscout Reporter geändert werden könnte, um das zu umgehen. Was soll dieser Issue hier also bewirken? Vielleicht könntest Du ein bisschen genauer schreiben, was Du genau von mir möchtest, damit ich sehen kann, was ich für Dich tun kann.

[quizzmaster]

@zreptil Es geht nicht darum, das du konkret etwas tun kannst. Besagte "Lösung" muss auf der Seite des Servers geschehen, auf dem die Nightscout-Instanz läuft. Ich habe das nur als Hinweis verstanden.

[zreptil]

@quizzmaster Das hatte ich durchaus auch so verstanden. Nur bringt dieser Hinweis faktisch hier absolut nichts. Ich kann daran nichts ändern und ich denke auch keiner der Benutzer von Herokuapp kann daran irgendetwas ändern. Deswegen denke ich einfach, dass das hier die falsche Stelle ist. Die Empfehlung für die CORS Option wird auf alle Fälle drin bleiben, weil die Technik des Webservers auf dem Nightscout läuft das einfach verlangt. Ansonsten würde ich dazu raten, sich mit Herokuapp oder Martin direkt in Verbindung zu setzen und zu schauen, was deren Sicherheitsbeauftragte dazu sagen, bestimmten Webseiten, die sich nicht unter ihrer Kontrolle befinden, zusätzliche Rechte zu geben.

Wie gesagt, diesen Issue sehe ich nicht als den meinen an :)

[zehnBE]

Ich hatte es mal gesetzt gehabt, aber dann gab es bei vielen Probleme. Das CORS-Plugin kann beim editieren vom Server aktiviert/deaktiviert werden. Aktuell wird bei den Instanzen aber ein: INSECURE_USE_HTTP=true SECURE_HSTS_HEADER=false gesetzt, da es sonst über den Nginx-Proxy Probleme gab. In den nächsten Wochen, kann ich vielleicht noch mal schauen....

[liske]

Sorry für die Aufregung - das Wort 'Security' im Issue-Titel war unglücklich gewählt (mir ging es um das Thema, nicht das es ein Security Bug in nightscout-reporter sei).

@zreptil Mir geht es, wie @quizzmaster schon geschrieben hat, um den Hinweis https://github.com/zreptil/nightscout-reporter/blob/master/lib/src/globals.dart#L511-L514 - technisch kann man das konfigurieren damit das funktioniert - sicherheitstechnisch aber eher eine Katastrophe.

@zehnBE Mit nginx oder apache httpd als Reverse Proxy sollten sich alle Szenarien abbilden lassen. Wenn das CORS-Plugin nicht aktiviert ist nimmt der Browser AFAIK automatisch an, das fremde Domain nicht erlaubt sind. Das CORS-Plugin im NS macht IMHO wenig Sinn außer man betreibt NS direkt ohne Reverse Proxy. Mit Reverse Proxy lässt sich das deutlich flexibler abbilden. Im nginx müsste das ungefähr so gehen (ungetestet):

    proxy_hide_header "Access-Control-Allow-Origin";
    if ($http_origin ~ "(ns\.example\.com|nightscout-reporter\.zreptil\.de)$") {
        add_header "Access-Control-Allow-Origin" $http_origin;
    }

[zreptil]

Geschlossen wegen Irrelevanz für Nightscout Reporter.