nicht angemeldet
Du hast noch drei weitere XSS-Sicherheitslücken, überall da wo du
<?=$_SERVER['PHP_SELF'];?>stehen hast.Oh. Das war in 2 von 3 Fallen sogar besser ganz wegzulassen (man muss
<form>kein action auf den Weg geben um das selbe Skript zu adressieren).
Und den dritten Fall hast du vergessen. Die XSS-Sicherheitslücke besteht dort weiterhin. Mit XSS-Attacken lassen sich auch Schutzmaßnahmen gegen CSRF-Attacken umgehen. Damit kann ein Angreifer also auch Aufgaben im Namen des Endnutzers ausführen.
Zudem hast du noch eine weitere Lücke eingebaut. In der Zeile trigger_error( 'Nicht erwarteter Referer: ' . $_SERVER['HTTP_REFERER'] . ' ' . $str, E_USER_ERROR ); wird der HTTP_REFERER nicht maskiert. Wenn der Server so konfigugiert ist, dass er PHP-Fehler ausgibt, ermöglich das einem Angreifer JavaScript einzuschleusen.
Die Zeile
header( 'Location: ' . $_SERVER['PHP_SELF'] );braucht auch Aufmerksamkeit. Ich weiß nicht, wie Browser mit fehlerhaften Location-Headern verfahren.13. Mai 2020 - Newflash: „Die Browser können seit sehr vielen Jahren mit relativen (nicht: „fehlerhaften") URLs in Location-Headern wunderbar umgehen. Anderes „Wissen“ ist veraltet.“
Du hast glaube ich nicht verstanden, worauf ich hinaus wollte. Es ging nicht um relative URLs, es ging darum, dass $_SERVER['PHP_SELF'] vor einer Ausgabe kontextgerecht behandelt werden muss, weil ein Angreifer sonst einen Syntax-Fehler in dem entsprechenden Header auslösen kann. Wozu der Syntax-Fehler führt, und ob das ein Sicherheitsrisiko birgt ist Sache der Browser-Implementierung. Aber das hast du ja nun angepasst, also geschenkt.
Benutze besser eine der etablierten, und intensiv erprobten Verteidigungs-Mechanismen.
Ah ja. Eine richtig schöne und große Scriptsammlung.
Von einer Skript-Sammlung war nie die Rede. Ich wollte dich dazu anleiten eine der erprobten Maßnahmen gegen CSRF-Angriffe zu implementieren und nicht dein eigenes Süppchen zu kochen. Viele vermeintliche Gegenmaßnahmen haben sich schon als unzureichend herausgestellt. Du hast dich auf den selben Pfad begeben und dabei offensichtlich einige Angriffsvektoren übersehen, weil du dem Irrglauben verfallen bist, dass POST-Anfragen gegen CSRF-Attacken immun seien. Die Lektüre, die ich dir verlinkt habe, erklärt warum das nicht der Fall ist. Aber auch das hast du im zweiten Anlauf nun korrigieren können, also geschenkt. Wichtig ist aber, dass du die XSS-Sicherheitslücken schließt, weil sich sonst dein CSRF-Schutz umgehen lässt.
Das wäre in meinem Fall so…
Bleiben wir doch beidem Fall: Fakt ist, dass du einen Passwort-Manager anbietest, bei dem wir jetzt rund ein Dutzend Sicherheitslücken aufgedeckt haben. Die Lücken ermöglichten im schlimmsten Fall einem Angreifer Passworte im Klartext auszulesen, Passwort-Hashes auszulesen, eigene Benutzer anzulegen, zu löschen, zu bearbeiten und den Passwort-Schutz zu deaktivieren oder zu aktivieren, um andere Benutzer auszuschließen.
Aber ich habe trotzdem Einiges getan. Ich habe strenge HTTP-Header gesetzt:
Und doch hilft das, was du da getan hast, nicht auf magische Weise XSS-Angriffe zu vermeiden. Du musst schon verstehen, was du da tust. Du setzt bswp. script-src 'self' 'unsafe-inline'. Das ist ein Türöffner für XSS-Angriffe. Hast du die Spezifikation gelesen? unsafe-inline sollte ausdrücklich nicht gesetzt werden. Zitat:
In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
Und wie anfangs erläutert hast du mindestens noch zwei genau solcher Sicherheitslücken.