mysql: Login
bearbeitet von 1unitedpower> > 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 ignoriert. Die XSS-Sicherheitslücke besteht weiterhin. XSS-Sicherheitslücken sind kein Spaß, damit lässt sich auch jeder Schutz gegen CSRF-Attacken umgehen. 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.“*
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. Wozu der Syntax-Fehler führt, und ob das ein Sicherheitsrisiko birgt ist Sache der Browser-Implementierung. Aber das hast du ja scheinbar angepasst, also geschenkt.
> > Benutze besser eine der etablierten, und intensiv erprobten Verteidigungs-Mechanismen.
>
> Ah ja. Eine richtig schöne und große Scriptsammlung.
Und es geht hier auch nicht Umfang, sondern um eine Mindestmaß an Qualität und theoretischem Grundlagenwissen. Über die Zeit haben viele Entwickler*innen Lösungen gegen CSRF-Attacken vorgeschlagen, die sich später als unzulänglich erwiesen haben. Du hast dich auf den selben Pfad begeben, obwohl es bereits studierte Gegenmaßen gibt. Dabei hast du 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 scheinbar korrigieren können, also geschenkt.
> Das wäre in meinem Fall so…
Bleiben wir doch beidem Fall: Da ist es so, 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 aktivieren, um andere Benutzer auszuschließen. Das sind alles enorme Risiken, und anstatt darüber transparent aufzuklären, versucht du die Risiken zu relativieren und herunterzuspielen.
> Aber [ich habe trotzdem Einiges getan](https://code.fastix.org/Projekte/Apache%2CPHP%3Ahtpasswd/?v=4.2). 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 quasi der Türöffner für XSS-Angriffe. Hast du die [Spezifikation](https://www.w3.org/TR/CSP3/#csp-directives) überhaupt 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 mindestens zwei dieser potentiellen Lücken finden sich auch in deiner aktuellen Version wieder.