Sicherheit: CSRF-Demo

[Basti]

Hallo.

Ich hab gerade ein kleines Skript zusammengeschrieben, um die
Funktionsweise von CSRF-Attacken ein wenig zu veranschaulichen.

Das Skript stellt ein Gästebuch dar mit einer Login-Funktion für einen
Administrator. Das Gästebuch zeigt die Eingaben ungefiltert an und so ist
es möglich, HTML-Code in das Gästebuch zu schreiben, der Requests an
das Gästebuch stellt. Schaut sich ein angemeldeter Admin das Gästebuch
an und hat dieser den Session-Cookie akzeptiert, dann wird bei diesem
Request natürlich auch der Session-Cookie übemittelt und die Aktion mit
seinen Rechten ausgeführt.

Zum Testen, einfach das Skript auf einem Testserver (PHP5) kopieren.
PHP braucht in dem entsprechenden Verzeichnis Schreibrechte, um ein
Daten- und ein Log-File anzulegen.

Skript aufrufen, dabei Cookies akzeptieren und erstmal mit den normalen
Gästebuch-Funktionen, dem An- und Abmelden und dem Link "Befehl
ausführen" rumspielen, um zu sehen, wie das normal funktioniert.

Dann:
Als Gast z.B. [img]?action=cmd[/img] eingeben,
sich als Admin einloggen,
Logfile aktualisieren und siehe da:
"Admin hat den Befehl ausgeführt"

Es reicht auch ein <img src=?action=cmd>
Die Browser nehmen es ja nicht so genau.

Viel Spaß,
Basti

<?php

$sDataFile = 'guestbook.dat';
$sLogFile  = 'adminlog.dat';

touch($sDataFile);
touch($sLogFile);

if (isset($_GET['logfile'])) show_logfile($sLogFile);

session_start();

if (!isset($_SESSION['sUser'])) $_SESSION['sUser'] = 'Gast';

$sAction = (isset($_GET['action'])) ? $_GET['action'] : '';

switch ($sAction) {

    case 'login':
    $_SESSION['sUser'] = 'Admin';
    break;

    case 'logout':
    $_SESSION['sUser'] = 'Gast';
    break;

    case 'cmd':
    $r = fopen($sLogFile, 'a');
    fputs($r, $_SESSION['sUser'] . " hat den Befehl ausgef&uuml;hrt\n");
    fclose($r);
    break;

    case 'addentry':
    if (ini_get('magic_quotes_gpc') == '1')
        $_POST['entry'] = stripslashes($_POST['entry']);
    $r = fopen($sDataFile, 'a');
    fputs($r, '<div>' . $_POST['entry'] . '</div>');
    fclose($r);
    break;

    case 'reset':
    file_put_contents($sDataFile, '');
    file_put_contents($sLogFile, '');
}

$sLoginLogout = ($_SESSION['sUser'] == 'Admin') ? 'logout' : 'login';

function show_logfile($sLogFile)
{
    echo '[url="?logfile=1"]Aktualisieren[/url]<pre>';
    echo file_get_contents($sLogFile);
    echo '</pre>';
    die();
}

?>
Benutzer: <?php echo $_SESSION['sUser']; ?>
 ([url="?action=<?php echo $sLoginLogout; ?>"]<?php echo $sLoginLogout; ?>[/url])

[url="?action=cmd"]Befehl ausf&uuml;hren[/url]
<hr/>
Eintr&auml;ge:
<pre><?php echo file_get_contents($sDataFile); ?></pre>
<form action="?action=addentry" method="post">
    <textarea name="entry" cols="30"></textarea>

    <input type="submit" value="Eintrag abschicken"/>
</form>
<hr/>
Logfile:

<iframe src="?logfile=1"></iframe>


[url="?action=reset"]Zur&uuml;cksetzen[/url]

[Basti]

Der Filter dürfte im <img>-Tag zum Beispiel keine URLs zulassen, bei denen nachdem Dateiname ein Fragezeichen und noch etwas folgt..

Kann man die nicht auch per mod_rewrite o.Ä. beschönigen? Da müsste man doch schon prüfen ob es wirklich ein valides Bild ist. Das würde mich mal interessieren.

Das Problem dabei ist doch, dass der Server nicht klar unterscheiden kann, ob der Request aus einem img-Tag heraus ausgelöst wurde oder durch einen Klick auf einen regulären Link durch den Administrator.

Basti

[Zergling-new]

Das stimmt wohl. Am sichersten wäre es dann wohl die Grafik auf den eigenen Server zu kopieren und auf Validität zu prüfen. Das geht halt nicht immer oder will man nicht immer.

[MaMo-Net]

Hi.

Der Filter dürfte im <img>-Tag zum Beispiel keine URLs zulassen, bei denen nachdem Dateiname ein Fragezeichen und noch etwas folgt..

Kann man die nicht auch per mod_rewrite o.Ä. beschönigen? Da müsste man doch schon prüfen ob es wirklich ein valides Bild ist. Das würde mich mal interessieren.

MfG MaMo

[Zergling-new]

Ich habe den Thread mal ins Tutorial verschoben, in Werbung hat er nicht so wirklich reingepasst.

[Basti]

Hi.

Das ist die eine Seite: Eingaben, die von außen kommen zu überprüfen und zu filtern, bevor sie an den Browser zurückwandern. Aber der Angriff kann eben auch von sonstwo kommen. Sobald du in einer Anwendung via Cookie eingeloggt bist kann dir irgendwer einen Request unter deiner Identität unterjubeln.

Das heißt, dass es nicht ausreicht, die eigenen Ausgaben an den Browser zu überprüfen, sondern dass auch die Anwendung so gestaltet sein sollte, dass zumindest nicht mit einem direkt vorhersagbaren Request Daten verändert oder veräußert werden können.

Einfache GET-Requests (z.B. img-Tag) sind unwirksam, wenn

a) die Anwendung einen POST-Request erwartet,
b) bei der Erzeugung eines Links ein Token erzeugt wurde, der sowohl serverseitig gespeichert wird, als auch dem Request beigefügt wird,
c) dem Link die Session-ID explizit beigefügt wird (und natürlich dann auch erwartet wird), oder
d) es keine Aktionen gibt, die mit nur einem Klick ausgelöst werden können (Bestätigungsseite etc.)
e) ...?

Mit JavaScript lassen sich sowohl POST-Requests erzeugen, als auch mehrere Requests in Folge, als auch Tokens oder Session-IDs von abgefragten Seiten auslesen. Damit wären also alle oben genannten Mechanismen unwirksam (bis auf e) vielleicht ).

Da bleibt also nur, das Einbringen von JavaScript auf die eigenen Seiten total zu unterbinden.

Bleibt für einen Angreifer noch der Weg, den Angriff von einer anderen Site zu starten. Und, soweit ich das sehe, bleibt da nur, den Referer zu prüfen, oder kann der via JavaScript manipuliert werden?

Captchas sind noch ein weg, wobei das auch nur zieht, wenn der Angreifer nicht da sitzt und sich die Formulare etc. zuschicken lässt, um dem Opfer die nächsten Anfragen unterzujubeln.

Vielleicht noch Bestätigungen über andere Medien zu fordern, wie z.B. per E-Mail. Oder das Abschalten von JavaScript zu erzwingen (was wahrscheinlich nicht funktioniert, oder?).

Und natürlich helfen, Sitzungsdauern zu begrenzen, auf Auto-Logins zu verzichten und Benutzer zu warnen (wobei letzteres mal ein wenig ungläubig dahingestellt sei)

Was noch?

Basti

[Corvin]

Der Filter dürfte im <img>-Tag zum Beispiel keine URLs zulassen, bei denen nachdem Dateiname ein Fragezeichen und noch etwas folgt..
Du erkennst ja sicher schädlichen Code, das musst du halt "nur noch" dem Computer beibringen

[Zergling-new]

Genau darauf zielt eben meine Frage ab, wie sähe grob dieser Filter aus, was müsste ich wie prüfen? Ich hätte da überhaupt keine Ansatz-Idee, außer vielleicht die Session-ID nicht als Cookie zu speichern, sondern immer im Link mitzugeben.

[Corvin]

Entweder du unterbindest HTML/JS einfach komplett oder du verwendest einen sehr umfangreichen Filter.

[Zergling-new]

Wie kann man dem entgegenwirken, einzig in dem man HTML und JavaScript unterbindet?

[Basti]

Noch ein paar Ergänzungen zum Thema CSRF:

Reicht es, HTML zu escapen?
In der Regel ist es nicht einfach so erlaubt, HTML in Gästebücher etc. einzutragen. Aber es gibt auch darüber hinaus Möglichkeiten, Requests einzuschläusen. Eine Möglichkeit sind z.B. Avatare, die nicht hochgeladen werden müssen, sondern für die ein URL angegeben wird oder auch ungeprüfte Angaben für Bilder via [ img ]-Tag oder so.

POST-Requests
Wenn es möglich ist, JavaScript auf die Seite zu bringen, lassen sich nicht nur GET-Requests, sondern auch POST-Requests absetzen!

Angriff von einer Anwendung auf die andere
Es ist auch nicht notwendig, dass die Anwendung, die angegriffen wird und das "Medium" über das Angegriffen wird (hier das Gästebuch) identisch sind. So kann man womöglich herausfinden, auf was für Seiten sich der Administrator einer angreifbaren Anwendung herumtreibt und ihm dort irgendwo einen solchen Request unterjubeln - oder ihn auch direkt auf eine Seite mit einem solchen Request locken.

Links
Natürlich kann man so einen Request auch hinter einem Link verstecken. In dem Fall muss der Benutzer den Link nur zu klicken und der Befehl wird ausgeführt.

In obigem Skript könnte ein Gast also auch eingeben:

Schöne Seite. Schau doch auch mal bei mir vorbei:
Meine Homepage

Identifikation via IP
Nicht nur Anwendung, die ihre Benutzer via Session-Cookie identifizieren sind Ziel solcher Angriffe, sondern auch solche, die die Benutzer anhand der IP identifizieren (Firewalls etc.)

Nochwas:

Mit dem obigen Skript lassen sich natürlich auch XSS-Angriffe ausführen.

Ein einfaches

<script>alert(document.cookie);</script>

gibt dem Gästebuch-Betrachter den Cookie-Inhalt aus. Ein wenig erweitert könnte man so die Session-ID an einen beliebigen Server schicken, ohne dass der Gästebuch-Betracher das so ohne weiteres mitbekommt.


Basti

[Corvin]

Nette Demo! Ich habe den Thread mal in meinem Security-Tutorial verlinkt.

[imported_Ben]

Feine Demo .