Sicherheit: CSRF-Demo

Basti · 29.12.2005, 00:04

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-Code:

  <?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]

imported_Ben · 29.12.2005, 00:55

Feine Demo

.

Corvin · 29.12.2005, 12:53

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

Basti · 29.12.2005, 13:12

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:

Code:

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

Code:

<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

Zergling-new · 29.12.2005, 14:11

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

Corvin · 29.12.2005, 14:35

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

Zergling-new · 29.12.2005, 14:58

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 · 29.12.2005, 15:04

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

Basti · 29.12.2005, 16:00

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

Zergling-new · 15.05.2006, 12:18

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

Umfrageergebnis anzeigen: War dieses Tutorial hilfreich?
Ja	3	75,00%
Nein	1	25,00%
Teilnehmer: 4. Du darfst bei dieser Umfrage nicht abstimmen

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

LinkBacks (?) LinkBack to this Thread: http://www.php.de/tutorials/35299-sicherheit-csrf-demo.html
Erstellt von	For	Type	Datum
Sichere PHP-Web-Applikationen schreiben - Ein Überblick - Webmasterpro.de	This thread	Refback	28.08.2008 19:42

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
BACKLINK CHECK und SICHERHEIT von zentraler CSV-Datei	ff-webdesigner.de	PHP-Fortgeschrittene	16	27.11.2008 20:25
[Erledigt] Sicherheit erhöhen...	pck1983	PHP Tipps 2008	22	03.08.2008 01:31
Sicherheit in PHP	robydog	PHP Tipps 2008	52	10.05.2008 13:09
FON und die WiFi Ads - Bald mehr Sicherheit		PHP Tipps 2007	0	03.08.2007 12:06
PHP Sicherheit	Plague	PHP Tipps 2007	13	26.04.2007 16:24
PHP Sicherheit	phpdummi	PHP Tipps 2006	1	27.09.2006 23:31
Erfahrung mit Sessions ( Sicherheit )	GELight	PHP Tipps 2006	6	11.08.2006 17:55
Sicherheit...	GELight	PHP Tipps 2006	5	31.01.2006 15:58
Frage zur Sicherheit von GET Variablen	malaga	PHP Tipps 2005-2	3	20.09.2005 13:36
Sicherheit im Web-Interface	nussbaum	PHP Tipps 2005-2	9	29.06.2005 14:10
Sicherheit....	renzo	PHP Tipps 2005-2	1	27.06.2005 15:53
[Erledigt] Thema Sicherheit?		PHP-Fortgeschrittene	5	05.11.2004 05:43
Sicherheit bei Wertübergaben		PHP Tipps 2004	3	14.10.2004 18:06
Apache öffentlich machen. Sicherheit?		Server, Hosting und Workstations	3	07.07.2004 03:20
Sicherheit bei URL-Übergabe	pcschröda	PHP-Fortgeschrittene	25	28.06.2004 16:44

29.12.2005, 00:04
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	Sicherheit: CSRF-Demo 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-Code: <?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ü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ühren[/url] <hr/> Einträ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ücksetzen[/url]


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

29.12.2005, 00:55
imported_Ben Erfahrener Benutzer Registriert seit: 18.09.2003 Beiträge: 13.598 PHP-Kenntnisse: Fortgeschritten	Feine Demo . __________________ Webentwickler-Blog - Buchbesprechung PHP Design Patterns - SQL-Antipatterns

29.12.2005, 12:53
Corvin Erfahrener Benutzer Registriert seit: 02.04.2008 Beiträge: 2.603	Nette Demo! Ich habe den Thread mal in meinem Security-Tutorial verlinkt.

29.12.2005, 13:12
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	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: Code: 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 Code: <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

29.12.2005, 14:11
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	Wie kann man dem entgegenwirken, einzig in dem man HTML und JavaScript unterbindet?

29.12.2005, 14:35
Corvin Erfahrener Benutzer Registriert seit: 02.04.2008 Beiträge: 2.603	Entweder du unterbindest HTML/JS einfach komplett oder du verwendest einen sehr umfangreichen Filter.

29.12.2005, 14:58
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	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.

29.12.2005, 15:04
Corvin Erfahrener Benutzer Registriert seit: 02.04.2008 Beiträge: 2.603	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

29.12.2005, 16:00
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	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

15.05.2006, 12:18
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	Ich habe den Thread mal ins Tutorial verschoben, in Werbung hat er nicht so wirklich reingepasst.