phpBB.de

OK.
Diese rewrite rule sollte dann m.E. so aussehen:
Es darf aber auch durch die betroffene Extension keine .htaccess mit rewrite rule "mitgebracht" worden sein.

Ich werde das mal umgehend testen.

Das funktioniert absolut nicht . Wenn man das in der htaccess so ändert kommt das hier:

https://i.ibb.co/sFf4w8S/fehler1.png

Kannst Du mal das Server-error-log mitliefern ?

Nachtrag:
Habe das Flag jetzt auch mal bei mir gesetzt, da gibt es ja keinen, der den Apachen verstellt. Bei mir keine Fehlermeldung wegen des Flags. Strato scheint die Nutzung unterbunden zu haben.

Kommando zurück, habe es an einer falschen (auskommentierten) Stelle gesetzt (Mit Handy nicht so einfach).
Ich bekomme auch einen Fehler und im Serverlog steht, "unknown Flag". Allerdings habe ich apache 2.4.59.

Servus Bruno

69bruno hat geschrieben: 17.07.2024 11:16 Oder aber, ein Serverspezialist lehrt mich eines Besseren. Mein Verständnis von .htaccess-Datein geht in die Richtung:

Ich bin primär Anwendungsprogrammierer, kein Serverspezialist, aber soweit meine Kenntnisse bezüglich .htaccess gehen:

- Bei jedem Seitenaufruf werden die .htaccess-Dateien linear eingelesen. Bei phpBB3 wäre das dann die erste im Forenroot, dann das nächste Verzeichnis, dann das übernächste, bis man im Verzeichnisbaum im Verzeichnis des akiven documents gelandet ist.

Genau, dabei werden immer zuerst alle übergeordneten .htaccess ausgewertet und erst als letzte diejenige des Ordners in dem man sich aktuell befindet.

- Die Regeln einer .htaccess werden nicht zwischengespeichert, also gilt immer die letzte Regel (der untersten .htaccess)(Nicht wiederholte/neugeregelte Regeln gelten fort)

Doch, das wäre ja sonst auch ganz übel, Stichwort Berechtigungen zum Beispiel. Bei Berechtigungen gilt zuerst immer die oberste .htaccess, dann werden der Reihe nach alle untergeordneten berücksichtigt, bis man beim aktiven Ordner angelangt ist. So kann man im Root z.B. den Gruppen A und B Zugang gewähren, aber im Ordner A der Gruppe B den Zugang verwehren und bei Ordner B der Gruppe A.

69bruno hat geschrieben: 17.07.2024 11:48 Es darf aber auch durch die betroffene Extension keine .htaccess mit rewrite rule "mitgebracht" worden sein.

Eher nicht. Ich wüsste gerade keinen guten Grund, warum eine Ext eine .htaccess mitliefern soll/muss. Das Thema Server-Berechtigungen und Einstellungen ist nicht Sache der Ext Coder, sondern Sache des Administrators.

Im Moment ist mir das auch noch nebulös. Mir ist z.B. nicht klar, ob der "böse" Code generell bei URLs greift, oder nur dann, wenn der böse Code in einer RewriteRule vorhanden ist. Dazu fand ich widersprüchliche Aussagen bei meiner Recherche.

Also ich weis nicht was strato jetzt geändert hat. Aber jetzt scheint es wieder zu gehen.

Das dürfte dann damit zusammenhängen:

Staendike hat geschrieben: 16.07.2024 18:33 Habe bei Strato angerufen und angeblich wissen die von diesem Problem und sind wohl dabei den Fehler zu suchen

Kann ich nur bestätigen.
Bei mir geht jetzt auch wieder alles komischerweise.
Was Strato da gemacht hat, weiß ich nicht.

Bei uns besteht dieses Problem weiterhin. Wir sind auch bei Strato und bei uns läuft phpBB 3.3.12 unter dem Apachen 2.4.61.

Was ich bisher herausgefunden habe ist, dass das mit dem Update des Apache auf Version 2.4.60 oder später zusammenhängt. Dort ist eine Sicherheitslücke geschlossen worden, nach der die Kodierung des Fragezeichens in einem URL mittels %3F mit einem 403-Fehler beantwortet wird.

Da einige Seiten von phpBB in der Variable redirect eines URLs das Fragezeichen mit %3F kodieren, tritt überall dort dieser Fehler auf. Zum Beispiel im Login von einer Unterseite oder bei den Links der Schnellmoderation unter den Beiträgen. Eben überall, wo das redirect gesetzt wird.

Wenn der Fehler "plötzlich" weg ist, kann es sein, dass Strato die Seite wieder auf einen noch nicht aktualisierten Server gelegt hat oder eben die Geschichte mittels UnsafeAllow3F gelöst wurde. Bei uns hat Strato eine Rückänderung jedoch explizit ausgeschlossen. Auch kann es sein, dass der Fehler sich erst langsam durchfrisst, wenn noch alte Seiten irgendwo im Cache sind.

Über die .htaccess kann man das systemlogisch nicht lösen, da der Fehler bereits im Apachen passiert ist, wenn die .htaccess ausgeführt wird. Das führt also nicht weiter.

Achso: Ich habe das hier bereits in den Bug Tracker eingetragen, mit der Vermutung, dass das alles so stimmt, was ich hier schreibe. Bitte korrigiert mich, wenn dem nicht so ist.

Fast zeitgleich mit dem Absenden meines obigen Beitrags funktioniert es jetzt auch bei uns wieder.

Eisrose hat geschrieben: 18.07.2024 17:47 Achso: Ich habe das hier bereits in den Bug Tracker eingetragen, mit der Vermutung, dass das alles so stimmt, was ich hier schreibe. Bitte korrigiert mich, wenn dem nicht so ist.

Was mir jetzt noch unklar bleibt, ist, ob Strato einfach das UnsafeAllow3F-Flag gesetzt hat oder ob das ein Fehler beim Update des Apachen bei Strato war. Wenn letzteres der Fall ist, muss ich eigentlich meine Fehlermeldung im Bug Tracker schliessen. Wenn es sich dagegen um einen generellen Fehler handelt, der aufgrund der Beseitigung eines Sicherheitsproblems beim Apachen in Verbindung mit neuen default settings entstand, müsste da weiterhin seitens phpBB was unternommen werden.

LukeWCS hat geschrieben: 17.07.2024 12:18 Im Moment ist mir das auch noch nebulös. Mir ist z.B. nicht klar, ob der "böse" Code generell bei URLs greift, oder nur dann, wenn der böse Code in einer RewriteRule vorhanden ist. Dazu fand ich widersprüchliche Aussagen bei meiner Recherche.

Der Fehler trat generell auf. Du konntest einfach irgendwo in den Querystring eines beliebigen URLs ein %3f reinschreiben und der 403-Fehler kam.

Staendike hat geschrieben: 18.07.2024 03:59 Was Strato da gemacht hat, weiß ich nicht.

Ja, wäre schön wenn man erfahren würde, was genau das Problem ist/war.

Eisrose hat geschrieben: 18.07.2024 17:47 Achso: Ich habe das hier bereits in den Bug Tracker eingetragen, mit der Vermutung, dass das alles so stimmt, was ich hier schreibe. Bitte korrigiert mich, wenn dem nicht so ist.

Sieht für mich gut aus, das entspricht den bisherigen Erkenntnissen. Aber noch ist nicht klar, ob das überhaupt ein generelles Apache Problem ist. Ich hoffe das ist nur auf Strato begrenzt, ansonsten wird das lustig, weil da eine ganze Menge geändert werden müsste. Das könnte dann ebenso Ext Coder betreffen. Denn zur URL Kodierung werden PHP Funktionen genutzt und diese sind allesamt nicht anpassbar, um z.B. das %3f Problem anderweitig lösen zu können.

Eisrose hat geschrieben: 18.07.2024 18:58 Was mir jetzt noch unklar bleibt, ist, ob Strato einfach das UnsafeAllow3F-Flag gesetzt hat oder ob das ein Fehler beim Update des Apachen bei Strato war.

Diese Frage habe ich mir auch bereits gestellt. Das Problem ist, seit 69bruno das hier gemeldet hat, versuche ich meine lokale Testumgebung mit phpBB 3.3.12 und Apache 2.4.61 so zu präparieren, dass ich dieses Problem reproduzieren kann. Ist mir bisher allerdings nicht gelungen. Also entweder mir fehlt noch eine Info oder Einstellung oder Komponente oder alle drei ^^, oder aber das ist wirklich auf Strato begrenzt.

Eisrose hat geschrieben: 18.07.2024 18:58 Der Fehler trat generell auf. Du konntest einfach irgendwo in den Querystring eines beliebigen URLs ein %3f reinschreiben und der 403-Fehler kam.

Ahja sehr schön, eine solche klare Aussage hat mir bisher gefehlt. Merci. Und das würde auch einwandfrei mit dem zusammen passen, was chris1278 hier beschrieben hat.

Jut, das Thema ModSecurity (meine Vermutung) ist somit eher vom Tisch, hab die Infobox im Startbeitrag und den Titel angepasst.