Sonntag 08. April 2018

Ein kleines Phänomen ist mir vorgestern hier im Backend aufgefallen. Ich hatte ja letztens erwähnt (oder auch nicht), dass ich aus irgendeinem Grund ein paar Probleme mit der Eingabe von Texten hier im Blog habe. Das Ganze läuft ja über eine simple HTML-Form-Eingabe in eine Textbox und anschließender Übergabe an eine primitive, kleine 2-Zeiler-PHP-Datei, die nichts Anderes tut, als eine Textdatei mit Datumsstempel als Name und Titel zu generieren und den Text beifügt. Ausgabe erfolgt komplett abgetrennt und unabhängig von der Eingabe via CGI.

Formatiert wird das Ganze mit Markdown und - leider - manuellen Umbrüchen, aber die auch nur deswegen, weil die historisch entstanden und die alten Texte damit reihenweise bereits durchzogen sind, also habe ich es dabei belassen. Schon ok.

Auf jeden Fall kommt es seit Kurzem nun immer wieder vor, dass die Datei nicht erstellt werden kann und ich eine Schreibberechtigungs-Fehlermeldung bewundern darf und erst bei einem der letzten Texte ist mir zufällig aufgefallen beziehungsweise bewusst geworden, dass es mit der Länge des Inhaltes zu tun hat. Also mal die Logfiles des Servers anschauen.

Und wurde eines Besseren belehrt. Denn dort findet sich bei einem der Versuche einen Eintrag zu erstellen, eine Apache-Fehlermeldung, die dann weiter zu einer Ergänzung leitet:

"ModSecurity: Access denied with code 403 (phase 2)"

Aha, interessant. Mal wieder was Neues gesehen, also gleich mal weiterschauen:

"Match of rx (blablala-Code hier an dieser Stelle, wo ich nicht genau auslesen kann gerade, was es genau betrifft) against ARGS:eintrag required. Protected by Atomicorp.com Basic Non-Realtime WAF Rules: Potentially Untrusted Web Content Detected."

Soso, also liegt es nicht an der Länge, sondern scheinbar an irgendeiner Formatierung, die dann bei einer Regel von ModSecurity zuschlägt.

Das Seltsame aber ist, dass ich keinen wirklichen Grund finden kann, denn die Formatierung und Aufbau meines Inhaltes beschränkt sich auf Fett, Kursiv, Links und Umbrüche. Mehr gibt es hier nicht und auch wenn ich alles der Schnelligkeit wegen sowieso händisch mal eben runterklopfe, passieren mir da recht selten Fehler, abgesehen von den klassischen Schreib- und Sinnfehlern aus Schlampigkeit meinerseits oder weil mein Kopf oftmals schon vier Absätze weiter ist.

Für einen False Positive ist mir das Ganze aber zu auffällig und auch wenn ich die Möglichkeit habe, einfach die Regel-ID zu deaktivieren bzw. auszutaggen, gefällt mir das natürlich nicht. Solche Lösungen mag ich generell nicht. Mh. Kopfkratz. Die ModSecurity Meldung bezieht sich auf den Regelsatz mit der ID 350147, aber außer, dass man es einfach deaktivieren soll, finde ich nichts Sinnvolles im Netz dazu oder bin einfach anscheinend blind gerade.

Nachtrag: Aha, spannend. Bin gerade dem Fehler ein wenig mehr auf die Spur gekommen und zwar durch den Text hier selber. Abermals konnte ich ihn anfänglich nicht posten. Also mal alle Formatierungszeichen rausgenommen, wie Sternchen, Anführungszeichen und so weiter... gleicher Fehler. Dann die Umbrüche weg und siehe da: es ging. Also liegt es anscheinend an irgendeiner Kombination der Zeilenumbrüche, die mit einem klassischen Spitze-Klammer-Auf und -Zu sowie BR erstellt werden. Ist die Datei aber mal erstellt, dann kann ich sehr wohl auch unendlich viele Kombinationen nachträglich in die Textdatei via Backend klatschen, also schlägt die Filterregel nur beim Erstellen der Datei zu.

Jetzt muss ich noch rausfinden, ob es an der Anzahl der Umbrüche oder einer zugehörigen Formatierung liegt. Vielleicht wäre es auch der passende Zeitpunkt, um mal eine andere Lösung einzubinden und auf die händische Eingabe zu verzichten - was es natürlich angenehmer machen würde, aber dann würde ich die 1980+ Textdateien auch gleich alle durch ein Replace durchlaufen lassen. Mmmmmhhhhh.

Nachtrag: Noch mehr rausgefunden... wenn ich einen neuen Eintrag nur mit einem Umbruch erstelle: kein Problem. Erstelle ich einen mit zwei Umbrüchen: auch kein Problem. Erstelle ich aber einen mit zwei Umbrüchen und dann ein Leerzeichen danach, dann kommt es zu dem Fehler. Mal schauen, ob und wie ich das bei zukünftigen Einträgen einfach umschiffen kann, denn eigentlich mag ich ja restriktive Sicherheit am Server. Ansonsten kümmere ich mich wirklich mal um eine andere Formatierung... \o/