nicht angemeldet
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.
Auf Produktivsystemen werden keine Fehlermeldungen ausgegeben.
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.“
Es geht nicht um relative URLs, es geht 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.
14.5.2020 Newsflash: Das PHP Handbuch sagt zu $_SERVER['PHP']
'PHP_SELF'
Der Dateiname des aktuell ausgeführten Skripts, relativ zum Document Root.
Wie soll er das tun?
Ich habe das ausgeschlossen, in dem ich die Skriptausführung abbreche, sobald FILE (wirklich aktelle Datei bei Inkludes) und $_SERVER['PHP_SELF'] (ggf. includierende Datei) nicht übereinstimmen.
Selbst wenn ein Angreifer also irgendwie eine andere Datei so manipulieren kann, dass diese mein Script includiert, dann scheitert er an diesem Punkt. Das ist eigentlich schon akademisch - aber bitte - ich habe das verhindert.
Jetzt erkläre mir doch bitte, wie ein Angreifer den Dateiname oder den Pfad so manipulieren können soll. Und warum er das tun sollte, wenn er das kann. Denn genau dann könnte er auf dem Server sehr viel mehr sehr viel einfacher.
Du setzt bswp. script-src 'self' 'unsafe-inline'. Das ist quasi der Türöffner für XSS-Angriffe
Aber nur in Projekten, bei denen „usergeneratet content“ oder anderer fremder Content vorkommen kann und ggf. nicht korrekt behandelt wird. Das ist hier nicht der Fall, die Benutzernamen werden ohne Kommentar* verworfen wenn was anderes als [A-Za-z0-9._-] drin ist (*:Die werden ja schon zuvor vom Browser geprüft). Die Passwörter nirgends wiedergegeben.
Das Skript erfüllt die Voraussetzungen für eine solche XSS-AtTacke also nicht. Gewiss nicht bei $_SERVER['PHP_SELF'].
Immerhin müsste man einem Pfadname wie
/foo/<script>alert("Böse");</script>/bar
anlegen. Das macht eher kein Besitzer einer Webseite. Und wie schon gesagt: Ein Angreifer, der das kann, kontrolliert den Server bereits. Damit ist das keine Sicherheitslücke mehr, sondern so oder so eine rein akademische und ziemlich krude erscheinende Vorstellung. Warum, BITTE, sollte er DAS tun?
Die Idee, hier tonnenweise irgendwelche Skripte, womöglich noch fremden Servern, zu inkludieren um die Sicherheit zu „erhöhen“, ist in dem Fall völlig daneben. Genauer: Nicht mehr hyperliquid sondern kontraproduktiv. Noch genauer: Nur im besten Fall unschädlich.