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%2 ... hing.de%2F
Lösung:
Die 3 häufigst verwendeten Header setzen:
Code: Alles auswählen
# 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"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
Überprüfung des Redirect beim Login
.
. 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. 
.