Auch als Web Entwickler mit langjähriger Erfahrung erlebt man immer wieder mal Überraschungen. Zum Beispiel, wenn plötzlich Fragezeichen anfangen, Probleme zu bereiten.
In einer Webanwendung, die wir intern verwenden, führten plötzlich bestimmte Parameter zu unerwarteten Problemen. In URLs können Parameter im sogenannten Query String übergeben werden. So enthält die URL https://meine.seite.tld/index.php?page=3 den Parameter page mit dem Wert 3. Das klappte in der Regel auch ohne Probleme - außer, wenn der Parameterwert ein Fragezeichen enthielt. In diesen Fällen wurde die Anfrage nicht wie vorgesehen verarbeitet, sondern der Apache Webserver reagierte mit einem 403 Forbidden. Das passierte, obwohl das Fragezeichen korrekt encodiert war.
Bestimmte Zeichen, wie zum Beispiel Slashes oder eben Fragezeichen, haben in einer URL nämlich spezifische Bedeutungen. Will man sie als “gewöhnliche” Zeichen zum Beispiel in einem Parameterwert verwenden, muss man sie maskieren oder encodieren. So wird beispielsweise aus einem Leerzeichen %20, aus einem Slash %2F oder aus einem Fragezeichen %3F.
Über ein so encodiertes Fragezeichen sollte eine Webanwendung eigentlich nicht stolpern. Eigentlich. In diesem Fall passierte es aber trotzdem.
Als Ursache des Problems stellte sich eine Sicherheitseinrichtung des Apache HTTPd Webservers heraus, nämlich im Kontext von Rewrites. Das sind, kurz gesagt, Weiterleitungen von einer URL auf eine andere. In bestimmten Fällen kann es nun passieren, das ein solches Rewrite einen Angreifer an Orte auf dem Server führt, wo er keinen Zugriff haben sollte. Zu diesem Angriffsszenario gehört, dass die Ursprungs-URL des Rewrites ein encodiertes Fragezeichen enthält, sowie die Ziel-URL ein nicht encodiertes Fragezeichen. Weitere Informationen gibt es in CVE-2024-38474.
Um solche Fälle zu vermeiden, schlagen solche Redirects ab Apache HTTPd 2.4.60 fehl. Und genau das, stellte sich heraus, war die Ursache unseres Fragezeichen-Problems. Diese neue Sicherheitseinrichtung lässt sich mit dem Flag UnsafeAllow3F abschalten. Natürlich sollte man dieses Flag nur einsetzen, wenn man sichergestellt hat, dass man damit nicht genau die Sicherheitslücke aufreißt, die durch die Änderung in Apache HTTPd 2.4.60 gestopft werden soll.
