Autor Thema: Security bei oc-server3  (Gelesen 1868 mal)

Offline Rotzbua

  • Aktive User
  • *
  • Beiträge: 7
Security bei oc-server3
« am: 11. Juni 2016, 17:49:19 »
Hallo liebe Opencaching Community,
mit freude habe ich entdeckt, dass euer Code public ist. Ich habe mir mal erlaubt kurz über euer Projekt aus IT Security Sicht zu schaun.
Dabei sind mir einige Aspekte aufgefallen. Bestimmt haben einige Kommentare dazu, weswegen ich sie hier im Forum poste und nicht im Ticketsystem wo wahrscheinlich nicht so viele reinschauen. Gerne helfe ich auch bei der Umsetzung wenn ich Zeit dafür habe.

(1) Besseres Passwort Hashing
Umsetzung: komplex
Prio: hoch
Hintergrund:
Das Passwort Hashing wird nicht gut umgesetzt. Im schlimmsten Fall wird nur ungesalzenes md5(*PASSWORT*) verwendet, was gebrochen ist und Rainbowtables existieren.
Im immer noch schlimmen Fall wird hmac('sha512', md5(*PASSWORT*)+SALT)
(a) md5 wird als Grundlage verwendet, damit bringt sha512 keine zusätzliche Sicherheit sondern bleibt auf dem Sicherheitsniveau von md52
(b) hmac ist für Integritätsprüfung von Nachrichten gedacht und nicht für Hashing von Passwörtern
(c) der Salt ist für alle Hashes der selbe, wodurch das erstellen einer Rainbowtable immer noch reicht
Lösung:
PHP führt mit Version 5.5 eine Funktion ein die Passwort Hashing vereinfacht. (c) Dabei wird für jedes Passwort ein eigener Salt erstellt. (a)(b) Außerdem werden Hashingfunktionen verwendet die explizit für diesen Fall entwickelt wurden.
Vorschlag:
Da alle Hashes nicht ersetzt werden können, würde ich vorschlagen es wie im PL Entwicklungszweig von Opencaching zu machen und bei jedem Login überprüfen ob noch ein alter Hash vorhanden ist und falls ja ihn durch einen neuen Höherwertigen ersetzen.

(2) Bei login über https Cookies httpsonly
Umsetzung: mittel
Prio: mittel
Hintergrund:
Wird über https eingeloggt so wird ein Cookie gesetzt, welches über jede Verbindung also auch über unsicheres http gesendet wird, gesetzt.
Lösung:
Cookie httpsonly setzen.
Vorschlag:
Cookie mit sensiblen Daten httpsonly setzen. Ein weiteres Cookie setzen welches signalisiert, dass über https eingeloggt wurde und automatisch dann auf https zurückgeleitet wird falls die Seite über http aufgerufen wird.

(3) HTTP Strict Transport Security (HSTS) Header setzen
Umsetzung: einfach
Prio: mittel
Hintergrund:
HTTPS wurde mittlerweile umgesetzt, wenn auch nur optional. Geht man explizit auf https (weil man sich z.B. in einem Hotspot befindet), so kommt es vor, dass man aus versehen wieder auf unverschlüsseltes http kommt.
Lösung:
HSTS ist ein Header der den Browser anweist für einen Zeitraum die Seite nur noch über https abzurufen.
Vorschlag:
HSTS nur auf die Hauptseite und nur für 10 Minuten setzen, falls Fehler auftreten kann man spätestens nach 10 Minuten wieder http benutzen.

(4)  HTTP Public Key Pinning (HPKP) Header setzen
Umsetzung: mittel
Prio: niedrig
Hintergrund:
Theoretisch kann jede Zertifizierungsstelle ein gültiges Zertifikat für die eigene Webseite ausstellen. Mit HPKP kann man exakt festlegen welche Zertifikat für die eigene Webseite vom Browser akzeptiert werden sollen.
Die Funktion ist ähnlich zu HSTS. HPKP schützt praktisch vor sehr fähigen Angreifern, kann gültige Zertifikat für Domains austellen, hat Zugriff auf die Kommunikation des Opfers. Für die Praxis eher irrelevant deswegen Prio niedrig.
Vorschlag:
Lässt sich auch im Reporting Modus betreiben, d.h. es ist nicht wirksam aber alle potentiellen Probleme werden automatisch gemeldet. Damit lässt es sich dann schnell aktiv schalten falls nötig, da man schon die benötigten Daten hat. Als Reportauswertungsseite (kostenlos) würde ich https://report-uri.io/ empfehlen.

(5) Security Header setzen
Umsetzung: einfach
Prio: mittel
Hintergrund:
Einige Browser unterstützen XSS Schutzmodi oder ähnliches. Diese werden aktuell nicht genutzt. Siehe: https://securityheaders.io/?q=http%3A%2F%2Fwww.opencaching.de%2F
Lösung:
Die 3 häufigst verwendeten Header setzen:
# X-Xss-Protection
# This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit).
Header always set X-XSS-Protection "1; mode=block"
# X-Frame-Options
# The X-Frame-Options header (RFC), or XFO header, protects your visitors against clickjacking attacks
Header always set X-Frame-Options SAMEORIGIN
# X-Content-Type-Options
# It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server.
Header always set X-Content-Type-Options: "nosniff"

(6) Content Security Policy (CSP) setzen
Umsetzung: mittel
Prio: niedrig
Hintergrund:
CSP kann eingesetzt werden um nur die von der Webseite verwendeten Resourcen (Bilder, Scripte, usw.) zu definieren. Mit CSP werden XSS oder sonstige Angriffe wesentlich erschwert. CSP ist noch nicht in einem RFC finalisiert.
Vorschlag:
Es lässt sich bequem im Reporting Modus betreiben, d.h. es ist nicht wirksam aber alle potentiellen Probleme werden automatisch gemeldet. Damit lässt es sich dann schnell aktiv schalten falls nötig, da man schon die benötigten Daten hat. Als Reportauswertungsseite (kostenlos) würde ich https://report-uri.io/ empfehlen.

(7) sessionid/uuid nicht mittels mt_rand() generieren
Umsetzung: mittel
Prio: niedrig
Hintergrund:
Die Funktion mt_rand ist nicht für kryptographische Verwendung geeignet. Die sessionid/uuid ist aber sowas wie ein "Passwort" und sollte daher mit geeigneten Funktionen erzeugt werden. Im Jahr 2013 wurde gezeigt, dass von den generierten Zufallszahlen auf den Seed von mt_srand geschlossen werden kann. Dadurch sind Seitenkanalangriffe auf Sessions möglich dich zeitgleich oder zeitlich nahe erfolgen.
Lösung:
Kryptographisch sichere Zufallsfunktion verwenden.

(8) Überprüfung des Redirect beim Login
Umsetzung: mittel
Prio: niedrig
Hintergrund:
?target=**URL** wird nicht überprüft und kann überall hinleiten.
Lösung:
Nur auf eigene Seiten, bzw. nur für gewollte Webseiten (Whitelist) zulassen.

Fragen:
(A) Werden Header mittel PHP Funktion header() oder über .htaccess gesetzt?
(B) Was ist aktuell die Untergrenze von PHP Version für die programmiert wird?

Ich freue mich auf eure Rückmeldungen.
Beste Grüße
Rotzbua
« Letzte Änderung: 04. August 2016, 18:26:42 von Rotzbua »

Offline dl6hbo

  • Normal
  • *****
  • Beiträge: 1682
  • - verstorben -
Re: Security bei oc-server3
« Antwort #1 am: 12. Juni 2016, 09:18:34 »
Hallo liebe Opencaching Community,
mit freude habe ich entdeckt, dass euer Code public ist. Ich habe mir mal erlaubt kurz über euer Projekt aus IT Security Sicht zu schaun.
Dabei sind mir einige Aspekte aufgefallen. Bestimmt haben einige Kommentare dazu, weswegen ich sie hier im Forum poste und nicht im Ticketsystem wo wahrscheinlich nicht so viele reinschauen. Gerne helfe ich auch bei der Umsetzung wenn ich Zeit dafür habe.

Moin Rotzbua, auf den ersten Blick sind Deine beiden Beiträge hier im Forum ziemliche "Brocken", die man erst einmal verdauen muss. Ich werde mal versuchen, aus Sicht eines Systemverwalters
darauf einzugehen.

Hilfe können wir immer brauchen.  Auch den unvoreingenommenen Blick von draussen, sehe ich als Hilfe an. Da Opencaching.de ein Freiwilligen-Freizeit Projekt ist, haben wir nicht automatisch sämtliche Experten beisammen, die so ein Projekt benötigen würde.

(1) Besseres Passwort Hashing
Umsetzung: komplex
Prio: hoch
Hintergrund:
Das Passwort Hashing wird nicht gut umgesetzt. Im schlimmsten Fall wird nur ungesalzenes md5(*PASSWORT*) verwendet, was gebrochen ist und Rainbowtables existieren.
Im immer noch schlimmen Fall wird hmac('sha512', md5(*PASSWORT*)+SALT)
(a) md5 wird als Grundlage verwendet, damit bringt sha512 keine zusätzliche Sicherheit sondern bleibt auf dem Sicherheitsniveau von md52
(b) hmac ist für Integritätsprüfung von Nachrichten gedacht und nicht für Hashing von Passwörtern
(c) der Salt ist für alle Hashes der selbe, wodurch das erstellen einer Rainbowtable immer noch reicht
Lösung:
PHP führt mit Version 5.5 eine Funktion ein die Passwort Hashing vereinfacht. (c) Dabei wird für jedes Passwort ein eigener Salt erstellt. (a)(b) Außerdem werden Hashingfunktionen verwendet die explizit für diesen Fall entwickelt wurden.
Vorschlag:
Da alle Hashes nicht ersetzt werden können, würde ich vorschlagen es wie im PL Entwicklungszweig von Opencaching zu machen und bei jedem Login überprüfen ob noch ein alter Hash vorhanden ist und falls ja ihn durch einen neuen Höherwertigen ersetzen.

Das ist in der Tat eine gute Idee und sicherlich relativ schnell umsetzbar, da OC.pl es ja schon so macht.

(2) Bei login über https Cookies httpsonly
Umsetzung: mittel
Prio: mittel
Hintergrund:
Wird über https eingeloggt so wird ein Cookie gesetzt, welches über jede Verbindung also auch über unsicheres http gesendet wird, gesetzt.
Lösung:
Cookie httpsonly setzen.
Vorschlag:
Cookie mit sensiblen Daten httpsonly setzen. Ein weiteres Cookie setzen welches signalisiert, dass über https eingeloggt wurde und automatisch dann auf https zurückgeleitet wird falls die Seite über http aufgerufen wird.

Das verstehe ich so, dass es zukünftig zweierlei Session-Cookies geben sollte, einen für http-Sessions und einen für https-Sessions. Ist das so richtig ?

(3) HTTP Strict Transport Security (HSTS) Header setzen
Umsetzung: einfach
Prio: mittel
Hintergrund:
HTTPS wurde mittlerweile umgesetzt, wenn auch nur optional. Geht man explizit auf https (weil man sich z.B. in einem Hotspot befindet), so kommt es vor, dass man aus versehen wieder auf unverschlüsseltes http kommt.
Lösung:
HSTS ist ein Header der den Browser anweist für einen Zeitraum die Seite nur noch über https abzurufen.
Vorschlag:
HSTS nur auf die Hauptseite und nur für 10 Minuten setzen, falls Fehler auftreten kann man spätestens nach 10 Minuten wieder http benutzen.

HTTPS ist bei OC.de relativ neu. Daher sind noch nicht alle verlinkten Seiten daran angepasst. (Freiwilligen-Freizeit Projekt)

(4)  HTTP Public Key Pinning (HPKP) Header setzen
Umsetzung: mittel
Prio: niedrig
Hintergrund:
Theoretisch kann jede Zertifizierungsstelle ein gültiges Zertifikat für die eigene Webseite ausstellen. Mit HPKP kann man exakt festlegen welche Zertifikat für die eigene Webseite vom Browser akzeptiert werden sollen.
Die Funktion ist ähnlich zu HSTS. HPKP schützt praktisch vor sehr fähigen Angreifern, kann gültige Zertifikat für Domains austellen, hat Zugriff auf die Kommunikation des Opfers. Für die Praxis eher irrelevant deswegen Prio niedrig.
Vorschlag:
Lässt sich auch im Reporting Modus betreiben, d.h. es ist nicht wirksam aber alle potentiellen Probleme werden automatisch gemeldet. Damit lässt es sich dann schnell aktiv schalten falls nötig, da man schon die benötigten Daten hat. Als Reportauswertungsseite (kostenlos) würde ich https://report-uri.io/ empfehlen.

Das bedeutet also etwas mehr Feintuning bei Zertifikaten ?

(5) Security Header setzen
Umsetzung: einfach
Prio: mittel
Hintergrund:
Einige Browser unterstützen XSS Schutzmodi oder ähnliches. Diese werden aktuell nicht genutzt. Siehe: https://securityheaders.io/?q=http%3A%2F%2Fwww.opencaching.de%2F
Lösung:
Die 3 häufigst verwendeten Header setzen:
# X-Xss-Protection
# This header is used to configure the built in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit).
Header always set X-XSS-Protection "1; mode=block"
# X-Frame-Options
# The X-Frame-Options header (RFC), or XFO header, protects your visitors against clickjacking attacks
Header always set X-Frame-Options SAMEORIGIN
# X-Content-Type-Options
# It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server.
Header always set X-Content-Type-Options: "nosniff"

Ein Job für unsere Entwickler...

(6) Content Security Policy (CSP) setzen
Umsetzung: mittel
Prio: niedrig
Hintergrund:
CSP kann eingesetzt werden um nur die von der Webseite verwendeten Resourcen (Bilder, Scripte, usw.) zu definieren. Mit CSP werden XSS oder sonstige Angriffe wesentlich erschwert. CSP ist noch nicht in einem RFC finalisiert.
Vorschlag:
Es lässt sich bequem im Reporting Modus betreiben, d.h. es ist nicht wirksam aber alle potentiellen Probleme werden automatisch gemeldet. Damit lässt es sich dann schnell aktiv schalten falls nötig, da man schon die benötigten Daten hat. Als Reportauswertungsseite (kostenlos) würde ich https://report-uri.io/ empfehlen.

Nette Datenquelle ...

(7) sessionid/uuid nicht mittels mt_rand() generieren
Umsetzung: mittel
Prio: niedrig
Hintergrund:
Die Funktion mt_rand ist nicht für kryptographische Verwendung geeignet. Die sessionid/uuid ist aber sowas wie ein "Passwort" und sollte daher mit geeigneten Funktionen erzeugt werden. Im Jahr 2013 wurde gezeigt, dass von den generierten Zufallszahlen auf den Seed von mt_srand geschlossen werden kann. Dadurch sind Seitenkanalangriffe auf Sessions möglich dich zeitgleich oder zeitlich nahe erfolgen.
Lösung:
Kryptographisch sichere Zufallsfunktion verwenden.

Stimmt. Das sollte jetzt sehr bald umgesetzt werden können.

( 8) Überprüfung des Redirect beim Login
Umsetzung: mittel
Prio: niedrig
Hintergrund:
?target=**URL** wird nicht überprüft und kann überall hinleiten.
Lösung:
Nur auf eigene Seiten, bzw. nur für gewollte Webseiten (Whitelist) zulassen.

Auch das sollte sehr bald zu schaffen sein.

Fragen:
(A) Werden Header mittel PHP Funktion header() oder über .htaccess gesetzt?
(B) Was ist aktuell die Untergrenze von PHP Version für die programmiert wird?

Ich freue mich auf eure Rückmeldungen.
Beste Grüße
Rotzbua

Die Fragen zu (A) und (B) kann ich nicht beantworten, da ich kein Entwickler bin.
« Letzte Änderung: 12. Juni 2016, 09:21:20 von dl6hbo »
Gruß, Rainer ( dl6hbo )
Everything should be made as simple as possible, but not simpler.
Albert Einstein

Offline teiling88

  • Moderator
  • Small
  • *****
  • Beiträge: 668
  • Vorstand & Entwicklung
Re: Security bei oc-server3
« Antwort #2 am: 12. Juni 2016, 13:52:06 »
Hallo liebe Opencaching Community,
mit freude habe ich entdeckt, dass euer Code public ist. Ich habe mir mal erlaubt kurz über euer Projekt aus IT Security Sicht zu schaun.
Dabei sind mir einige Aspekte aufgefallen. Bestimmt haben einige Kommentare dazu, weswegen ich sie hier im Forum poste und nicht im Ticketsystem wo wahrscheinlich nicht so viele reinschauen. Gerne helfe ich auch bei der Umsetzung wenn ich Zeit dafür habe.

Hallo Rotzbua,

vielen Dank für deine Hinweise - wie Du sicherlich mitbekommen hast sind wir gerade Dabei den kompletten Quellcode Stück für Stück auf "links" zu drehen. Wir haben den Quellcode auf einen guten PSR-2 Standard gebracht, Composer und Vagrant für unsere Entwickler VM eingeführt.

Wir sind dabei Symfony mit Doctrine einzuführen usw. Die Punkte 1, 7 und 8 haben wir auch schon auf unserer Roadmap. Die restlichen werden wir evaluieren und prüfen. Wenn Du magst kannst Du auch gerne mit einsteigen wenn es deine Zeit zulässt. :-)

Offline Rotzbua

  • Aktive User
  • *
  • Beiträge: 7
Re: Security bei oc-server3
« Antwort #3 am: 12. Juni 2016, 18:34:19 »
Danke für eure Rückmeldung.
Seht bitte die Auflistung mehr als Audit/Bericht/Anregung an und nicht als direkte Arbeitsliste  ;).

(2) Bei login über https Cookies httpsonly
Umsetzung: mittel
Prio: mittel
Hintergrund:
Wird über https eingeloggt so wird ein Cookie gesetzt, welches über jede Verbindung also auch über unsicheres http gesendet wird, gesetzt.
Lösung:
Cookie httpsonly setzen.
Vorschlag:
Cookie mit sensiblen Daten httpsonly setzen. Ein weiteres Cookie setzen welches signalisiert, dass über https eingeloggt wurde und automatisch dann auf https zurückgeleitet wird falls die Seite über http aufgerufen wird.

Das verstehe ich so, dass es zukünftig zweierlei Session-Cookies geben sollte, einen für http-Sessions und einen für https-Sessions. Ist das so richtig ?
Ja. Ziel ist es, dass jemand der sich schon bewusst über https einloggt auch wirklich geschützt vor Man-in-the-middle (MiM) Angriffen geschützt ist. Beispiel: Hotspot/Freifunk wird benutzt. Ich versuch den Ablauf mal darzustellen:

Login über http:
Session-Cookie ganz normal wie jetzt setzten.
-> http und https funktionieren so wie jetzt

Login über https:
Session-Cookie httpsonly setzen, dann wird dieser Cookie nur über https übertragen (ist eine Cookie Eigenschaft), zweiten "normalen" UmleitenNachHTTPS-Cookie setzen.
-> Aufruf über http: Session-Cookie wird nicht übertragen (MiM kann nicht Session klauen), UmleitenNachHTTPS-Cookie wird übertragen -> Seite erkennt das und leitet auf https um
-> Aufruf über https: alles wie bisher

Im Prinzip macht (3) HSTS ähnlich. Nur dort wird aber https dann "hart" vom Browser für die Domain gefordert.

(4)  HTTP Public Key Pinning (HPKP) Header setzen
Umsetzung: mittel
Prio: niedrig
Hintergrund:
Theoretisch kann jede Zertifizierungsstelle ein gültiges Zertifikat für die eigene Webseite ausstellen. Mit HPKP kann man exakt festlegen welche Zertifikat für die eigene Webseite vom Browser akzeptiert werden sollen.
Die Funktion ist ähnlich zu HSTS. HPKP schützt praktisch vor sehr fähigen Angreifern, kann gültige Zertifikat für Domains austellen, hat Zugriff auf die Kommunikation des Opfers. Für die Praxis eher irrelevant deswegen Prio niedrig.
Vorschlag:
Lässt sich auch im Reporting Modus betreiben, d.h. es ist nicht wirksam aber alle potentiellen Probleme werden automatisch gemeldet. Damit lässt es sich dann schnell aktiv schalten falls nötig, da man schon die benötigten Daten hat. Als Reportauswertungsseite (kostenlos) würde ich https://report-uri.io/ empfehlen.
Das bedeutet also etwas mehr Feintuning bei Zertifikaten ?
Ja, man muss vorausschauender Planen wenn man Zertifikate auswechselt/ersetzt. Schützt im Grunde vor MiM Angriffen, bzw. der Aufdeckung von solchen Angriffen. Im Prinzip verfolgt es das selbe Ziel wie DNSSEC/TLSA.


vielen Dank für deine Hinweise - wie Du sicherlich mitbekommen hast sind wir gerade Dabei den kompletten Quellcode Stück für Stück auf "links" zu drehen. Wir haben den Quellcode auf einen guten PSR-2 Standard gebracht, Composer und Vagrant für unsere Entwickler VM eingeführt.

Wir sind dabei Symfony mit Doctrine einzuführen usw. Die Punkte 1, 7 und 8 haben wir auch schon auf unserer Roadmap. Die restlichen werden wir evaluieren und prüfen. Wenn Du magst kannst Du auch gerne mit einsteigen wenn es deine Zeit zulässt. :-)
Freut mich, dass die Punkte schon auf der Roadmap sind :). Die meisten Punkte beschäftigen sich mehr mit Sicherungstechniken im Browser und zwischen Server/Browser, also weniger programmiererisches. Zeitlich wird es bei mir leider erst September/Oktober wo ich mehr Zeit investieren kann.

Bei der Umsetzung der oberen Punkte würde ich mich gerne beteiligen, an der generellen Programmierung von OC habe ich ehrlich gesagt keine Interesse.
Ich habe mir jetzt ein ACC bei eurem Ticketsystem gemacht (selber Name). Ich würde vorschlagen, wenn ihr wisst, dass ihr einen Punkt umsetzen wollt, dann erstellt dort ein Ticket und fügt mich hinzu. Ich denke so ist die Umsetzung am einfachsten :D .


Offline Rotzbua

  • Aktive User
  • *
  • Beiträge: 7
Re: Security bei oc-server3
« Antwort #4 am: 15. August 2016, 14:25:24 »
Ich habe noch was wichtiges gefunden. Problem ist, dass es Auswirkungen auf okapi und .pl Zweig hat.

(9) Exploitmöglichkeit durch serialize Verwendung für Userinput
http://redmine.opencaching.de/issues/999

Ansonsten noch:

(10) Cookie wird für komplette Domain gesetzt
http://redmine.opencaching.de/issues/1006

(11) Wunderschönes Griefing möglich, der "unloggbare Cache" zumindest über das Webinterface
http://redmine.opencaching.de/issues/1008

(12) Bisschen Maleware hosten
http://redmine.opencaching.de/issues/1009

-----

Den Punkt (2) Bei login über https Cookies httpsonly hab ich programmiert und getestet.

Für Engagement ist mir aktuell das Feedback zu gering. Falls ihr später euch mal an die Punkte macht, könnt ihr euch gerne an mich wenden.

Noch einen sonnigen Sommer
Rotzbua

Offline teiling88

  • Moderator
  • Small
  • *****
  • Beiträge: 668
  • Vorstand & Entwicklung
Re: Security bei oc-server3
« Antwort #5 am: 15. August 2016, 23:25:11 »
Den Punkt (2) Bei login über https Cookies httpsonly hab ich programmiert und getestet.
Ich befinde mich aktuell im Urlaub - habe aber gerade schon einmal kurz drüber geflogen. Du implementierst das ganze noch im alten lib2 Zweig - magst Du das nicht nach src/oc "verschieben". Dort kommt der neue Refaktorierte Code rein den wir nachher auch in Symfony integrieren wollen.

Für Engagement ist mir aktuell das Feedback zu gering. Falls ihr später euch mal an die Punkte macht, könnt ihr euch gerne an mich wenden.

Was für ein Feedback erwartest Du den von uns? Ich bin aktuell im Urlaub und mit Mirco (ClanFamily) aktuell die beiden Entwickler die sich um PRs kümmern. Mirco ist der Frontend und ich der Backend Part.

Da ich aktuell durch Urlaub und Thesis nicht all zu viel Zeit habe kann das aktuell leider etwas dauern :-\