Captachs in 0.8.5

[chrisbra]

Hi,
gestern abend habe ich das Update auf s9y 0.8.5 vollzogen. Hat wie immer reibungslos geklappt. Ein großes Lob.
Jedoch jetzt bekam ich eine Mail von einem Besucher meines Blogs, dass die Captachs nicht richtig funktionieren sollen. Er hat es 6 mal probiert und immer hat das Blog abgelehnt. Er benutzt FF1.5 und Safari auf Mac OSX.

ich hab auch gleich ein Testposting versucht, konnte das Problem aber nicht nachvollziehen. Gab es Änderungen an den Captchas im aktuellen Release? Mir ist aufgefallen, dass die Captachs jetzt doch schwieriger zu lesen sind.

Kann jemand das Problem nachvollziehen? Ich hab ein Testeintrag in meinem Blog gemacht, um das Problem reproduzieren zu können. Link ist http://blog.256bit.org/archives/141-Cap ... nicht.html

Ein kurzer Blick in die Tabelle spamblocklog ergab folgendes:
REJECTED | Captcha ungültig (Eingegeben: 2BHTU, Erwartet: )

Kann damit jemand was anfangen? Warum steht hinter erwartet nichts?

Mit freundlichen Grüßen

[garvinhicking]

Da wurde nichts geändert.

Das Problem kann auftreten wenn Dein Besucher in seinem Browser keine Cookies aktiviert hat.

Viele Grüße,
Garvin

[chrisbra]

Hi,
sind denn Cookies unbedingt notwendig? Was ist mit den Besuchern, die ohne Kekse browsen? Warum steht das eigentlich nicht irgendwo, dass die Kekse benötigt werden, um zu kommentieren? Oder hab ich was übersehen?

Könnte man nicht einfach den erwarteten Captcha Code in einen Hash packen und im Formular mitschicken? Dann wären doch Cookies nicht mehr nötig, oder übersehe ich etwas?

Liebe Grüße,
chrisbra

[garvinhicking]

Ja, Cookies sind unbedingt notwendig. Besucher ohne Kekse können keine Kommentare hinterlassen; das wird in der Beschreibung der Kommentarmaske eindeutig erwähnt.

Wenn man den erwarteten Captcha Code mit in einen Hash packt, gibt man Spammern wertvolle Hinweise über den erwarteten Code, so dass diese auf kurz oder lang den Algorithmus knacken könnten: Einfach einmal einen gültigen Cookie rüberschicken, und dann kannst Du die richtige Antwort und die Challenge jederzeit wieder schicken.

Wie Du richtig siehst sind Cookies genau deshalb erforderlich, um den erwarteten Code sicher in einer Session auf dem Server und nicht beim Client zu transportieren.

Viele Grüße,
Garvin

[heddesheimer]

Wie Du richtig siehst sind Cookies genau deshalb erforderlich, um den erwarteten Code sicher in einer Session auf dem Server und nicht beim Client zu transportieren.

Sollte die Session nicht auch ohne Cookies funktionieren, indem PHP per Fallback die Session-ID über den Get-Parameter überträgt?

Gruß Marian

[garvinhicking]

Nein, in unserem Fall funktioniert das nicht, da die Captchas mit einem externen Script erzeugt werden die die Session-ID nicht parsen.

Auf Cookies zu setzen ist auch ein weiterer Schutz gegen Spammer, die so nämlich auch Cookies emulieren müssten um erfolgreich zu spammen...

Viele Grüße,
Garvin

[chrisbra]

Wenn man den erwarteten Captcha Code mit in einen Hash packt, gibt man Spammern wertvolle Hinweise über den erwarteten Code, so dass diese auf kurz oder lang den Algorithmus knacken könnten:

Tun sie das? Bei Verwendung einer kryptografischen Hash-funktion wie SHA-256 oder MD5? Ich weiß, dass diese Schwächen haben, aber der Aufwand ist wohl dennoch zu groß, nur zum Spammen.

Anyway, ich wollte nur anmerken, dass meiner Meinung nach Cookies ein Vertrauensproblem darstellen können und ich würde halt gern drauf verzichten. Egal, wenn es nicht anders geht, dann ist es auch in Ordnung.

Grüße,
chrisbra

[garvinhicking]

Chrisbra:

Klar, ganz egal welche Zauber-Kryptofunktion man anwendet: Bei einem F ormular-Request musst Du ja die EINGABE und die KRYPTO-Funktion übermitteln; um das dann später session-unabhängig zu kontrollieren muss der Krypto-Wert die Eingabe enthalten. Der User muss also jetzt nur einmal gucken was die richtige eingabe wäre, und schickt dann in Zukunft immer nur den richtigen Krypto Wert und die dazugehörige Eingabe. Damit hat er einen Einweg-Captcha, den er immer übermitteln könnte.

Das einzig wirksame wäre die Session-ID mit in die URLs zu packen beim Aufruf der Captcha-Grafiken. Den Aufwand finde ich persönlich jedoch nicht treibenswert, da man Cookies von den Besuchern IMHO schon für Spamschutz erwarten kann. Patches nehme ich natürlich gerne an, wenn sich jemand die Mühe machen möchte.

Ich stimme Dir schon zu, dass jede zusätzliche Hürde ein Ärgernis darstellen kann - wenns Spammer nicht gäbe, müsste man das alles nicht treiben. :-/

Viele Grüße,
Garvin

[chrisbra]

Das einzig wirksame wäre die Session-ID mit in die URLs zu packen beim Aufruf der Captcha-Grafiken. Den Aufwand finde ich persönlich jedoch nicht treibenswert, da man Cookies von den Besuchern IMHO schon für Spamschutz erwarten kann. Patches nehme ich natürlich gerne an, wenn sich jemand die Mühe machen möchte.

Gib mir mal 'nen Tipp, wo muß ich suchen?

Grüße
chrisbra

[garvinhicking]

Gib mir mal 'nen Tipp, wo muß ich suchen?

plugin/serendipity_event_spamblock/serendipity_event_spamblock.php:

An dieser Stelle muss die sessionid übergeben werden:

Code: Select all

                    if ($show_captcha) {
                        echo '<div class="serendipity_commentDirection">';
                        if (!isset($serendipity['POST']['preview']) || strtolower($serendipity['POST']['captcha'] != strtolower($_SESSION['spamblock']['captcha']))) {
                            echo '<br />' . PLUGIN_EVENT_SPAMBLOCK_CAPTCHAS_USERDESC . '<br />';
                            if ($use_gd) {
                                printf('<img src="%s" title="%s" alt="CAPTCHA" class="captcha" />',
                                    $serendipity['baseURL'] . ($serendipity['rewrite'] == 'none' ? $serendipity['indexFile'] . '?/' : '') . 'plugin/captcha_' . md5(time()),
                                    htmlspecialchars(PLUGIN_EVENT_SPAMBLOCK_CAPTCHAS_USERDESC2)
                                );
                            } else {
                                $bgcolors = explode(',', $this->get_config('captcha_color', '255,0,255'));
                                $hexval   = '#' . dechex(trim($bgcolors[0])) . dechex(trim($bgcolors[1])) . dechex(trim($bgcolors[2]));
                                $this->random_string($max_char, $min_char);
                                echo '<div style="background-color: ' . $hexval . '">';
                                for ($i = 1; $i <= $max_char; $i++) {
                                    printf('<img src="%s" title="%s" alt="CAPTCHA ' . $i . '" class="captcha" />',
                                        $serendipity['baseURL'] . ($serendipity['rewrite'] == 'none' ? $serendipity['indexFile'] . '?/' : '') . 'plugin/captcha_' . $i . '_' . md5(time()),
                                        htmlspecialchars(PLUGIN_EVENT_SPAMBLOCK_CAPTCHAS_USERDESC2)
                                    );
                                }
                                echo '</div>';
                            }
                            echo '<br />';
                            echo '<label for="captcha">'. PLUGIN_EVENT_SPAMBLOCK_CAPTCHAS_USERDESC3 . '</label><br /><input type="text" size="5" name="serendipity[captcha]" value="" id="captcha" />';
                        } elseif (isset($serendipity['POST']['captcha'])) {
                            echo '<input type="hidden" name="serendipity[captcha]" value="' . htmlspecialchars($serendipity['POST']['captcha']) . '" />';
                        }
                        echo '</div>';
                    }

An dieser Stelle müssen die übergebenen Session-ID dekodiert werden und mittels PHP session funktionionen initialisiert werden (evtl. session_destroy vorher, falls keine cookie-ID vorhanden):

Code: Select all

                case 'external_plugin':
                    $parts     = explode('_', $eventData);
                    if (!empty($parts[1])) {
                        $param     = (int) $parts[1];
                    } else {
                        $param     = null;
                    }

                    $methods = array('captcha');

                    if (!in_array($parts[0], $methods)) {
                        return;
                    }

Ausserdem muss im Rest des Codes sichergestellt werden, dass die Sessions per URL-Übergabe funktionieren anstelle per Cookie; oder zumindest wenn Einzelartikel aufgerufen werden. Dafür wäre evtl. Anpassung der Rewrite-Rules und des Pattern-Matchings in der index.php notwendig.

Wie gesagt, das ganze ist sehr aufwändig, und IMHO diesen Aufwand nicht wert - Serendipity hat eigentlich recht wenig Systemvoraussetzungen; funktionierende PHP-Cookie-Sessions ist leider bis dato eine davon...

Viele Grüße,
Garvin