[Frage] Blockaden durch Cloudflare?

[PeterPawn]

Ich habe es gerade wieder erleben müssen, daß Cloudflare das Absenden einer Antwort blockierte ... und das ist für den normalen Benutzer kaum mehr zu erkennen, denn die Anzeige gibt da praktisch gar nichts her:

und selbst mit ein paar Netzwerk-Kenntnissen ausgerüstet (zumindest mit entsprechendem "gefühlten Wissen"), muß man erst eine Weile suchen, bis man die Ursache dafür gefunden hat:

        Sorry, you have been blocked
You are unable to access ip-phone-forum.de
 
                       
   
            Why have I been blocked?
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
       
            What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

Da denke ich mir doch, ich folge einfach mal der Empfehlung "You can email" und frage hier nach ... per E-Mail ist es ja eher schwierig (es gibt keine Adresse, kein Impressum, etc.) und da die von mir zumindest versuchte Antwort auch nichts Geheimes beinhaltet, kann sie ja wunderbar als Vorlage für eine Erklärung (seitens des Betreibers, ggf. nach Nachfrage bei Cloudflare) dienen, WAS GENAU denn nun an dem Text diese Entscheidung getriggert hat.

Es ging dabei um eine Antwort, die genau den Text enthielt, den ich hier: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2361616 über einen Link zu meinem eigenen Server eingefügt habe.

Selbst wenn da irgendwelche Zeichen enthalten sein sollten, die vom Betreiber (bzw. dessen Admin, der hier immer synonym angesprochen sein möge) als "unerwünscht" gekennzeichnet wurden (das ist eine Frage von Einstellungen), sollte der verwendete Javascript-Code auf der Client-Seite (wenn man den schon zulassen MUSS, sofern man vernünftig arbeiten will) ja wohl in der Lage sein, diese Zeichen bereits passend zu maskieren.

======================================================================================

Das ist daher auch nur ein Beispiel ... es passiert mir in letzter Zeit desöfteren (an anderer Stelle habe ich das auch vor kurzem mal angemerkt, da noch ohne eine genauere Untersuchung der Zusammenhänge) und ich werde definitiv nicht jedes Mal (bzw. genauer: kein weiteres Mal) versuchen, eine inhaltliche Antwort trotzdem noch "zuzustellen" - ebenso habe ich gar keinen Bock selbst zu ermitteln, woran sich Cloudflare nun konkret stört; ich tippe einfach mal, daß da jemand vor nicht allzu langer Zeit (1-2 Monate) Einstellungen geändert hat und das nicht ausreichend getestet wurde (oder der Schwund wird dann doch - schulterzuckend - akzeptiert ... aber auch dann sollten die Benutzer vielleicht informiert werden, was genau denn nun KRITISCH ist und daher zu vermeiden wäre).

Daß dieser Service ohnehin nicht ausschließlich vorteilhaft ist, ist auch ein offenes Geheimnis ... zwar kann man das Bestreben eines Site-Betreibers, sich gegen DoS-Angriffe zu wappnen, noch verstehen, aber das "Delegieren" von Security an eine US-amerikanische Firma, wobei die eine solche Aufgabe eben nur wahrnehmen kann, wenn sie tatsächlich ALLE INHALTE untersucht (die sie dazu natürlich auch erst einmal erhalten muß - was natürlich (mangels Datenschutzerklärung) auch komplett im Dunklen bleibt), ist durchaus "Ansichtssache" und da alle Zugriffe ja VERMEINTLICH auf die Domain "ip-phone-forum.de" erfolgen (im Prinzip arbeitet Cloudflare hier ebenso, wie ein Angreifer bei einem MITM-Szenario, wenn auch auf ausdrücklichen, aber häufig doch einseitigen Wunsch des Betreibers), kann das der Benutzer eigentlich auch nicht erkennen (außer er analysiert tatsächlich den Netzwerkverkehr und verläßt sich nicht nur auf das, was man ihm im Browser vorgaukelt).

Damit wird dann eben Cloudflare zum direkten Google-Rivalen ("don't be evil") und die schlagen sich am Ende darum, wer mehr intime Kenntnisse über die jeweiligen Nutzer sammeln kann ... das geht bei DNS-Servern los und endet bei ausgedehnten Traffic-Analysen - zumindest zwischen den Benutzern und den Sites, die sich dieses Services bedienen.

Man gibt also schon als IPPF-Benutzer einiges an Daten (ohne es direkt zu erfahren) an einen der großen US-amerikanischen Datensammler (deren Zentrale ist in SF, CA) ... da kann man m.E. dann aber auch erwarten, daß diejenigen, die eine Entscheidung für dessen Nutzung getroffen haben, die Konfiguration von Service und eigener Website - auch und gerade in der Kombination aus beidem - im Griff haben. Ansonsten löst sich auch hier so mancher Beitrag schneller wieder in Luft auf, als es der Autor eigentlich anstrebte.

 

[Novize]

Ich vermisse schmerzlich ein tl;dr

Warum dieser Fehler, in Deinen Augen das „Blockieren“ eines Beitrags, zum nachträglichen Löschen irgendwelcher Beiträge führen soll, erkläre mal bitte in kurzen Worten. Thx

 

[weißnix_]

Ansonsten löst sich auch hier so mancher Beitrag schneller wieder in Luft auf, als es der Autor eigentlich anstrebte.

Für den Mod mag ein Beitrag erst existieren, wenn er vom Server aktzeptiert und im Forum sichtbar ist.
Für einen Beitragenden existiert ein Beitrag ab dem niedergeschriebenen Wort.

 

[PeterPawn]

erkläre mal bitte in kurzen Worten.

Wo steht da in dem von mir Geschriebenen etwas von nachträglichem Löschen? Ich finde dafür - mittels lokaler Textsuche im Browser - keine Anhaltspunkte.

Wenn sich das auf meinen letzten Satz beziehen sollte ... da hatte ich eher den Umstand im Auge, daß man nach dem Absenden eines neuen Beitrags in einem Browser-Tab schon sehr genau hinsehen muß, ob dieser Beitrag auch tatsächlich erfolgreich gespeichert wurde (das erfolgt ja auch nicht immer im "Handumdrehen", zumindest nicht bei etwas ausführlicheren Beiträgen, da kommt dann erst mal ein "spinner" oben rechts in der Seite).

Da dasselbe Problem mit Cloudflare auch beim automatischen Sichern von Entwürfen auftritt, kann man sich auch nicht darauf verlassen, daß bisher geschriebene Beiträge am Ende schon nicht verloren gehen, weil sie - während des Schreibens - immer mal wieder auf den Server übertragen werden.

Kurz genug ... oder sollte ich mich auf den ausschließlichen Gebrauch von Hauptsätzen beschränken? Angesichts von Aussagen in früheren "Unterhaltungen" bringt mich nämlich auch ein "Zwinkern" nicht wirklich selbst zum Schmunzeln.

PS:

in Deinen Augen das „Blockieren“ eines Beitrags

Na ja ... das mit "meinen Augen" ist halt auch so eine Sache. Wenn man sich den von Cloudflare verwendeten Text in der Response ansieht, ist eine Formulierung "in Deinen Augen" aber auch leicht mißzuverstehen - jedoch wollen wir ja gar nicht zwischen den Zeilen lesen.

 

[GT2RS]

Hallo PeterPawn,

Ich bin mir sicher, dass du verstehst, dass diese Funktionen dazu dienen, Nutzern zusätzliche Sicherheit zu bieten und nicht dazu, ihnen das Leben schwer zu machen. Viele der Funktionen wurden tatsächlich deaktiviert oder angepasst, um Probleme zu vermeiden, die in der technischen Natur dieses Forum gründen. Wir können jedoch nicht alles deaktivieren. Es muss ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit bestehen. Ich glaube, dass dies größtenteils erreicht worden ist. Wenn man nicht gerade versucht, eine Regel für böswillige Zwecke zu umgehen, gibt es viele Möglichkeiten, einen Beitrag zu schreiben, ohne blockiert zu werden. (Sicherlich weißt du das bereits).

Wir werden keine der bestehenden Regeln ändern, es sei denn, es betrifft eine große Anzahl von Benutzern oder es ist absolut notwendig.

Was wir tun können, ist, die Fehlermeldung so zu ändern, dass diese ausdrücklich darauf hinweist, dass der Beitrag durch Cloudflare blockiert wurde. Du hast Recht bezüglich der Wahrscheinlichkeit, dass in solchen Fällen Entwürfe verloren gehen. Wir werden auch das prüfen und gegebenenfalls Maßnahmen ergreifen.

 

[PeterPawn]

Ich wüßte zugegebenermaßen schon gerne, was konkret in dem Text denn nun die Aktion von Cloudflare triggert ... der Text steht ja unter dem Link in dem Beitrag, auf den ich in #1 verweise, zur Verfügung und Cloudflare ordnet solchen Blockaden ja eine eindeutige ID zu (die per Kontaktformular auch von mir übermittelt wurde) und mit der sollte man ermitteln können, was GENAU nun zur Blockade führte.

Denn ich kann nichts anders formulieren, wenn ich gar nicht weiß, was hier der Trigger ist ... das ist es auch, was ich in #1 mit

ebenso habe ich gar keinen Bock selbst zu ermitteln, woran sich Cloudflare nun konkret stört

zum Ausdruck bringen wollte. Der Beitrag besteht aus 613 X Worten (ohne Leerzeilen, Zitat, angedeuteten "ruler" und das eingebettete Bild) und selbst mit binärer Suche (also dem Zerlegen des Textes in zwei Hälften und dem Test, welche dieser Hälften weiterhin abgelehnt wird ... das wird dann mit der betroffenen Hälfte so lange fortgesetzt, bis man den eigentlichen Auslöser gefunden hat) ist das noch "richtig Arbeit", die man im Cloudflare-Dashboard deutlich leichter erledigen können sollte.

Und ja ... es wäre günstig, wenn der XHR in JS bei HTTP-Error 403 explizit noch einmal prüft, ob es sich um eine Blockade durch Cloudflare handelt (der zurückgelieferte HTML-Body ist ja ziemlich eindeutig, wobei schon die Suche nach Text-Teilen mit RegEx reichen sollte) und dann eine entsprechende "Handlungsempfehlung" gibt. Denn auch ich (der ich um die Problematik bereits wußte) habe erst nach einigen Anläufen und eigener Untersuchung der Ursache bemerkt, daß es gar nicht an einer (ggf. auch nur temporären) "Nichtverfügbarkeit" der Site lag oder liegt, wenn dieses "Oops" kommt.

Hier hatte ich das zuvor mal "angemerkt" und es noch auf eine andere Ursache geschoben: https://www.ip-phone-forum.de/threads/7590-in-bootschleife.306149/post-2360971 - es wäre sogar denkbar, daß es da tatsächlich auch eine andere Ursache war, denn der am Ende gesendete und akzeptierte Text stand genauso - über die dort erwähnten 20 Minuten - in einem geöffneten Browser-Tab herum und ließ sich letzten Endes dann doch senden - nur die erste Zeile kam da noch hinzu.

Es passiert (zumindest mir) in letzter Zeit (1-2 Monate) eben auch desöfteren, daß Zugriffe auf diese Site mit "Timeout" abbrechen oder daß DNS-Abfragen (über eine eigene Resolver-Kaskade, die am Ende "an die Quelle" geht - also an die "authorized name servers" für die Domain und das sind hier ja dann auch die von Cloudflare) nicht sinnvoll beantwortet werden, zumindest nicht in passenden Zeiträumen (und das alles noch zu einer Zeit, wo "home office" in großem Maßstab noch nicht wirklich das Problem sein kann, höchstens in CN).

Das ist dann halt auch einer der Nachteile, die man sich mit einem solchen Service eintritt ... wenn der nicht "alles steuern" kann, funktioniert er nicht richtig und jede Überlastung dieses Services, die durch bzw. für andere Sites anfällt, beeinflußt dann auch die Verfügbarkeit/Erreichbarkeit der eigenen Site.

Um das noch einmal zu verdeutlichen ... ich habe zwar eigene Vorbehalte gegen Cloudflare und deren Datensammelwut, aber ich akzeptiere/verstehe auch (zumindest partiell), wenn jemand sich solche Dienste "einkauft". Das war/ist mir auch schon länger bewußt (daß CF hier verwendet wird) und ich schreibe hier trotzdem weiterhin. Aber wenn dann deren Filter offensichtlich soo schlecht programmiert sind oder der von dieser Site bereitgestellte JS-Code so schlecht mit dieser Filterung (und den konkreten Einstellungen für dieses Board) zusammenwirkt, dann sollte man tätig werden ... exakt das ist es auch, was ich mit dem Thread erreichen wollte.

EDIT: Die Zahl 613 oben war ein Irrtum meinerseits ... das ist die Anzahl der Worte in #1 in diesem Thread und wurde schon gestern von mir ermittelt, als der Wunsch nach einer "synopsis" an mich herangetragen wurde.

 

[GT2RS]

Hi PeterPawn,

ich glaube, es ist offensichtlich, was den Block in deinem Text ausgelöst hat (auch Cloudflare bestätigt dies): das <script>-Tag.

Du brauchst keine Nachforschungen anzustellen und/oder deine Zeit zu verschwenden. Sollte ein Problem/Fehler auftreten, dann lass es uns einfach wissen, und wir werden (in den meisten Fällen) leicht feststellen können, wo die Ursache liegt, und beurteilen, ob irgendwelche Maßnahmen ergriffen werden sollten.

Wir wissen um die Vor- und Nachteile eines solchen Dienstes und sind der Meinung, dass die Vorteile gegenüber den Nachteilen überwiegen.

Wie bereit gesagt kann ein Benutzer in den meisten, wenn nicht sogar in allen Fällen seinen Beitrag so anpassen, dass er die Sicherheitsprüfung besteht.

 

[PeterPawn]

es ist offensichtlich, was den Block in deinem Text ausgelöst hat (auch Cloudflare bestätigt dies): das ...-Tag

Ich finde das gar nicht so offensichtlich - ja, ich habe es nicht einmal wirklich bemerkt, daß mein Beispiel für einen Aufruf per Kommandozeile (obendrein in einem ICODE-Block) am Ende zu einem HTML-Tag im Text führte - auch dank der fehlenden Möglichkeiten, innerhalb eines solchen Blocks weitere Textauszeichnungen zu verwenden und damit zu markieren, welche Teile dieses Aufrufs vom Verwender durch seine eigenen Werte zu ersetzen wären, denn das von mir benutzte Umschließen mit "spitzen Klammern" ist dafür ein durchaus übliches Vorgehen, sofern anderes, wie kursiv oder invers oder unterstrichen, nicht verfügbar ist.

Zwar gibt es inzwischen wieder die Möglichkeit, "monospaced text" irgendwie zu kolorieren (als "[CODE=rich]"), aber auch das mußte man erst selbst wieder erkunden. Entsprechende Bitten und Beiträge blieben schlicht unbeantwortet und irgendwann ging es dann nach einem Update plötzlich doch wieder, wenn auch anders, als zuvor unter vBulletin, was immer noch jede Menge Beiträge mit entsprechenden Beispielen praktisch nutzlos macht, wenn deren Leser es nicht verstehen, daß diese Tags (die auch nicht ausgefiltert wurden/werden) gar nicht wirklich zum entsprechenden Beispiel gehören, sondern nur Artefakte nach der Umstellung auf Xenforo sind, während da zuvor entsprechende Hervorhebungen durch Farben und/oder anderen Schriftstil zu lesen waren.

Aber da Du wohl recht hast mit Deiner Feststellung hinsichtlich dieses "tags" (die Tatsache, daß ich den Part nicht mal zitieren kann, spricht schon sehr dafür), sollte man immer noch per JS dafür sorgen, daß solche Worte VOR dem Versand zum Speichern entsprechend kodiert werden.

Ich verstehe, daß es sinnvoll ist, solche Tags aus Beiträgen zu "entschärfen" (schon damit darüber keine Code-Injection in Seiten anderer Leser erfolgen kann - ich wäre einer der Ersten, der das kritisieren würde, selbst wenn ich per se erst mal überall mit NoScript-AddOn unterwegs bin), aber das geht definitv auch anders.

Das wird dann eben als HTML-Entity "maskiert" und nicht als Text übermittelt ... genau dafür gibt es solche Standards ja (u.a.) auch, wie z.B. diesen hier: https://www.w3.org/TR/html4/sgml/entities.html - nur kann das der Benutzer/Verwender seinerseits gar nicht machen, weil da dann tatsächlich wieder das HTML-Encoding, was bereits durchgeführt wird, zuschlägt und dafür sorgt, daß "von Hand" umgewandelte Zeichen auch tatsächlich wieder 1:1 als ebendiese Umwandlung ausgegeben werden (und erst recht innerhalb anderer BBCode-Tags). Wenn ich meinerseits da ein "&gt;" schreibe, landet das auch genau so in der Anzeige bei anderen Lesern, weil das Ampersand an der ersten Stelle noch einmal als & kodiert wird.

Wer den hier offenbar greifenden Trigger als sinnvolle Filterung ansieht und ansonsten der Meinung ist, die Leute sollten dann einfach ihre Beiträge anders abfassen, der macht es sich - nach meiner Ansicht jedenfalls - zu leicht.

Das Problem, die Meta-Character einer Sprache (und das "less-than sign" bzw. das "greater-than sign" um das HTML-Keyword sind hier eben solche) auch irgendwie so zu kodieren, daß sie ihre Bedeutung verlieren, hat jede Definition einer "Computersprache" (bis hin zum Shell-Code und regulären Ausdrücken - dort verwendet man i.d.R. den "backslash" als "escape character") und die schaffen es üblicherweise durch entsprechende Standards dann auch. Nur muß man diese Standards dann halt auch anwenden, d.h. hier, man muß sie implementieren (ggf. auch lassen, wenn man es selbst nicht stemmen kann oder will).

Denn wenn man weiß, daß es - auf dem Weg zum Server - noch entsprechende Prüfungen gibt, dann darf/kann man eben nicht nur, wie bisher, auf dem eigenen Server eine solche Filterliste noch parallel führen und sich darauf verlassen, daß diese dann solche Konstrukte schon entschärfen wird (das war bei vBulletin der Fall und ist es bei Xenforo auch - es muß nämlich auch eine Lösung für die Xenforo-Boards geben, die sich nicht auf CF verlassen (wollen), denn auch diese wollen ihren Benutzern keine "echten" Skripte in die Seiten injizieren), sondern dann muß man sich auch darum kümmern, daß der zu sendende Inhalt schon im Browser des Benutzers so kodiert wird (entity encoding), daß er - wenn er solche Konstrukte eben als "normalen Text" enthält und nicht als "Anweisung" für die darüber (oder darunter, je nach Ansicht) liegende (HTML-)Schicht - den zusätzlichen, vom Betreiber dazwischen geschalteten, Filter trotzdem noch passieren kann. Alles andere ist - in meinen Augen - für ein Board mit diesem Charakter unpraktikabel.

Denn witzigerweise läßt natürlich CF den Request auch passieren, wenn ich meinerseits das Ganze als:

>script<

schreibe ... nur wandelt dann offensichtlich der Xenforo-Parser diese Konstruktion seinerseits noch einmal um und macht daraus - für die Anzeige im Browser - folgendes:

>script<

Das Problem ist es hier also, daß da eine zweifache Kodierung der HTML-Entities erfolgt. Damit steht man vor dem Problem, daß der "unencoded content" mit den richtigen Tags den CF-Filter nicht passieren kann und der "encoded content" (wenn man das von Hand ausführt), vom Xenforo-Parser noch einmal umgewandelt wird. Wie man das Problem jetzt als Betreiber in den Griff kriegt, bleibt natürlich jedem selbst überlassen ... aber es ist ja auch ein "offenes Geheimnis", daß man im Zusammenhang mit dem Einsatz von CF vor einer Xenforo-Installation auch ein paar eigene Vorkehrungen treffen muß (https://support.cloudflare.com/hc/en-us/articles/202034110-Using-Cloudflare-with-Xenforo-forums) und auch wenn das Problem solcher HTML-Entities in diesem "Ratgeber" von CF nicht explizit angesprochen wird, besteht es ja offensichtlich. Ich frage mich hier halt, warum man einen CF-Filter auf das HTML-Tag für Skript-Code legen muß, wenn doch bereits der Xenforo-Parser entsprechende Vorkehrungen enthält, solche Tags durch Entity-Encoding zu entschärfen. Eine "second line of defense" ist zwar auch nicht zu verachten, aber in meinen Augen spätestens dann Unsinn, wenn sie mit der ersten nicht sauber zusammenarbeiten kann.

Dann muß eben der JS-Code vor dem Absenden des XHR noch den Inhalt prüfen und - im Minimum - den Benutzer auf die "kritische Stelle" hinweisen ... wobei man dann eben auch gleich hingehen und diese durch die passenden HTML-Entities ersetzen kann. Dann muß man nur noch dafür sorgen, daß der Xenforo-Parser die solchermaßen schon auf der Client-Seite geänderten Daten nicht ein zweites Mal umwandelt. Der Benutzer kann da jedenfalls - derzeit - gar nichts wirklich beeinflussen ... höchstens auf die Verwendung von "kritischen Konstrukten" verzichten und das ist schon einigermaßen schwierig, wenn er gar nicht genau weiß, welche Konstrukte denn nun dazugehören sollen. Und das will man als Betreiber ja nun auch wieder nicht offenlegen (kann ich wieder nachvollziehen), weil man damit auch die verbleibenden Lücken in den Filtern aufzeigen würde.

Ich kann zwar jetzt den Inhalt dieses konkreten Beitrags tatsächlich ändern, aber das gilt noch lange nicht für jeden anderen, zukünftigen, der da noch zu schreiben wäre und für jeden erdenklichen Filter, den da jemand über die WAF-Rules von CF installiert haben mag. Denn man merkt es ja gar nicht immer selbst (siehe oben), wo exakt nun das Problem liegt und wenn ich mich jedesmal bei einem solchen Problem (mit <sсript> wird mir das sicherlich nicht erneut passieren, weil ich dann nach dessen Vorkommen im Text suchen würde) erst an den Betreiber wenden soll, um den konkreten Trigger zu erfahren, sprechen auch da wieder die Reaktionszeiten (angefangen beim Wochenende) und der erforderliche "good will" für mich dagegen, das als "normalen Ablauf", der halt nicht anders machbar wäre, zu akzeptieren. Wenn man CF dazwischen schaltet, muß/sollte man auch dafür sorgen, daß sich an der Handhabung für die Nutzer nichts ändert ... bzw. eher etwas verbessert, aber nicht verschlechtert.

 

[koyaanisqatsi]

Moinsen


Filter
Lustig, weil ich gerade ein CGI Skript schreibe welches den Sourcecode in <pre/> Tags leserlich ausgeben soll.
Ohne "Sonderbehandlung" werden jedoch die im Skript vorkommenden HTML Tags ( Elemente ) dummerweise auch in HTML "transformiert", bzw. ausgegeben.
Die REXX Function die das korrigieren soll...

/* Function returning source code */
code:
LF='0A'x
sl=''
do j = 1 by 1 to  sourceline(); sl=sl''sourceline(j)''LF; end
sl=changestr('<',sl,'&lt;')
sl=changestr('>',sl,'&gt;')
return sl

...schafft es schon fast.
Allerdings ist das < und > auch ein beliebter Vergleichsoperator
...aber jetzt weiss ich wenigstens wie Bugs entstehen.
Und, da muss ich PeterPawn bedingungslos zustimmen, das & am End nochmal nach &amp; zu wandeln, machts noch viel schlimmer.
In REXX wäre das...

/* Function returning source code */
code:
LF='0A'x
sl=''
do j = 1 by 1 to  sourceline(); sl=sl''sourceline(j)''LF; end
sl=changestr('<',sl,'&lt;')
sl=changestr('>',sl,'&gt;')
sl=changestr('&',sl,'&amp;&')
return sl

...und die <pre/> Ausgabe...


Na, da kann ich die Programmierer bei Cloudflare schon verstehen
Blocken ist einfacher

...und bevor sich hier Einer über meine REXX Affinität echauffiert, ick kann auch supermodern, hier mein ultimativer Onlinechecker...

...erzeugter Sourcecode als Textausgabe, einfach in der Adresszeile das type/html entfernen, ergibt...

...gibts auch in hübscher Base64 Kodierung.