Cross-Site Request Forgery (CSRF)

[max479]

Hallo erstmal,

Ich bin gerade damit beschäftigt einen Schutz für CSRF Angriffe in meine Formular Scripts, bzw. auch in Textlinks einzubauen, bei denen INSERT, UPDATE, oder DELETE Funktionen ausgeführt werden.

Kann mir vielleicht jemand bestätigen, ob folgender Ablauf ausreicht?

formular.php:

<?php
$tok=md5(uniqid(rand(), true));
$_SESSION["tok"]=$tok;
?>

<form method="post" action="check.php">
<input type="hidden" name="tok" value="<?echo $tok;?>">
</form>

check.php:

if(!isset($_SESSION["tok"]) or $_SESSION["tok"]!=$_POST["tok"]):
    header("Location: [URL]");
    exit();
endif; 

Vielen Dank und schöne Grüße,
Max

[rossixx]

wenn ich dich richtig verstehe suchst du nach einer möglichkeit die get bzw. post daten, die an die folgeseite übergeben werden sollen zu checken und zu vermeiden das diese manipuliert wurden.

die lösung für diesen fall heist: hash

[pekka]

Mmm... Insert, Update und Delete sind ja Operationen, die normalerweise immer an eine authentifizierte Session geknüpft sind. Welche zusätzliche Sicherheit das Token bringen soll, kann ich im Moment nicht nachvollziehen. Kannst Du das genauer ausführen?

[wahsaga]

Wie immer gilt eigentlich - wer das Problem verstanden hat, der weiss auch, was dagegen zu unternehmen ist.

Deshalb würde ich vorschlagen, hier anzufangen: Cross-site request forgery - Wikipedia, the free encyclopedia

[Yoshi-]

Mmm... Insert, Update und Delete sind ja Operationen, die normalerweise immer an eine authentifizierte Session geknüpft sind. Welche zusätzliche Sicherheit das Token bringen soll, kann ich im Moment nicht nachvollziehen. Kannst Du das genauer ausführen?

CSRF ist das man z.B. den Admin von dieser Seite einen Link zu einen Formular gibt das genauso aufgebaut ist wie ein Formular im Admincenter, nur mit hidden Feldern, wenn der Admin dann z.b. auf einen Button klickt wird das Formular von der Fremden Seite auf diese wieder geleitet und da der Admin ja alle Rechte hat, wird das Formular hier auch so verarbeitet als wenn der Admin es direkt im Admincenter eingegeben hat.

Der Ablauf des TE müsste eigentlich reichen.

[pekka]

Interessant, danke!

Der Ablauf des TE müsste eigentlich reichen.

Dem schließe ich mich an.

[wahsaga]

CSRF ist das man z.B. den Admin von dieser Seite einen Link zu einen Formular gibt das genauso aufgebaut ist wie ein Formular im Admincenter, nur mit hidden Feldern, wenn der Admin dann z.b. auf einen Button klickt wird das Formular von der Fremden Seite auf diese wieder geleitet und [...]

Nein, das wäre simples Phishing.

Was CSRF wirklich ist, steht bspw. im verlinkten Wikipedia-Artikel.

[pekka]

Nein, das wäre simples Phishing.

Was CSRF wirklich ist, steht bspw. im verlinkten Wikipedia-Artikel.

Soweit ich den Artikel verstehe, ist Yoshis Aussage durchaus korrekt. Er sagt, daß einem Admin ein Formular eines Interfaces vorgespiegelt wird, dieses vom Admin mit Werten ausgestattet und das ganze dann an das echte Interface geschickt wird, an dem der Admin gleichzeitig angemeldet sein muß.

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF ("sea-surf") or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.

Dagegen schützt sich der TO, indem er einen Hash generiert, den er sowohl in einer Session-Variable als auch in allen Formularen ablegt, die an das System gesendet werden. Weichen Formular-Hash und Session-Hash voneinander ab, wird die Durchführung gestoppt.

Oder versteh ich was falsch?

[unset]

Nein, das wäre simples Phishing.

Das wäre es, wenn das das Formular, bzw. die Seite den Eindruck erwecken soll, dass es sich um die anzugreifen Seite handelt. Aber ich glaub Yoshi- meint hier, dass das Formular eben nur genau die Werte rausschickt, die die Applikation gerne hätte …*Insofern ist das schon ein treffendes Beispiel für CSRF.

[wahsaga]

Er sagt, daß einem Admin ein Formular eines Interfaces vorgespiegelt wird, dieses vom Admin mit Werten ausgestattet und das ganze dann an das echte Interface geschickt wird

Nein, das fett geschriebene ist eben nicht notwendig.

Der Angreifer gibt die zu übermittelnden Werte bereits vor.
Er muss dann noch den Nutzer, der im System angemeldet ist, dazu bringen, diese vorgegebenen Werte unbeabsichtigt an die Zielseite zu übermitteln - und das geschieht iaR. gar nicht dadurch, dass ich als Nutzer auf der Angreifer-Seite noch irgendwas explizit machen muss, sondern wird meinem Browser überlassen.


Das Beispiel im Artikel verdeutlicht es noch.

Wenn das Löschen von Postings hier im Forum für Moderatoren per GET-Request ohne weitere Bestätigung möglich wäre - dann müsstest du mich nur auf irgendeine Seite locken, wo du

<img src="http://diesesforum/deletePosting.php?posting_id=4711">

drin untergebracht hast.

Mein Browser würde dann die Ressource http://diesesforum/deletePosting.php?posting_id=4711 anfordern, und dabei meinen Login-Cookie von http://diesesforum/ mitschicken. Der Cookie weisst mich als eingeloggten Moderator aus, also wird die Lösch-Anfrage ausgeführt - da ist meinerseits kein Ausfüllen eines Formulars mehr erforderlich.


Zugegeben, wenn ich Yoshi-'s Beitrag noch mal lese, dann meinte er vermutlich das gleiche Prinzip. Bei POST-Requests ist das Abschicken eines Formulars erforderlich - aber auch das erfolgt keine explizite User-Aktion, sondern kann per JavaScript automatisch erfolgen. Dann das target noch auf einen unsichtbaren Iframe gesetzt, und der Nutzer bekommt davon kaum noch etwas mit.

[pekka]

Nein, das fett geschriebene ist eben nicht notwendig.

Der Angreifer gibt die zu übermittelnden Werte bereits vor.

Stimmt. Vom Prinzip her haben wir aber glaube ich alle dasselbe gemeint, nur anders ausgedrückt.

[rossixx]

na wenn das jetzt zwischen euch geklärt ist:

fehlt nur noch die to do list, was dagegen sinnvolles zu unternehmen ist ?!?!

[unset]

Das wurde bereist gesagt: Einmal gültige Token. Mit Token kein CSRF.

[Yoshi-]

Es ging ja weniger darum, zuerklären wie man CSRF am effektivsten benutzt, sondern nur darum, wie CSRF grob funktioniert.

[unset]

Eigentlich ging es darum, wie man CSRF verhindert …*