CPO 4.1.5: CSRF check failed

[hscha]

Hallo CPO-Macher,

seit der Installation der CPO-Version 4.1.5 quillt das Logfile vor Fehlermeldungen "CSRF check failed." über. Fast jedes Einloggen in den Mitarbeiterbereich der betreffenden Webseite führt zu einem Abbruch des Logins.
Kann das jemand von euch nachvollziehen?

Grüße aus Berlin von
Horst

[MarkusR]

Wie funktioniert bei Dir der Login?

Version a)
Der User ruft über die Navigation oder einen Link eine geschlossene Rubrik auf. Da nicht eingeloggt, wird er zur member.php gebracht, loggt sich dort ein und kommt dann in die Rubrik

Version b)
Du hast irgendwo ein Formular gebastelt, daß die dort eingegebenen Login-Daten an die member.php sendet.

Version a sollte funktionieren, Version b darf nicht mehr funktionieren, da solche Aufrufe durch "Fremdformulare" genau die gestopfte Sicherheitslücke darstellen (It's not a bug, it's a feature!). Du kannst Dir aber sicher von Balu erklären lassen, wie Du passende Ergänzungen vornehmen kannst.

diese Seite scheint Version b zu sein
http://www.reformschule-charlottenburg. ... itarbeiter
geht der Login denn über die zugehörige member.php
http://www.reformschule-charlottenburg. ... itarbeiter
???

[hscha]

Hallo Markus,
ich denke eigentlich die Version a) zu nutzen, weil die Rubrik "Mitarbeiter" eine personalisierte Rubrik ist. Es erscheint das Conpresso-eigene Formular, das die member.php aufruft.
Leider ist nun gar kein Login mehr möglich, so dass ich heute nachmittag zunächst ein Fallback auf 4.1.3 machen werde.
@ Balu: Vielleicht hast du ja einen Tipp, wie man das mit Formularen auf derselben Domain machen kann...

Grüße von Horst

[MarkusR]

Wenn ich Dein selbstgestricktes Formular benutze ("Anmelden mit den verabredeten Daten"), dann erscheint

Sicherheitsprüfung fehlgeschlagen. Bitte versuchen Sie es noch einmal.

Mache ich das gleiche im ConPresso-eigenen Formular ("Bitte geben Sie Ihren Benutzernamen und Ihr Passwort ein."), dann erscheint

Diese Benutzername/Passwort-Kombination existiert leider nicht.

Mit dem richtigen Passwort sollte ein Login möglich sein.

Du benutzt also Version b.

Melde Dich doch mal selbst auf
http://www.reformschule-charlottenburg. ... itarbeiter
im UNTEREN Formular an.

[MarkusR]

Ganz spannend ist folgendes:

ruft man
http://www.reformschule-charlottenburg. ... itarbeiter
auf, dann wird die rubrik Maitarbeiter gezeigt

ruft man aber
http://www.reformschule-charlottenburg. ... itarbeiter
also mit kleinem "m" auf, dann wird da eine extra Formular gezeigt, was Du als "das Conpresso-eigene Formular" bezeichnest.

Für ConPresso ist es egal, ob man den Rubriknamen groß oder klein schreibt. Daher macht es den Eindruck, als ob da jemand noch ein Selbstgestricktes Formular eingebaut hat, daß auf $_REQUEST['rubric'] == 'mitarbeiter' prüft und somit auf "Mitarbeiter" nicht reagiert.

Ich kann mich zwar täuschen, aber für mich ist das nicht "das Conpresso-eigene Formular"...

Übrigens "erscheint" "das Conpresso-eigene Formular" nicht bei personalisierten Rubriken, da man sich dort niemals Einloggen muss, aber kann. Daher muß man schon member.php von Hand aufrufen (was bei Dir aber nicht der Fall ist) oder ein eigenes Login-Formular stricken...

[MarkusR]

Vorläufige und SICHERE Lösung:

Hänge
http://www.reformschule-charlottenburg. ... itarbeiter
(großes M) in Deine Navigation.

Nachteil: der Navigationspunkt wird nicht gehighlightet und ein bereits eingeloggter User kommt auch wieder zum Login.

Alternative: Schreibe in den Text, der jetzt in der Rubrik steht "bitte vorläufig diesen Link benutzen" und verlinke diese URL.

[hscha]

Hallo Markus,
du hast in allen Punkten recht
Ich versuchs gleich mit einem Aufruf der member.php mit der Rubrik-ID. Melde mich mit den Ergebnissen...

Danke und Grüße von
Horst

[hscha]

Hallo Markus,
ich habe den Navilink erstmal auf die member.php geändert, fände es aber gut, wenn die Möglichkeit, ein eigenes Login-Formular zu haben, weiter bestünde, da ich auf anderen Webseiten auch damit arbeite.
Gibt es nach dem Sicherheitsupdate noch eine Chance?

Danke für deine Tipps und
Grüße von
Horst aus Berlin

[MarkusR]

Natürlich gibt es das.

Genau wie bei einem Captcha wird beim Formularaufruf eine Info in die Session geschrieben, die mit der Info beim Empfang der Formulardaten verglichen wird.

Ich würde halt erwarten, da es ja auch im Handbuch auf Seite 172 (Seite 180 im PDF) offiziell als Option beschreiben wird, daß eine offizielle Lösung angeboten wird.

Hier die Inoffizielle:
In Dein Formular muß noch ein $antiCSRF->printInput('dologin'); hinein, also z.B.:

Code: Alles auswählen

<?php $antiCSRF->printInput('dologin'); ?>

Schaue Dir einfach den unteren Teil von _include/member,inc.php an, das sind alle Formularvarianten.

Wegen den Seitentemplates MUSS hier noch was von den Entwicklern kommen... oder man nutzt mod_functions

[hscha]

Danke für den Tipp, Markus!
mod_functions sehe ich mir mal genauer an...

Grüße aus Berlin von
Horst

[MarkusR]

mit mod_functions könnte das so aussehen

function printAntiCSRF($action)
{
$antiCSRF = $GLOBALS['antiCSRF'];
$token = $antiCSRF->getInput($action);
return $token;
}

die roten Teile trägst Du in die Definitionsmaske ein.

Dann sollte <!-- function: printAntiCSRF; action=dologin; -->
die benötigte Ausgabe erzeugen. Habe ich gerade getestet.

edit: habe gerade in einer 4.1.5 Installation mit mod_functions erfolgreich einen Login mit diesem Formular gemacht:

Code: Alles auswählen

<!-- start of login form -->
<form method="post" action="member.php">
<input type="hidden" name="rubric" value="RUBRIK" />
<input type="hidden" name="action" value="dologin" />
<!-- function: printAntiCSRF; action=dologin; -->
<strong>Benutzername:</strong><br />
<input type="text" name="username" /><br />
<strong>Passwort:</strong><br />
<input type="password" name="password" /><br />
<input type="submit" value="Anmelden" />
</form>
<a href="member.php?action=password_reset&rubric=RUBRIK">
Passwort vergessen?</a><br />
<!-- end of login form -->

Das ist das Formular aus dem Handbuch ergänzt mit der neuen Funktion.

Mit PHP kann man dann auch <?php echo printAntiCSRF('dologin'); ?> benutzen.

[hscha]

Hallo Markus,
danke für die obige Anleitung!
Was machen aber Leute, die keine Seitentemplates benutzen? Sind die auf mod_inline angewiesen?

Noch'n Gruß aus dem sommerlich verregneten Berlin von
Horst

[MarkusR]

Was machen aber Leute, die keine Seitentemplates benutzen?

Die sagen einfach mal, wie sie das Formular da rein gebracht haben und zeigen wie ihr Code dafür aussieht. Es kann soooo einfach sein...
Ich könnte jetzt wieder auf die Google-Suche nach "Wie man Fragen richtig stellt" verweisen oder einen Lückentext anbieten: Ich habe folgenden Code in meiner Seite:.... Es passiert folgendes: .... Ich habe schon folgendes probiert: ....


Haben sie das in eine der header oder footer Dateien geschrieben, dann können sie ja einfach PHP-Code benutzen.

Code: Alles auswählen

<?php 
    $antiCSRF = $GLOBALS['antiCSRF']; 
    $antiCSRF->printInput('dologin'); 
?>

mod_inline benutzt man ja, wenn man es in einen Artikel reingeschrieben hat, was man natürlich sagen würde und es nicht als "das ConPresso-eigene Formular" bezeichnen würde

[balu]

Hi,

ich überlege gerade, ob wir diesen Check aus der Frontend-Anmeldung (also für die Besucher der Seite, nicht für das Administrations-Backend) rausnehmen.

Das macht die Erstellung der Formulare für die Admins einfacher, die eventuell nicht überall den Check in der Form erstellen können.

Balu

PS: Das wäre dann die Zeile direkt hinter "case 'dologin':"

Code: Alles auswählen

    case 'dologin': // {{{
        if (!$antiCSRF->checkToken()) {
            $message[] = ___('Security check failed. Please try again.');
            logaction('login', 'CSRF check failed.');
            break;
        }

in conpresso/_include/member.inc.php.

[MarkusR]

Das macht die Erstellung der Formulare für die Admins einfacher, die eventuell nicht überall den Check in der Form erstellen können.

Das sollte eher nicht als Argument dienen.

Aber wenn man mal nachliest was CSRF eigentlich bedeutet (einem eingeloggten User Aktionen unterschieben), dann sollte die Prüfung überflüssig sein, denn
1.) ist der User ja gar nicht eingeloggt
2.) wenn doch, schadet das erneute Einloggen eines bereits eingeloggten Users nicht
3.) wird durch das Einloggen ja keine weitere Aktion ausgelöst, die Probleme bereiten könnte

Oder sehe ich das falsch?