XXS-Lücke auf Au-Ja.de behoben

Am vergangenen Freitag meldete sich der Sicherheitsforscher Chirag Prajapati von Cybertix bei Au-Ja.de mit dem Hinweis, auf unserer Webseite eine XXS-Lücke (Cross Site Scripting) gefunden zu haben. Wir konnten das Problem verifizieren und haben es noch am selben Tag behoben. Betroffen war nur das Portal, das Forum war nicht betroffen.

Die Schwachstelle im Detail
Chirag Prajapati hatte die für seinen Angriff verwendete URL derart gestaltet, dass diese JavaScript-Code enthielt. Dieser befand sich allerdings nicht im Query-String, also dem Teil der URL, welcher die zu übergebenden Wert umfasst, sondern im Dateipfad:

https://beispiel.usw/zielseite.html/x"><svG%20onLoad=prompt(document.domain)>?Wert1=1&Wert2=2

Das ist eher ungewöhnlich, da Webseiten in der Regel zwar die übergebenen Werte verarbeiten (und dabei Fehler machen), aber nur selten ihre eigene Adresse auswerten. Dies obliegt dem Webserver und dieser hätte auf obige Anfrage klassischerweise mit der Meldung Not Found reagiert, da er zielseite.html als Verzeichnisnahmen und /x als weiteres Unterverzeichnis interpretiert hätte. Das Ergebnis: Ein ungültiger Pfad, eine Not Found-Meldung, aber keine XXS-Lücke.

Auftritt AcceptPathInfo-Direktive: Seit Apache 2.0.30 ist das standardmäßige Verhalten des Web-Servers ein anderes. Nun wird zielseite.html tatsächlich als Datei erkannt und /x samt der darauf folgenden Zeichen als zusätzliche Pfadangaben interpretiert. Dies hat zur Folge, dass der Web-Server keine Fehlerseite absetzt, sondern zielseite.html im Pfadkontext /x öffnet. Und jetzt enthält die URL der Seite auf einmal scharfen JavaScript-Code.

Tatsächlich arbeitet unser Forum mit zusätzlichen Pfadangaben, doch Prajapatis Angriff scheitert dort aufgrund gezielter Sicherheitsmaßnahmen. Da unserer Portal ohne zusätzliche Pfadangaben auskommt, haben wir AcceptPathInfo dort deaktiviert, so dass der Angriff ebenfalls ins Leere lief. Zumindest auf fast allen Seiten, denn einige Aufrufe werden per .htaccess und RewriteRule umgeschrieben. Dies betrifft ausschließlich die News-Meldungen auf dem Portal.

Also dann: Es wird eine URL nach obigem Muster erstellt und in die Adresszeile des Webbrowsers eingegeben. Nur wenn diese URL dem von uns verwendeten Schema entspricht und zugleich auf einen Pfad verweist, der auf unserem Web-Server gar nicht existiert, kommt es zur Ausführung der RewriteRule. Die Webseite versucht den umgeschriebenen Pfad zu verarbeiten und der scharfe JavaScript-Code aus der Adresszeile landet trotz des deaktivierten AcceptPathInfo im Adresspfad.

Das nennt man wohl dumm gelaufen, doch solange der Adresspfad nicht auf der Webseite verwendet wird, passiert auch nichts. Doch wir verwenden den Adresspfad im Portal, um den Google-Übersetzer zu integrieren. Diesem übergeben wir die Ursprungs- und Zielsprache sowie den Pfad der zu übersetzenden URL. Sofern eine ausreichende Bereinigung des Adresspfades durchgeführt wird, geschieht dennoch nichts. Das war aber ausgerechnet bei den umgeschriebenen Adressen nicht der Fall.

Im Rahmen der Umstellung des News-Systems im vergangenen Jahr hatten sich Probleme bei der Integration des Google-Übersetzers gezeigt. Zur Fehleranalyse wurde die URL auf den News-Seiten anders abgefragt und verarbeitet, doch was als Provisorium bis zur endgültigen Lösung gedacht war, blieb bis Freitag aktiv. Und, wie Chirag Prajapati so richtig bemerkt hatte, war die provisorische Bereinigung der URL leider unzureichend gewesen.

Ablauf und Auswirkungen eines Angriffs
Da der JavaScript-Code in einer URL steckt und sich derart manipulierte URLs nicht auf unserer Webseite befinden, muss die bösartige URL auf einer Drittseite platziert oder per E-Mail an ein potentielles Opfer verschickt werden. Wenn das Opfer die URL aufruft, wird zwar Inhalt von Au-ja.de geladen, zusätzlich aber auch der JavaScript-Code des Angreifers ausgeführt. Diesen könnte der Angreifer beispielsweise verwenden, um Zugangsdaten abzufragen.

Da unser Portal keine Benutzerkonten verwendet und sich klar von unserem Forum unterscheidet, dürfte ein solcher Angriff allerdings ins Leere laufen. Hinzu kommt, dass der durch die zusätzlichen Pfadangaben veränderte Pfadkontext die relativen Links auf der Seite ins Leere leitet und damit das Layout zerstört. Die per manipuliertem Pfad aufgerufene Seite sieht eindeutig kaputt aus, was Besucher in der Regel nicht zur Eingabe von Benutzerdaten animiert.

Es fand auch kein Austausch der bösartigen URLs mit unserer Datenbank statt. Tatsächlich ist die Datenbank vollständig vom Portal abgekapselt. Und um es nochmals klarzustellen: Der bösartige Code lag zu keinem Zeitpunkt auf unserem Server, er musste über die URL in der Adresszeile des Webbrowsers an unsere Webseite übermittelt werden. Beim Surfen auf Au-Ja.de hat somit zu keinem Zeitpunkt eine Gefahr bestanden. Nichtsdestotrotz: Die XXS-Lücke war vorhanden und daher gilt unser Dank Chirag Prajapati für seine Entdeckung und deren Meldung!

Timeline:

• 10.03.2023, 16:55 Uhr: Chirag Prajapati von Cybertix meldet eine mögliche Sicherheitslücke.
• 10.03.2023, 18:05 Uhr: Rückfrage bezüglich der Details.
• 10.03.2023, 18:31 Uhr: Chirag Prajapati übermittelt seinen POC für eine XXS-Schwachstelle.
• 10.03.2023, 22:16 Uhr: Fehler bestätigt. Der POC kann JavaScript ausführen, zerstört dabei aber das Layout, so dass die Seite nicht mehr korrekt bzw. vollständig geladen wird.
• 10.03.2023, 22:30 Uhr: Fehler analysiert. Das Problem betrifft nur die Nachrichtensektion der Portalseite, auf der es keinen Login und keine Benutzerdaten gibt. Das Forum ist nicht betroffen.
• 10.03.2023, 23:08 Uhr: Der Fehler wurde mit Hilfe verbesserter Säuberungen beseitigt.
• 11.03.2023, 15:44 Uhr: Zusätzliche Maßnahmen zur Gefahrenabwehr ins CMS integriert.
• 12.03.2023, 17:00 Uhr: Ungültige Pfade, die an AcceptPathInfo Off vorbeikommen, werden nun gezielt abgefangen
• 12.03.2023, 23:54 Uhr: Zusätzliche Maßnahmen zur Gefahrenabwehr in .htaccess integriert.