Fehler 403 Forbidden durch Cookiebar AH10508: Unsafe URL with %3f URL rewritten

[ErHaWeb]

Ja, STRATO kann man hier keinen Vorwurf machen. Die schließen eine bekannte Sicherheitslücke und verhindern, dass diese umgangen werden kann.

Das unschöne bei dieser "Lösung" durch Apache ist nur, dass Anwendungen, die bereits von sich aus die URL-Integrität gewährleisten (in TYPO3 z.B. über authentifizierte Hashes, Token usw.), ebenfalls darunter leiden.

Ich bin gespannt ob nun die jeweiligen Core Teams der Applikationen aktiv werden müssen oder ob Apache doch noch zurück rudert und eine andere Lösung liefert.

[Spooky]

Bei Contao werden wir wohl eher mal abwarten. Da das hauptsächlich Login Redirects betrifft ist die Auswirkung nicht ganz so schlimm. Bei gewissen Extensions (wie der oveleon/contao-cookiebar) ist das natürlich anders, dort müsste man ggf. doch einen Workaround einbauen - auch wenn es unsinnig erscheint :/

[Spooky]

Bei Strato läuft jetzt auch Apache 2.4.61 - das Problem bleibt wie erwartet bestehen.

[ausi]

In der Dokumentation vom Apache steht für UnsafeAllow3F folgendes:

Setting this flag is required to allow a rewrite to continue If the HTTP request being written has an encoded question mark, '%3f', and the rewritten result has a '?' in the substiution. This protects from a malicious URL taking advantage of a capture and re-substitution of the encoded question mark.

Der Fehler sollte somit nur auftreten wenn man in der Substiution (dem Ziel-URL-Teil der RewriteRule) ein Fragezeichen verwendet.

Lokal konnte ich das auch reproduzieren wenn ich die Rule

RewriteRule ^ %{ENV:BASE}/index.php [L]

auf

RewriteRule ^ %{ENV:BASE}/index.php?x [L]

ändere, dann kommt bei mir ebenfalls der 403-Fehler für alle URLs die %3F enthalten.

Wenn ein Aufruf von /preview.php?foo=%3F auch zu dem 403-Fehler führt, kann das Problem eigentlich nicht an der .htaccess von Contao liegen, da für diese URL nichts rewritten wird.

Nachdem die URL https://ferienhaus-schwarzwald-todtn...on.png?foo=%3F funktioniert, aber https://ferienhaus-schwarzwald-todtn...ew.php?foo=%3F nicht, gehe ich davon aus, dass in der Apache-Konfiguration vom Webspace eine RewriteRule für PHP-Dateien existiert die diesen Fehler verursacht.

[Spooky]

@ErHaWeb @d003232 mit der Information könnt ihr nun an Strato herantreten. Es liegt somit höchstwahrscheinlich doch an RewriteRules, die Strato in deren Config nutzt.

[ausi]

Es liegt somit höchstwahrscheinlich doch an RewriteRules, die Strato in deren Config nutzt.

Das könnte man vorab noch verifizieren indem man die .htaccess von Contao komplett löscht und dann prüft ob https://ferienhaus-schwarzwald-todtn...ew.php?foo=%3F noch immer zum 403-Forbidden-Fehler führt (anstatt zum Login weiterzuleiten).

[d003232]

Das könnte man vorab noch verifizieren indem man die .htaccess von Contao komplett löscht und dann prüft ob https://ferienhaus-schwarzwald-todtn...ew.php?foo=%3F noch immer zum 403-Forbidden-Fehler führt (anstatt zum Login weiterzuleiten).

Ich habe die .htaccess Datei im contao/public Verzeichnis testweise gelöscht. Der 403 forbiden Fehler tritt trotzdem auf!

[ausi]

Ich habe die .htaccess Datei im contao/public Verzeichnis testweise gelöscht. Der 403 forbiden Fehler tritt trotzdem auf!

Damit sollte eindeutig sein, dass es ein Problem des Hosters ist.

[ErHaWeb]

Das TYPO3 Core Team hat mittlerweile ebenfalls bewiesen, dass dieses Problem direkt im Zusammenhang mit STRATO steht.
Grundsätzlich funktioniert TYPO3 auch mit Apache 2.4.60+.

siehe: https://forge.typo3.org/issues/104410

[d003232]

Ich kann nachvollziehen, dass es nichts mit Contao zu tun hat. Grundsätzlich führt ein "%3F" in der URL zum Zugriffsfehler (z.B. https://ferienhaus-schwarzwald-todtnauberg.de/%3f ). Das ist bei Strato auch der Fall, wenn unter der Domain gar kein Contao läuft.

Die Frage wäre nun, ob cookiebar trotzdem das "%3f" in der URL vermeiden kann ... oder ob man warten muss, bis Strato von seiner Seite etwas ändert?

[Spooky]

Die Frage wäre nun, ob cookiebar trotzdem das "%3f" in der URL vermeiden kann ...

Grundsätzlich ja - du könntest das ja beauftragen.

[d003232]

Der Strato Support hat sich gemeldet. Man scheint zu keiner Änderung bereit:

Wir haben Ihr Anliegen umfangreich geprüft und konnte die übermittelte Information feststellen.

Weitere Einschränkungen konnten von der zuständigen Fachabteilung nicht festgestellt werden.

Ich bedaure, Ihnen keine andere Auskunft geben zu können und wünsche einen angenehmen Mittwochabend.

Somit führen bei Strato alle URL zu einem Zugriffsfehler, die den String "%3f" enthalten, egal an welcher Stelle. Ein uncodiertes "?" oder ein anders codiertes "?" wären wohl kein Problem.

[ausi]

Wir haben Ihr Anliegen umfangreich geprüft und konnte die übermittelte Information feststellen.

Was heißt das? Haben sie noch eine Information übermittelt mit irgendwelchen Feststellungen?

Weitere Einschränkungen konnten von der zuständigen Fachabteilung nicht festgestellt werden.

Heißt das, sie haben festgestellt das es kein allgemeines Problem ist? Wenn ja, in welchen Rahmenbedinungen tritt die Einschränkung nicht ein?

Ich kann mir ehrlich gesagt nicht vorstellen, das ein Hoster tatsächlich sagt „Bei uns kann man keine URLs mit %3F verwenden“.

[zoglo]

Der Strato Support hat sich gemeldet. Man scheint zu keiner Änderung bereit:


Somit führen bei Strato alle URL zu einem Zugriffsfehler, die den String "%3f" enthalten, egal an welcher Stelle. Ein uncodiertes "?" oder ein anders codiertes "?" wären wohl kein Problem.

Wenn du es schnell und dringend brauchst für STRATO (incoming slogan: So schnell geht günstig).
Finanziell beauftragen über die "info@oveleon.de" wie von spooky erwähnt oder selber als PR gegen die 1.x bereitstellen, gerne auch gegen die 2.x für Contao ^5.

[d003232]

Ich kann mir ehrlich gesagt nicht vorstellen, das ein Hoster tatsächlich sagt „Bei uns kann man keine URLs mit %3F verwenden“.

Vermutlich müssen sich noch mehr beschweren. Wie der First Level Support ja schreibt, sieht die "Fachabteilung" damit kein Problem, da ja alles andere funktioniert.

[d003232]

Wenn du es schnell und dringend brauchst für STRATO (incoming slogan: So schnell geht günstig).
Finanziell beauftragen über die "info@oveleon.de" wie von spooky erwähnt oder selber als PR gegen die 1.x bereitstellen, gerne auch gegen die 2.x für Contao ^5.

Ich nehme jetzt erst mal alle iframes aus der cookiebar raus. Damit kann ich auch leben. Vielleicht hat ja Strato irgendwann Einsicht oder ich wechsel den Provider.

[d003232]

Es geht wieder!!!

Offensichtlich hat Strato dich eine Änderung vorgenommen!

[zoglo]

Vermutlich müssen sich noch mehr beschweren. Wie der First Level Support ja schreibt, sieht die "Fachabteilung" damit kein Problem, da ja alles andere funktioniert.

Beschweren hilft nicht viel, erzeugt nur mehr Druck - Druck ist schlecht.

Ich nehme jetzt erst mal alle iframes aus der cookiebar raus. Damit kann ich auch leben. Vielleicht hat ja Strato irgendwann Einsicht oder ich wechsel den Provider.

Du kannst die Cookiebar auch deaktivieren und auf ein Update warten.

Ich habe das Issue schon vor deiner Antwort auf GitHub wiedereröffnet, irgendwann wenn wieder Zeit ist, wird man drangehen, derzeit sind alle Maintainer in anderen (finanziell tragbaren) Projekten verplant.

[mlweb]

Ich kann mir ehrlich gesagt nicht vorstellen, das ein Hoster tatsächlich sagt „Bei uns kann man keine URLs mit %3F verwenden“.

Grundsätzlich kann ich mir bei Strato leider alles vorstellen. Das zeigt ja dann auch die folgende Feststellung

Es geht wieder!!!

Offensichtlich hat Strato dich eine Änderung vorgenommen!

[d003232]

Offensichtlich hat Strato den Check auf '%3f' geändert:

Ein '%3f' ohne vorheriges '?' führt zu einem Zugriffsfehler. Ein '%3f' nach einem vorherigen '?' ist ok.

geht: https://ferienhaus-schwarzwald-todtnauberg.de/?foo=%3f
geht nicht: https://ferienhaus-schwarzwald-todtnauberg.de/%3fdummy

Damit ist doch nun alles Gut und das Thema abgeschlossen?

[Spooky]

Grundsätzlich nicht. Strato muss erklären, warum man bei denen keine URLs mit "%3F" nutzen darf.

Gestern Abend war das übrigens noch anders, da ging alles. Seither haben sie wieder etwas geändert.

[hinzke]

habe heute von strato mitgeteilt bekommen dass dort ein update vorgenommen wurde und das problem tatsächlich erledigt ist aber es kann auf anderen servern mit gleicher apache-version auch auftauchen

[neelix]

Mit Apache 2.4.63 kommt ein Fix, der den Fehler wieder behebt.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69197

Ist dann nur noch eine Frage der Zeit, bis die Version auch in den div. Distris und den Hostern ankommt. Bis dahin muss man sich mit dem Workaround behelfen.

Der ursprüngliche Fix war etwas übereifrig und hat mehr Fälle erwischt als nötig.