[FINAL] [CDB][3.3] Spamsecure

In diesem Forum können Extension-Autoren ihre Extensions vorstellen, die sich noch im Entwicklungsstatus befinden. Der Einbau in Foren im produktiven Betrieb wird nicht empfohlen.
Benutzeravatar
chris1278
Mitglied
Beiträge: 3526
Registriert: 12.11.2007 06:20
Wohnort: Euskirchen
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von chris1278 »

Es dauert nicht mehr lange. So wie es aussieht sind nur noch ein paar Feinabstimmungen notwendig und dann werden wir das nächste update freigeben.
Benutzeravatar
LukeWCS
Supporter
Supporter
Beiträge: 2091
Registriert: 15.12.2014 10:19
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von LukeWCS »

Auch mal hier kommentieren, damit man Zitate direkt nutzen kann. Bruno hatte inzwischen im WWH Forum die gleichen Schlüsse gezogen wie ich und ich zeige hier lediglich warum das Problem überhaupt existiert, sprich eine kleine Analyse der Ursache.
guenniguenzelsen hat geschrieben: 09.04.2022 11:16 Eintrag bei nicht erlaubten Zeichen (um Russenspam außen vor zu halten): бфяДжлпдИиЧ

Diese Zeichen werden dann ebenfalls als nicht erlaubte Zeichen erkannt, beim Versuch einen Text zu veröffentlichen:
Ä (nur als Großbuchstabe)
ö (nur als Kleinbuchstabe)
Die Ursache für das Problem ist die Funktion strpbrk(), diese ist auf singlebyte Operation ausgelegt und kann nicht mit multibyte umgehen. Um das Problem zu verstehen, habe ich sowohl den String mit den unerlaubten Zeichen als auch einen Testbeitrag in ihre Bestandteile, sprich ASCII Codes zerlegt:

$searchchars ist dabei das, was guenniguenzelsen hier geschrieben hat.
$message besteht lediglich aus dem Text "äöü", mehr nicht.

Code: Alles auswählen

$message:
listener.php:75:string 'äöü' (length=6)
listener.php:78:string 'ä' (length=2)
listener.php:79:int 195
listener.php:80:int 164
listener.php:78:string 'ö' (length=2)
listener.php:79:int 195
listener.php:80:int 182
listener.php:78:string 'ü' (length=2)
listener.php:79:int 195
listener.php:80:int 188
$searchchars:
listener.php:84:string 'бфяДжлпдИиЧ' (length=22)
listener.php:87:string 'б' (length=2)
listener.php:88:int 208
listener.php:89:int 177
listener.php:87:string 'ф' (length=2)
listener.php:88:int 209
listener.php:89:int 132
listener.php:87:string 'я' (length=2)
listener.php:88:int 209
listener.php:89:int 143
listener.php:87:string 'Д' (length=2)
listener.php:88:int 208
listener.php:89:int 148
listener.php:87:string 'ж' (length=2)
listener.php:88:int 208
listener.php:89:int 182
listener.php:87:string 'л' (length=2)
listener.php:88:int 208
listener.php:89:int 187
listener.php:87:string 'п' (length=2)
listener.php:88:int 208
listener.php:89:int 191
listener.php:87:string 'д' (length=2)
listener.php:88:int 208
listener.php:89:int 180
listener.php:87:string 'И' (length=2)
listener.php:88:int 208
listener.php:89:int 152
listener.php:87:string 'и' (length=2)
listener.php:88:int 208
listener.php:89:int 184
listener.php:87:string 'Ч' (length=2)
listener.php:88:int 208
listener.php:89:int 167
Die Problem-Kombination in diesem Fall ist der Umlaut "ö" und das kyrillische Zeichen "ж". Da strpbrk() Byte für Byte arbeitet und keine UTF8 Kodierten Zeichen verarbeiten kann, kommt es zu einer Übereinstimmung bei "ö" als "unerlaubtes" Zeichen, weil dessen zweites Byte exakt den gleichen ASCII Code hat wie das zweite Byte eines der gesperrten Zeichen, nämlich 182.

Deswegen nochmal ein Konzentrat der obigen Debug Ausgabe, damit man das direkt sehen kann:

Code: Alles auswählen

$message:
listener.php:75:string 'äöü' (length=6)
listener.php:78:string 'ö' (length=2)
listener.php:79:int 195
listener.php:80:int 182
$searchchars:
listener.php:84:string 'бфяДжлпдИиЧ' (length=22)
listener.php:87:string 'ж' (length=2)
listener.php:88:int 208
listener.php:89:int 182
Das gleiche grundsätzliche Problem gilt dann natürlich auch für die anderen gemeldeten false-positives wie z.B. "Ä" und "§".
Möge das Backup mit dir sein. Immer.

Erweiterungen - Infos zur artgerechten Haltung
phpBB Ext Check - Analysesystem für phpBB Erweiterungen (Entwickler Werkzeug)
69bruno
Mitglied
Beiträge: 444
Registriert: 05.06.2020 08:21

Re: [DEV] [3.3] Spamsecure

Beitrag von 69bruno »

Danke für die Analyse, ich hatte mir das "gedacht", aber noch nicht nachweisbar analysiert.

Das macht auch meinen Lösungsansatz für die Ext hinfällig, da bei meinen Tests durch die Umwandlung der Umlaute/Sonderzeichen zwar keine Zeichen mehr ungewollt gesperrt wurden, dies aber ein reiner Zufallstreffer war. Beim nächsten Multibytezeichen, welches im ACP als unerlaubt eingetragen wird und dessen 2. oder 3. byte einem Singlebytezeichen im deutsch-/englischsprachigen Zeichensatz entspräche, wäre wieder ein Zeichen weg :roll:

Also muss ich mir ansehen, wie ich die multibyte-Zeichen abfange und entferne. Dann dient die Ext nur dazu, singlebyte-Zeichensätze zu unterbinden(Womit mein Ziel - ganze Sprach-Zeichensätze zu unterbinden wahrscheinlich trotzdem erreicht würde)
Forum: cruiser-lounge.de
PHPBB-Version: 3.3.11 / Debian-Linux 10 / PHP-Version: 8.1
Benutzeravatar
T-Rex
Mitglied
Beiträge: 40
Registriert: 24.03.2019 20:56
Wohnort: Bonn (Legoland)
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von T-Rex »

Ich war mal so frei und hab mir euren Code mal angesehen. Nach 40 Jahren in der IT kann ich zumindest die meisten Scriptsprachen lesen und interpretieren.

Ich kann ein bisschen PHP scripten, es reicht für den Hausgebrauch und mit der Verarbeitung von Multibyte-Strings hab ich mich bisher nur theoretisch beschäftigt.

Deshalb würde ich meine Antwort auch eher als Diskussionsgrundlage für eure Lösungswege verstehen.

Würde statt strpbrk nicht besser mb_ereg_match Verwendung finden? Vielleicht reicht auch mb_ereg bzw. mb_eregi oder auch eine der mb_str Funktionen?

Jetzt

Code: Alles auswählen

if (strpbrk($message, $searchchars))
stattdessen

Code: Alles auswählen

If mb_ereg_match($searchchars, $message)
Bin nicht sicher, ob die Übergabeparameter an die Funktion in der korrekten Reihenfolge stehen. Es gibt auch noch einen dritten Parameter (Option), der darf aber NULL sein.
T-Rex, der IT-Dinosaurier (retired)

Ich bin /root, ich darf das!! :lol:

Benutzeravatar
chris1278
Mitglied
Beiträge: 3526
Registriert: 12.11.2007 06:20
Wohnort: Euskirchen
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von chris1278 »

Di funktion an sich wurde mittlerwqeile selber etwas umgebaut ob das ein lösungsansatz als alternative wäre muss sich bruno mal anschauen.
69bruno
Mitglied
Beiträge: 444
Registriert: 05.06.2020 08:21

Re: [DEV] [3.3] Spamsecure

Beitrag von 69bruno »

Danke für den Vorschlag, zur Zeit sind wir auf eine andere Funktion umgestiegen, die nur erfordert dass ein Trennzeichen zwischen den Zeichen/Zeichenketten eingegeben wird. Damit kann die Funktion auch verwendet werden, um bestimmte Zeichenketten und nicht nur einzelne Zeichen auszuschließen.
Aber dazu mehr, wenn die Änderungen abgeschlossen sind.
Forum: cruiser-lounge.de
PHPBB-Version: 3.3.11 / Debian-Linux 10 / PHP-Version: 8.1
Benutzeravatar
chris1278
Mitglied
Beiträge: 3526
Registriert: 12.11.2007 06:20
Wohnort: Euskirchen
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von chris1278 »

So neue Version ist Online. Version 1.0.2

Wichtige Info

Bitte unbedingt vor Installation die Beschreibung im Startbeitrag nochmals durchlesen. Da sich die Extension Grundlegen verändert hat. Es ist dringend Empfohlen die Alte Extension vorher komplett zu deinstallieren.

Man kann zwar auch normal updaten aber dann müssen die Einstellungen komplett überprüft werden insbesondere die des Abschnittes für den Regex code.
Renix
Mitglied
Beiträge: 8
Registriert: 09.04.2022 12:53

Re: [DEV] [3.3] Spamsecure

Beitrag von Renix »

Einige Tage getestet, Überarbeitung ist gelungen, die russischen Spamer sind ausgesperrt.
Vielleicht mache ich etwas falsch, die Funktion wirkt bei allen Gruppen, unabhängig von den Rechteeinstellungen.
Aus meiner Sicht ist eine Rechtevergabe nach Gruppen auch nicht erforderlich.

Danke fürs teilen.
MfG.
Renix
Benutzeravatar
chris1278
Mitglied
Beiträge: 3526
Registriert: 12.11.2007 06:20
Wohnort: Euskirchen
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von chris1278 »

Renix hat geschrieben: 04.05.2022 19:16 Vielleicht mache ich etwas falsch, die Funktion wirkt bei allen Gruppen, unabhängig von den Rechteeinstellungen.
Das kann eigentlich nicht sein. Nach erstinstallation sollten keine Rechte gesetzt sein. Das heist da musst du mal prüfen ob die gruppen oder user da was falsch eingestelölt haben.

Wie schon gesagt wenn man die Extension installieret sind die berechtigungen noch nicht gesetzt.
Renix hat geschrieben: 04.05.2022 19:16 Aus meiner Sicht ist eine Rechtevergabe nach Gruppen auch nicht erforderlich.
Wenn man das nur für gäste nutzen will durchaus. Aber da die Ext doch ein wenig umfangreicher ist kann man die auch gezielter für andere Sachen einsetzen und somit ist eine Berechtigung für gruppen oder user durchaus sinnvoll. Aber man muss das ja nicht nutzen.
Benutzeravatar
T-Rex
Mitglied
Beiträge: 40
Registriert: 24.03.2019 20:56
Wohnort: Bonn (Legoland)
Kontaktdaten:

Re: [DEV] [3.3] Spamsecure

Beitrag von T-Rex »

Ich unterstütze den Betreiber eines Forums (Freie Motorradwerkstatt im 1Mann bzw. Meisterbetrieb) bei der Aktuellhaltung der Software des Forums und hab die Ext vor ein paar Tagen eingebaut.

Ich hab bei den Gruppen Bots, Gäste kürzlich registrierte Benutzer und registrierte Benutzer die Einstellung "Spamsecure-Einstellung: "Einstellungen für nicht erlaubte Zeichen/Zeichenketten" anwenden" auf ja gesetzt.

Das es nur 2 Admins (den Meister und mich) und keine Moderatoren gibt, hab ich an den Berechtigungen für diese 2 Gruppen erstmal keine Änderungen vorgenommen.

Bisher gab es auch noch keine Meldung von den Usern, dass sie auf Probleme durch diese Erweiterung gestoßen wären.

Danke Euch für die Entwicklung dieser Extension.
T-Rex, der IT-Dinosaurier (retired)

Ich bin /root, ich darf das!! :lol:

Antworten

Zurück zu „Extensions in Entwicklung“