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

Ich habe ein durch die Cookiebar geblocktest iframe. Seit kurzem bekomme ich statt des iframes eine Fehlermeldung "Forbidden You don't have permission to access this resource. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request."

Es scheint an der Cookiebar zu liegen. Im Protokoll des Webservers erscheint die Fehlermeldung "AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F".

Die URL, die den Fehler verursacht ist wohl:

HTML-Code:

---

https://ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/20?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.php%3Fpropid%3D155937%5B%26%5Dlang%3D%5B%26%5Dreferer%3Dwebseite-leer

---

diese wird irgendwie automatisch durch Cookiebar erzeugt:

PHP-Code:

---

<iframe data-ccb-id="20" src="/cookiebar/block/de/20?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.php%3Fpropid%3D144283%26lang%3D%26referer%3Dwebseite-leertest" data-src="https://beds24.com/booking2.php?propid=144283&amp;lang=&amp;referer=webseite-leertest" width="1100" height="100%" scrolling="no" style="max-width:100%;border:none;overflow:auto;"></iframe> 


---

Ich versehe nur nicht warum. Der eigentliche HTML Code für den iframe wird durch ein PHP Script generiert. Auf der HTML Seite selbst greift dann dort nochmal die Cookiebar ein. Der Zusammenhang ist mir leider nicht klar. Ich vermute irgend ein Java Skript? Aber welche Einstellung, damit Cookiebar dort eingreift?

falsch: https://ferienhaus-schwarzwald-todtn...ropid%3D155937

gut: https://ferienhaus-schwarzwald-todtn.../propid=155937

Scheinbar liegt es an der seltsamen Umschlüsselung der gblockten Ziel-URL durch Cookiebar. Wie kann ich hier eingreifen und z.b. diese Unschlüsselung abschalten. Wenn ich die "%3A" usw. durich die normalen ASCII Zeichen ersetzte funktioniert wieder alles.

Sehr spezifische (Auf Google findet man sicher etwas) oder sehr unspezifische Fehlermeldung deinerseits (Settings? Contao Version? Screenshots? Mehr URLS? Genaue Fehlerbeschreibung? Bitte mehr Informationen wenn du kostenlosen Support willst -> Man für dich dein Problem recherchieren soll).

• Was hast du versucht und wie sind deine Einstellungen in der Cookiebar?
• Was erwartest du?
• Was ist das genaue Problem mit der URL? Du hast hier mehrere gepostet?

Du kannst nicht in die Generierung eingreifen, ohne dass du hier die Klassen der Cookiebar überschreibst.

Nur zur Nachverfolgung, wurde auch 2 Stunden nach Erstellung des Threads auf GitHub gepostet:
https://github.com/oveleon/contao-cookiebar/issues/212

@d003232: du hast in deinem Github Ticket auch das PHP Script veröffentlich. Dieses PHP Script solltest du umgehend von der Website in dieser Form entfernen, da du damit eine XSS Sicherheitslücke eingebaut hast. // achso, die Nutzung von $_GET ist vermutlich nur für {{file::*}}, dann ist es weitgehend ok.

Davon abgesehen scheint der 403 Fehler von deinem Web Server zu kommen. Du musst daher bei deinem Web Server prüfen, warum es dazu kommt.

Danke für die Anregungen. Ein klein wenig bin ich weiter gekommen. Offenbar liegt es an der Umschlüsslung von "?" in "%3F" in der URL durch cookiebar. Aber warum schreibt cookiebar das "?" in der URL überhaupt um?

So funktioniert die URL nicht und führt zum 403 Fehler:
ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/16?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.ph p%3Fpropid%3D155937%26lang%3D%26referer%3Dwebseite-leer

so funktioniert die URL:
ferienhaus-schwarzwald-todtnauberg.de/cookiebar/block/de/16?redirect=https%3A%2F%2Fbeds24.com%2Fbooking2.ph p?propid%3D155937%26lang%3D%26referer%3Dwebseite-leer

Im Server Log von Strato finde ich einen dazu passenden Fehler: AH10508: Unsafe URL with %3f URL rewritten without UnsafeAllow3F

Nun ist mir nicht klar:
1. Liegt es an einer Webserver Einstellung bei Strato, d.h. ich muss irgendwie ein "UnsafeAllow3F" aktivieren?
2. oder müsste cookiebar einfach das "?" in der URL lassen und dieses nicht umschreiben?

Ansonsten:
Contao 5.3.11
cookiebar 2.1.1

Ich bin verunsichert, ob es vielleicht noch durch eine veraltetet Datei aus Contao 4.x kommt? Gleichzeitig tritt der "forbidden Fehler" nicht zu 100% auf. Machmal geht es einfach.

Der Fehler kommt wie gesagt vom Web Server direkt und hat nichts mit Contao oder PHP zu tun.

Zitat:

---

Zitat von Spooky

Der Fehler kommt wie gesagt vom Web Server direkt und hat nichts mit Contao oder PHP zu tun.

---

Dass der Webserver den 403 Fehler meldet habe ich verstanden.

Was mir nicht klar ist, ist warum cookiebar das "?" in der URL umschlüsselt? Wenn das nicht passieren wäre, würde der Webserver auch keinen 403 Fehler erzeugen. Ich kann z.B. das "%3f" in der url im Firefox Debugger manuell wieder auf 2?" abändern. Dann wird das iframe wieder ordentlich geladen.

Anhang 27291
Anhang 27292

Das zweite Fragezeichen (also der gesamte Wert des "redirect" Parameters) muss encodet sein, andernfalls wäre es eine ungültige URL.

Zitat:

---

Zitat von Spooky

Das zweite Fragezeichen (also der gesamte Wert des "redirect" Parameters) muss encodet sein, andernfalls wäre es eine ungültige URL.

---

Hmm. Warum kommt es dann zum 403 Fehler, wenn das zweite Fragezeichen encodet ist? Wenn es nicht entcodet ist funktioniert alles.

Liegt das an den Einstellungen des Webservers? Wo könnte ich da etwas einstellen? Eigentlich bekommt doch der Webserver gar nicht direkt den redirect Parameter?

Zitat:

---

Zitat von d003232

Eigentlich bekommt doch der Webserver gar nicht direkt den redirect Parameter?

---

Doch, natürlich, der Web Server bekommt die URL als Erstes.

Ich bin einen kleinen Schritt weiter, brauche aber nochmal Hilfe:

1. Ursache scheint ein Sicherheitsupdate zum 1.7.2024 im Apache Server 2.4.59 zu sein, der Rewrite Rules für das '?' (%3F) nicht mehr erlaubt:
   https://www.cve.org/CVERecord?id=CVE-2024-38474
   
2. Um der Umschreibung zu erlauben, kann man das Rewrite Flag UnsafeAllow3F setzen (oder vermutlich hoffen, dass de Provider ein Update von Apache auf 2.4.60 vornimmt?):
   https://httpd.apache.org/docs/curren...nsafe_allow_3f

Wer weiß, in welcher Rewrite Rule ich das UnsafeAllow3f setzten muss, damit das Encoding von cookiebar wieder funktioniert. Welche Rewrite Rule nutzt cookiebar?

Hm, ich denke du bist schon auf Apache 2.4.60 und deswegen kommt es zu diesem Fehler. So lese ich das zumindest.

Zitat:

---

Zitat von Spooky

Hm, ich denke du bist schon auf Apache 2.4.60 und deswegen kommt es zu diesem Fehler. So lese ich das zumindest.

---

phpinfo sagt: "SERVER_SOFTWARE Apache/2.4.59 (Unix)" / Provider ist Strato

Ich hätte es so verstandem, dass das Sicherheitsupdate für 2.4.59 gilt, um das Sicherheitsrisiko zu patchen. Mit 2.4.60 wäre das grundsätzliche Problem dann behoben, so dass man den Workaround mit UnsafeAllow3F nicht mehr bräuchte?

So interpretiere ich das zumindest nicht. Die Sicherheitslücke betrifft alle Apache 2.4 Versionen bis inkl. 2.4.59. Die Sicherheitslücke wurde in allen Apache Versionen mit Build Date am or nach dem 4. Juli geschlossen. Seitdem tritt das Problem in diesen Apache Versionen auf, da man nun immer UnsafeAllow3F braucht.

Angeblich ab 2.4.61 dann aber nicht mehr, laut einem Stackoverflow Post, das konnte ich aber nicht unabhängig bestätigen.

Poste mal deine .htaccess

Zitat:

---

Zitat von Spooky

Poste mal deine .htaccess

---

PHP-Code:

---

# Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
<FilesMatch "(\.htaccess)">
  Order deny,allow
  Deny from all
</FilesMatch>

<IfModule mod_rewrite.c>
    RewriteEngine On

    <IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #   following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule> 


---

Ersetze

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

mit

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

Zitat:

---

Zitat von Spooky

Ersetze

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

mit

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

---

Die Verwendung des Flags scheint grundsätzlich zu einem 500er Fehler des Webservers zu führen. Ich vermute, dass der Parameter aktuell bei Strato nicht erlaubt ist?

Nun habe ich dreimal versucht, den Support von Strato zu erreichen. Tatsächlich dreimal in weniger als 60 Sekunden durchgekommen ... nur versuch das Problem mal jemandem zu erklären, der im First Level Suport von Webservertechnik quasi nichts versteht. :(

Falls es dem Support hilft: einfach nur erklären, dass URLs wie

Code:

---

https://ferienhaus-schwarzwald-todtnauberg.de/?foo=%3F

---

aktuell nicht funktionieren.

Zitat:

---

Zitat von d003232

Die Verwendung des Flags scheint grundsätzlich zu einem 500er Fehler des Webservers zu führen.

---

Poste die .htaccess nach der Änderung.

Zitat:

---

Zitat von Spooky

Poste die .htaccess nach der Änderung.

---

Nein, kein Tippfehler :-)

PHP-Code:

---

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


---

Die Idee mit dem kleinen Beispiellink https://ferienhaus-schwarzwald-todtnauberg.de/?foo=%3F ist gut.

Zumindest in meinem lokalen Apache 2.4.61 konnte ich das Problem nicht nachstellen. Leider habe ich (für Windows) keinen Download für 2.4.60 oder 2.4.59.1 gefunden um zu verifizieren, dass das Problem dort tatsächlich auftritt.

Leider dauert es bei Strato mehrere Stunden, bis man den aktuelle Errorlog des Webservers sieht. Hier nun das Ergebnis von gestern:

PHP-Code:

---

home/strato/http/premium/rid/00/00/xxxxxxxx/htdocs/xxxxxxxxxxxx/contao-prod/public/.htaccess: RewriteRule: unknown flag 'UnsafeAllow3F' 


---

Das bedeutet ich muss auf die Antwort des Strato Supports warten, bis ich das neue rewrite flag UnsafeAllow3f in der .htaccess setzen kann.

Ich melde mich, sobald ich Neues habe. Bis dahin nehme ich meine iframes erst mal aus der cookiebar raus, damit mein Buchungsformular wieder nutzbar wird.

Leider kann ich nicht wirklich helfen, da ich keinen Zugang zum Strato Vertrag habe. Alles was mit FTP zu tun hat, kann ich aber testen.

@eisensau: einfach an eine URL einer auf Strato gehosteten Contao 4+ Seite ?foo=%3F anhängen. Wenn kein 403 Fehler vom Server kommt, bist du nicht betroffen.

Da war ich etwas sparsam mit den Informationen.
Ich habe gestern aufgrund des gleichen Problems die Cookiebar für die Youtube Videos abgeschaltet.

FYI: Die TYPO3 Community ist von diesem Problem ebenfalls betroffen. Danke Euch für die Insights hier.
Ein Benutzer bei uns im TYPO3 Community Hub hat nun folgendes geteilt:

Zitat:

---

Antwort vom Support eben: Problem ist bekannt und soll heute Abend spätestens Morgen früh behoben sein.

---

Quelle: https://forum.t3academy.de/d/507-neu...n-error-403/22

Aus einem Thread im TYPO3 Slack Channel #typo3-cms:

Zitat:

---

Update vom STRATO Service
Wir verweisen auf Schwachstellenbeschreibung CVE-2024-38474 (https://www.cve.org/CVERecord?id=CVE-2024-38474). Dieses Update wird generell auf allen gängigen Apache Instanzen installiert werden.
Aus Sicherheitsgründen werden wir die unsichere Methode die Typo3 verwendet auf den Hostsystemen nicht wieder freigeben. Wir bitten Sie ggfs. den Entwickler von Typo3 zu Kontaktieren und Ihn auf die Schwachstelle hinzuweisen. Wir empfehlen ausdrücklich keine Modifikationen die dies umgeht umzusetzen, weil Sie dadurch angreifbar werden.

---

Quelle: https://typo3.slack.com/archives/C02...&cid=C025BQLFA

Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist. Benutzer berichten, dass ihre betroffenen Instanzen noch Apache 2.4.59 nutzen.
Anhang 27297

Betroffene STRATO-Kunden sollten also darum bitten, Apache zu aktualisieren.

Wenn man nicht im Typo3 Slack angemeldet ist, kann man dies leider nicht lesen :)

Wenn Nutzer von 2.4.59 berichten, evtl. gab es hier einen Fix vom Provider (STRATO) selbst? (Ähnlich wie beim extended Support)

Zitat:

---

Zitat von ErHaWeb

Aus einem Thread im TYPO3 Slack Channel #typo3-cms:

Quelle: https://typo3.slack.com/archives/C02...&cid=C025BQLFA

Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist. Benutzer berichten, dass ihre betroffenen Instanzen noch Apache 2.4.59 nutzen.
Anhang 27297

Betroffene STRATO-Kunden sollten also darum bitten, Apache zu aktualisieren.

---

Klar, die TYPO3-Entwickler und auch andere darum zu bitten, die Schwachstelle in Apache zu umgehen, die Apache bereits behoben hat, ist ein netter, wenn auch recht plumper Versuch davon abzulenken, dass man es selbst schlicht nicht schafft, das entsprechende Sicherheits-Update für Apache schnell genug einzuspielen. Wenn das die beste Lösung wäre, dann hätten sich die Apache-Entwickler das Sicherheits-Update sparen können.

Tritt der Fehler bei Ionos auch auf oder sind die mit dem Update schon durch?

Zitat:

---

Wenn man nicht im Typo3 Slack angemeldet ist, kann man dies leider nicht lesen

---

Schon klar, die Quellenangabe ist nur für diejenigen gedacht, die in direkten Kontakt mit "Leidensgenossen" der TYPO3 Community treten wollen und sich dort im Slack registrieren.
Das ist natürlich ein Aufwand den nicht jeder betreiben will. Aber hey, lieber eine Quelle zu viel als zu wenig ;)

Hier habe ich weitere Interessante Infos gefunden:
https://stackoverflow.com/questions/...-unsafeallow3f

Zitat:

---

The issue here is not question marks in URLs as such. It is url-encoded question marks in URLs that are used for serving static files.

Bad version:
example.com/images?route=/cats/long-hair%3fsize=large
example.com/login?returnto=/cats/long-hair%3fsize=large

Good versions:
example.com/images/cats/long-hair?size=large
example.com/login?returnto=/cats/long-hair&returntoparams=size%3dlarge

---

Bei uns wird aktuell noch versucht herauszufinden, wer für die Lösung des Problems verantwortlich ist.

Zitat Mathias Brodala aus dem Slack Channel:

Zitat:

---

Die schlechte Version in dem Beispiel auf StackOverflow ist an sich nicht schlecht. Das Schlimme daran ist, dass es nichts gibt, was die Integrität von route / returnto sicherstellt. So kann jeder Client den Wert des Parameters manipulieren und ihn frei ändern. Dies wird normalerweise durch authentifizierte Hashes, Token usw. verhindert. Und TYPO3 tut das AFAIK. Daher ist es IMO ziemlich sinnlos, URLs mit einem verschlüsselten Fragezeichen selbst zu verweigern.

---

Zitat:

---

Zitat von ErHaWeb

Schon klar, die Quellenangabe ist nur für diejenigen gedacht, die in direkten Kontakt mit "Leidensgenossen" der TYPO3 Community treten wollen

---

Slack ist ein flüchtiger Speicher - Forumsbeiträge können schneller gefunden werden und die Informationen stehen bereit.
Selbes Thema mit GitHub Issues - Alle Informationen stehen im Forum mit Link -> Dann wird das Issue halt ignoriert, bis alle Informationen im Issue stehen - Man muss ja nicht für jeden recherchieren und den Extra-Aufwand betreiben :D

Zitat:

---

Zitat von ErHaWeb

Das merkwürde daran ist, dass das Problem ja laut CVE-2024-38474 in Apache 2.4.60+ behoben ist.

---

Siehe mein vorheriger Post. Mit Apache 2.4.60 wurde UnsafeAllow3F eingeführt - dieses Feature, also der Patch für die Sicherheitslücke, wurde allerdings auch in alten Versionen über neuere Builds gepatched.

Der Fehler liegt nicht bei Strato selbst. Das Problem ist die Art und Weise wie Apache diese Sicherheitslücke handhabt. Meiner Meinung nach muss Apache hier zurück rudern und eine andere Lösung finden.

Nur mal zur Nachverfolgung:
Hier wird das Fragezeichen angehängt:
https://github.com/oveleon/contao-co...tener.php#L377

Gestern habe ich schon nachgeschaut, man müsste es umbauen, damit es auch ohne gehen würde, dann würde innerhalb des IFrames aber auch nicht mehr die URL erhalten werden können... das kommt noch aus Anfängen der Cookiebar.
Ist nun halt die Frage ob hier Strato schuld ist, Apache es schon behoben hat oder nicht?

Oder anders gesagt:

Wenn es schon behoben wurde in Apache 2.4.61... Dies aber auftritt, da Hoster wie STRATO einfach zu schnell patchen und dann auf einer Kaffeefahrt sind (So schnell geht günstig, Faster. Better. Strato, So schnell geht das), lohnt sich der Aufwand des Umbaus?

Soweit ich das verstehe wird das Problem in jeder Apache Version auftreten (also in allen Versionen wo UnsafeAllow3F unterstützt ist).

Contao selbst ist davon auch betroffen, nicht nur Extensions.

Das heißt, das Problem ist derzeit nur dadurch behoben, dass diese URLs einfach per Default nicht mehr genutzt werden können? Und wer dann meint, dass seine Anwendung selbst die Angriffsmöglichkeiten zuverlässig verhindert - oder dass ihm die Sicherheit egal ist, der kann dann das Flag setzen und gut ist (oder eben auch nicht)? Sprich, man überträgt die Verantwortung dafür dem Programmierer und/oder Anwender der Anwendung (hier TYPO3, Contao, ...)?

Ja, genau so würde ich es auch zusammenfassen nach aktuellem Wissensstand.

Im Fall von STRATO kommt allerdings erschwerend hinzu, dass das Flag "UnsafeAllow3F" nicht gesetzt werden darf > Error 500
https://community.contao.org/de/show...ten#post586344

Zitat:

---

Zitat von tab

Das heißt, das Problem ist derzeit nur dadurch behoben, dass diese URLs einfach per Default nicht mehr genutzt werden können?

---

Man muss die jeweilige Applikation umschreiben, bspw. auf base64 encoded URLs (wäre mein Ansatz).

Zitat:

---

Zitat von tab

Und wer dann meint, dass seine Anwendung selbst die Angriffsmöglichkeiten zuverlässig verhindert - oder dass ihm die Sicherheit egal ist, der kann dann das Flag setzen und gut ist (oder eben auch nicht)? Sprich, man überträgt die Verantwortung dafür dem Programmierer und/oder Anwender der Anwendung (hier TYPO3, Contao, ...)?

---

Die Anwendung selbst hat gar nichts mit der Sicherheitslücke zu tun. Die betrifft einzig und allein den Web Server selbst (also Apache).

In wie weit UnsafeAllow3F bei der Default RewriteRule von Symfony/Contao (also die, die alle sonstigen Requests auf die index.php umschreibt) ein Sicherheitsproblem für den Web Server darstellt, kann ich auch nicht beurteilen, da ich das eigentliche Sicherheitsproblem zu wenig verstehe. Meine Vermutung wäre, dass das hinzufügen von UnsafeAllow3F bei der oben erwähnten Regel kein Problem wäre, da dass ja ohnehin nur für Requests gilt, die nicht auf physische Ressourcen gehen. Aber wie gesagt - könnte eine Fehleinschätzung sein.

Zitat:

---

Zitat von ErHaWeb

Ja, genau so würde ich es auch zusammenfassen nach aktuellem Wissensstand.

Im Fall von STRATO kommt allerdings erschwerend hinzu, dass das Flag "UnsafeAllow3F" nicht gesetzt werden kann ? Error 500
#post586344

---

Fände ich aber auch nachvollziehbar, je nachdem was Angreifer aus der "Weakness" machen können. Strato wird sich im Shared Webhosting schwer tun zu entscheiden, welche Anwendung eines Kunden trotz Setzen des Flags tatsächlich sicher ist und welche nicht. Das kann man eventuell noch dem einzelnen Kunden überlassen, aber nur solange es nur den Kunden selbst betrifft. Wenn das Setzen des Flags "UnsafeAllow3F" durch einen Kunden (bei Verwendung einer unsicheren Anwendung) aber möglicherweise auch Webspaces anderer Kunden kompromittiert, dann wäre das natürlich ein absolutes NoGo im Shared Webhosting.

Ja, Strato liegt hier nicht falsch.

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.

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 :/

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

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

Code:

---

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

---

auf

Code:

---

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.

@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.

Zitat:

---

Zitat von Spooky

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).

Zitat:

---

Zitat von ausi

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!

Zitat:

---

Zitat von d003232

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.

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

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?

Zitat:

---

Zitat von d003232

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

---

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

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

Zitat:

---

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.

Zitat:

---

Zitat von d003232

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?

Zitat:

---

Zitat von d003232

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“.

Zitat:

---

Zitat von d003232

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.

Zitat:

---

Zitat von ausi

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.

Zitat:

---

Zitat von zoglo

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.

Es geht wieder!!!

Offensichtlich hat Strato dich eine Änderung vorgenommen!

Zitat:

---

Zitat von d003232

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.

Zitat:

---

Zitat von d003232

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.

Zitat:

---

Zitat von ausi

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

Zitat:

---

Zitat von d003232

Es geht wieder!!!

Offensichtlich hat Strato dich eine Änderung vorgenommen!

---

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?

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.

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

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.