Mal eine grundsätzliche Frage zur antiCSRF-Funktion...
Beim Betrachten des Codes fällt mir auf, daß
nur POST-Variablen berücksichtigt werden, allerdings steht CSRF ja für Cross-Site
Request Forgery und betrifft also auch
jegliche Requests. Und davon gibt es ja etliche in ConPresso, die GET als Methode benutzen.
Nur mal als Beispiel:
Bei Modulen wird nur die finale Sicherheitsabfrage beim Deinstallieren durch antiCSRF geschützt, weil ein Formular genutzt wird. Alle anderen Aktionen laufen aber über ein GET. Es kann also ein Angreifer nach Lust und Laune Module aktivieren, deaktivieren und auch installieren, wenn sie auf dem Server als Verzeichnis vorhanden sind.
Genausogut könnte er auch Artikel sperren oder freigeben. Und er kann nach Lust und Laune hochgeladene Bilder und Dateien löschen. Und er kann deaktivierte User wiederherstellen.
Ja, mir ist klar, daß das bisher ja sowieso ging und ein Schutz für Formulare besser ist als gar kein Schutz. Aber wenn schon, dann könnte man die Funktion checkToken auf $_REQUEST umbauen.
Die Angabe der Variaben von Hand als Funktionsargumente wäre zwar auch eine Möglichkeit, aber eigentlich müsste die Beschränkung ja nicht sein, oder?
Dann müssten natürlich Aktionen wie das Abschalten eines Moduls mit einem Link in der Form
Code: Alles auswählen
../_admin/modules.php?action=modules_deactivate&module=MODULNAME&csrfToken=eca50474cc8aae3a4468997cd44fe1f3
ausgeführt werden, was man mittels angehängtem
Code: Alles auswählen
'&csrfToken='.$antiCSRF->getToken('modules_deactivate')
erreichen könnte.
Die Prüfung könnte man derzeit mit einem
Code: Alles auswählen
if (!$antiCSRF->checkToken($_REQUEST['action'], $_REQUEST['csrfToken'])) { ...
erzeugen. Schöner wäre es aber, wenn standardmä0g REQUEST statt POST ausgewertet würde und somit auch hier
reichen würde.