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.
Es sollten keine Fehlermeldungen ausgegeben werden. Du kannst es nicht wissen, die Frage ist, wieso das Risiko überhaupt eingehen, wenn es sich so leicht beheben lässt.
14.5.2020 Newsflash: Das PHP Handbuch sagt zu $_SERVER['PHP']
'PHP_SELF' Der Dateiname des aktuell ausgeführten Skripts, relativ zum Document Root.
Die Dokumentation ist an der Stelle ungenau. Einer der Kommentare erwähnt, dass sich die Variable spoofen lässt. Alles was ein Angreifer tun muss, ist dem Endnutzer einen manipulierten Link unterzuschieben.
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.
Wie ich das sehe überprüfst du realpath( __FILE__ ) !== realpath( $_SERVER['SCRIPT_FILENAME'] ) ). Also SCRIPT_FILENAME und nicht PHP_SELF. Ich würde mich bei der Ausgabe von Variablen auch nicht auf einen Test verlassen, der ein paar Hundert Zeilen vorher stattfindet. Wenn der Test sich mal ändert, hast du den Salat. Was ist so schlimm daran Werte ordentlich vor der Ausgabe zu maskieren?
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.
Den Fall haben wir jetzt ja nun mehrfach gehabt. Was ist so schlimm daran der Empfehlung des W3C zu folgen eine striktere Policy zu implementieren? Dann hättest du wirklich einen effektiveren Schutz gegen XSS-Angriffe.