Deine Anwendung ist anfällig für CSRF-Angriffe. Damit kann ein Angreifer quasi beliebige Aktionen im Namen des Benutzers ausführen.
Das waren zwar nicht ganz so „beliebige Aktionen“, sondern „lediglich“ das Löschen von anderen Benutzern, aber das reicht ja völlig aus, um Schaden zu verursachen.
[v] erledigt: Der zu löschende Benutzername wird jetzt nicht mehr per GET übertragen, sondern in ein Cookie mit sehr begrenzter Gültigkeit und Lebensdauer geschrieben. Die Möglichkeit, Cookies zu schreiben wird geprüft.
htmlspecialchars ist ein Anfang, aber dein Zielkontext ist JavaScript.
Eigentlich war das gefahrfrei, da die Benuternamen nur aus /[A-Za-z0-9_.-]/
bestehen durften. Aber für den denkbaren Fall, dass die Datei mit Benutzername und Passwort-Hash von Hand oder durch eine konkurrierende Anwendung bearbeitet werden - und weil ich mal sehen wollte zu welchem Ergebnis das führt - habe ich das jetzt an der JS-Stelle so gemacht:
trim( json_encode( $strUser, JSON_HEX_AMP|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_TAG ), '"' )
Für das Cookie lasse ich dann durch JS noch Strichpunkte (Semikolons) im Username durch \u003B
ersetzen.
Im HTML-Teil:
htmlspecialchars( $strUser, ENT_QUOTES )
Mit dem eigentlich unmöglichen Benutzername
f'<script>alert("hurra");</script>'oo
in der Passwortdatei ergibt das:
<li class="t2" title="Diesen Benutzer löschen ..." onclick="Ask('f\u0027\u003Cscript\u003Ealert(\u0022hurra\u0022);\u003C\/script\u003E\u0027oo' )">f'<script>alert("hurra");</script>'oo</li>
Weitere Veränderungen:
-
die "Kosten" für den BCRYPT-Algorithmus sind jetzt konfigurierbar - Falls der Apache und PHP irgendwann einmal verschiedene Vorstellungen darüber entwickeln, welche Einstellung von PHP als default benutzt und welche vom Apache akzeptiert wird.
-
Für die Kompatibilät mit denkbaren anderen Anwendungen muss der Benutzername jetzt mit einem Buchstabe beginnen.
-
Die Mindestlänge des Benutzernamens ist konfigurierbar.
Version 4.1 - für die Quelltextansicht entweder diesen Link nehmen oder bitte reload drücken.