SQL Injection

Aaaalso ich suche ein Video-Tutorial, um lücken für eine SQL-Injection zu finden. Wie man diese Lücken ausnutzt, darüber hat enco schonmal ein Video gemacht, Nun würd ich gern noch ein Videotut haben, was man praktisch mit enos tut "verbinden" könnte... wär ganz nett :lol:

mFg

HIer ist ein kleines Paper allgemein über SQL Injections. (gefunden auf obscurity-board.org von Geforce)

Code:

---

SQL-Injection - Angriff und Abwehr
SQL-Injection bezeichnet das Einschleusen von eigenen Befehlen in eine SQL-Datenbank. Überprüft eine Web-Applikation Benutzereingaben nicht ausreichend, ist damit jede Datenbank auf jedem Betriebssystem verwundbar.

Webshops, News-Boards, Groupware- und Content-Management-Systeme setzen Datenbanken ein, um darin Kundendaten, Artikel und Texte abzulegen. Oft trifft der Besucher solch einer Seite auf Kombinationen von Windows-2000-Server, IIS, MS-SQL-Server und Active Server Pages oder Linux zusammen mit Apache, mySQL und PHP oder Perl.

In Webformularen können Benutzer Informationen eingeben, um Bestellungen einzugeben oder sich als Kunde zu registrieren. Aus diesen Angaben erzeugt die Web-Applikation dynamische Datenbankanfragen. Überprüft die Applikation die Eingabe nicht oder fehlerhaft, ist es möglich, spezielle Zeichenketten einzuschleusen. Mit geschickt gewählten Eingaben kann ein Angreifer dann eigene Parameter und Befehle an die Datenbank übergeben und auf deren Inhalte und sogar das System zugreifen.

Linguistik

Um Daten in eine SQL-Datenbank zu schreiben oder daraus zu lesen, kommuniziert eine Applikation mit der Datenbank über die Befehlssprache SQL (Structured Query Language). In der Regel übergibt sie einen kompletten String, den sie vorher aus Befehlen und Benutzereingaben zusammengefügt hat. Da es eine Vielzahl von SQL-Datenbank-Lösungen gibt, die teilweise eigene Funktionen unterstützen, ist der SQL-Befehlsumfang mittlerweile recht groß. Eine Schnittmenge von Befehlen, wie etwa Befehle SELECT, UPDATE, DELETE, INSERT, DROP und WHERE, verstehen aber alle. SQL-Datenbanken können mehrere Datenbanken mit jeweils mehreren Tabellen enthalten, die wiederum aus mehreren Spalten bestehen.

Ungefiltert

Mit dem SQL-Befehl

SELECT * FROM kunde WHERE card = 'visa'

liefert eine Datenbank alle Datensätze der Tabelle kunde zurück, die in der Spalte card den Wert visa abgelegt haben. Ersetzt man die konstante Zeichenkette visa durch eine Variable $card, so sind in Verbindung mit einer Benutzereingabe verschiedene Zeichenketten möglich:

SELECT * FROM kunde WHERE card = '$card'

Solange in der Variablen Werte wie visa, amex oder master stehen, reagiert die Datenbank wie erwartet. Gibt ein böswilliger Benutzer jedoch die Zeichenkette ';DROP TABLE KUNDE-- ein, schickt die Applikation folgendes an die Datenbank:

SELECT * FROM kunde WHERE card = '';DROP TABLE KUNDE--'

Da das Semikolon ein Trennzeichen darstellt, sieht die Datenbank zwei Befehle:

SELECT * FROM kunde WHERE card = ''

zeigt alle Datensätze deren Spalte card leer ist. Anschließend führt die Datenbank den zweiten Befehl aus, der die Tabelle kunde komplett löscht.

DROP TABLE KUNDE--'

Die zwei Bindestriche kennzeichnen den Anfang eines Kommentars, weshalb auch das letzte Hochkomma (Quote) ignoriert wird, statt einen Fehler hervorzurufen. In diesem Beispiel kann ein Angreifer ohne vorherige Authentifizierung ganze Tabellen von der Festplatten wischen. Allerdings muss die Web-Applikation die erforderlichen Zugriffsrechte besitzt. Beim Anlegen des entsprechenden Datenbanknutzers muss der Datenbank-Administrator das Löschen mittels DROP erlauben.

Das grundlegende Problem bei SQL-Injection ist die fehlende Filterung der Eingaben auf mögliche Quotes. Viele Applikation setzen einen SQL-Befehl aus Stringelementen zusammen, die von Hochkommas eingerahmt werden müssen. Unter Java sieht das dann so aus:

String sql = new String("SELECT * FROM kunden WHERE
card= '" + request.getParameter("cardname")"'")

Java expandiert die Eingabe cardname und fügt sie dem feststehenden String hinzu. Mögliche Quotes in cardname bleiben erhalten, erscheinen nun aber in einem anderem Kontext. Der ursprünglichen Befehl kann um weitere Befehle ergänzt werden.
Kung Fu
Durch das Einschleusen eigener Befehle ist es möglich, auf beliebige Tabellen und Daten zuzugreifen und deren Inhalte zu manipulieren, zum Beispiel Kreditkartennummern, die ein Webshop zu Abrechnungszwecken gespeichert hat. Dazu muss ein Angreifer aber die Struktur der Datenbank kennen. Um etwa aus einer Tabelle zu lesen, ist es notwendig, den Tabellennamen anzugeben. Ohne Einblick in den Source-Code muss er raten -- oder die Datenbank dazu bewegen, Informationen preiszugeben.

Je nach Plattform und Umgebung, zeigen Web-Applikationen in bestimmten Situationen dem Anwender Fehlermeldungen an. Beispielsweise geben Microsofts Active Server Pages über misslungene Zugriffe auf den MS-SQL-Server Auskunft.

Übergibt man im Web-Frontend als Usernamen

' having 1=1--

an, so erzeugt die Programmzeile

var Query = "SELECT * FROM users WHERE username = '" + username + "'
and password =" ' " + password + "'";

eine Fehlermeldung, da das SQL-Statement HAVING an dieser Stelle eigentlich nichts zu suchen hat. Sinngemäß lautet die Meldung: "Die Spalte users.username ist ungültig, da sie in keiner Funktion enthalten ist und kein GROUP-BY-Argument angegeben ist."

Ein Angreifer weiß nun, dass es in der Tabelle users die Spalte username gibt und kann weitere Versuche starten:

' group by users.username having 1=1--

produziert die Ausgabe: "Die Spalte users.password ist ungültig, da sie in keiner Funktion enthalten ist und kein GROUP-BY-Argument angegeben ist." Zusätzlich kennt er nun den Namen eines weiteren Feldes. Neben HAVING sind auch andere SQL-Befehle möglich, um Fehlermeldungen zu produzieren. Den Variablentyp erfährt der Angreifer durch die Eingabe

' union select sum(username) from users--

Die Applikation meldet einen Fehler, wenn username vom Typ varchar ist: Die Funktion sum() erlaubt nämlich keine varchars als Argument.

Mit vielen provozierten Meldungen kann man sich nach und nach ein Bild vom Aufbau der Datenbank machen. Anschließend ist es dann relativ einfach, eigene Datensätze zu schreiben, zu ändern, zu lesen oder zu sogar zu löschen.

Mehr Kung Fu

Unterstützt die Datenbank besondere Features, so ist es sogar möglich mit dem darunterliegenden Betriebssystem zu kommunizieren. Für einen MS-SQL-Server auf Windows 2000 und VBScript findet man häufig solche Anweisungen:

var Query = "SELECT * FROM myKunde WHERE card = '"
& request.form("eingabe") & "'";
Set myDatensatz = myConnection.execute(Query);

Mit dem Befehl lassen sich allen Datensätze anzeigen, in denen die Variable eingabe identisch mit dem Inhalt des Feldes card. Leider hat auch hier der Programmierer darauf vertraut, dass der Bediener keine bösen Absichten hat. Gibt dieser nämlich

' exec master..xp_cmdshell 'net user foo bar /ADD'--

ein, so macht das Skript daraus den Befehl:

SELECT * FROM myKunde WHERE card = ''
exec master..xp_cmdshell 'net user foo bar /ADD'--'

Der MS-SQL-Server liest den letzten Teil des Kommandos als sogenannte Extended Stored Procedures (ESP), die er auf dem Server ausführt[1]. Die Funktion xp_cmdshell übergibt den sich anschließenden String als Befehl an die DOS-Kommandozeile. Das Beispiel fügt damit dem System, beispielsweise Windows 2000, den User foo mit dem Password bar hinzu. ESPs sind im Prinzip dynamische Bibliotheken, die zur Laufzeit nachgeladen und ausgeführt werden. Neben MS-SQL unterstützen auch andere Datenbankhersteller Extended Stored Procedures, die diverse Funktionen bieten, beispielsweise Registry-Keys lesen und schreiben oder Dienste starten und stoppen[9].
Besser Coden
Um SQL-Injection zu vermeiden, ist es notwendig, eingegebene Zeichenketten sorgfältig zu überprüfen und zu filtern, bevor die Applikation sie als Argument in einen SQL-Befehl expandiert und an die Datenbank sendet. Die Strategie des Filters sollte restriktiv sein. Dazu gibt es zwei Ansätze, die je nach Einsatzumgebung sinnvoll sind. Ist die zu erwartende Menge möglicher Benutzereingaben vorhersagbar, sollen nur diejenigen erlaubt sein, die in einer definierten Liste aufgeführt sind. Der Inhalt eines Feldes in das Anwender beispielsweise Automarken eingeben können, lässt sich mit einer Liste aller bekannten Marken vergleichen. Die Applikation verwirft die Eingabe, wenn sie keinem Eintrag in der Liste entspricht. Ähnlich den Filteransätzen bei Firewalls wäre dies eine "deny all, allow some"-Strategie.

Schwieriger wird das Filtern bei nicht vorhersagbaren Eingaben wie Straßennamen, Nachnamen und Telefonnummern. Hier funktioniert nur der "allow all, deny some"-Ansatz zufriedenstellend. Die Applikation darf nur Eingaben an die Datenbank weitergeben, die definierte Elemente nicht enthält: Das Quote-Zeichen und das Semikolon sind verboten. Auch die hintereinander gestellten Bindestriche ("--") dürfen nicht in der Zeichenkette zu finden sein. Andernfalls verwirft das Programm die Eingabe.

Zusätzlich sollte der Filter nach SQL-Befehlen in der Zeichenkette suchen. Trifft er dabei auf solch einen String, verwirft er ebenfalls die Anfrage. Allerdings ist dieses Vorgehen nicht immer pauschal richtig. Einige Content-Management-System speichern Texte in der Datenbank. Der vorliegende Text würde bei Berücksichtigung obiger Hinweise nie den Weg in solch ein System finden. Hier muss der Programmierer verschiedene Methoden kombinieren.

Sehr empfehlenswert ist der Einsatz von Prepared SQL-Statements beziehungsweise Stored Procedures. Dazu definiert man im Programm Templates der gewünschten SQL-Befehle und sendet sie an die Datenbank:

SELECT * FROM users WHERE card = ?

Diese speichert die Befehle und fügt später nur noch die zur Laufzeit übergebenen Parameter hinzu. Ein nachträgliches Einschleusen von zusätzlichen SQL-Befehlen ist dann nicht mehr möglich.

Schützenhilfe bei der Erstellung und dem Betrieb von Datenbank-Applikationen erhalten Programmierer von diversen Tools. Diese helfen schon in der Entwicklungsphase kritische Funktionen und Variablen zu erkennen und zu verbessern[8]. Spezielle Schwachstellen-Scanner überprüfen laufende Applikationen und verschiedene Datenbank-Produkte auf SQL-Injection, Cross-Site-Scripting und sogar Buffer Overflow und erstellen einen Bericht über gefundene Sicherheitslücken[7].

Netzwerksicherheit

Normale Firewalls sind nicht in der Lage SQL-Injection abzuwehren, da ein Angreifer auf die Datenbank nur über ein Web-Frontend mit Formularen zugreift. Firewalls filtern auf Port-Ebene und der Zugriff auf das Frontend mit HTTP (Port 80) ist ja erlaubt.

Application-Level-Firewalls (Proxies), Firewalls mit Intrusion Prevention (IPS) und netzwerkbasierte Intrusion Detection Systeme (IDS) können zwar SQL-Fragmente in Paketen erkennen, daraus aber ein sinnvolles Regelwerk zu erstellen, ist sehr aufwendig, da das schützende System nichts über den aktuellen Kontext weiß. So darf ein spezieller Benutzer bestimmte Datensätze löschen, andere hingegen nicht. Das IDS kann dies aber nicht unterscheiden.

Spezielle Host-basierte Datenbank-Intrusion-Protection-Systeme (DB-IPS) [5,6] versuchen Angriffe auf die Datenbank zu erkennen und abzuwehren. Sie sind auch in der Lage zu unterscheiden, welche Applikation und welche Benutzer bestimmte Befehle an die Datenbank senden dürfen. Einige DB-IPS können sogar Anomalien in der Kommunikation feststellen, beispielsweise wenn eine Applikation plötzlich Kommandos übergibt, die zwar gültig sind, aber vorher noch nie aufgetaucht sind.

Eine vorherige Anmeldung am Server oder der Applikation beseitigt zwar nicht das SQL-Injection-Problem, grenzt doch aber die Zahl möglicher Benutzer ein. Ein Web-Server kann dann Schutz bieten, wenn die Verbindung mit SSL gesichert ist und die Authentifizierung in beide Richtungen erfolgt, also nicht nur der Server ein Zertifikat sendet, sondern auch der Client. Allerdings kann dann aufgrund der Verschlüsselung netzwerk-basierte Intrusion Prevention System nicht mehr in die Pakete hineinschauen; ein eventueller Angriff bliebe unerkannt. Für host-basierte IPS gilt diese Einschränkung nicht.

Eine Anmeldung über ein Webfrontend ist zwar denkbar, da aber meist auch die Anwender-Authentifizierung auf Datenbanken zurückgreift und somit für SQL-Injection anfällig ist, tritt der Fehler nur an anderer Stelle auf.

Fazit

SQL-Injection wird zu einer ernst zu nehmenden Bedrohung für Web-Lösungen die Datenbanken verwenden. Inbesondere Applikationen die mit PHP und ASP entwickelt wurden, scheinen den Statistiken nach besonders anfällig zu sein. Die Zahl der Meldungen von Buffer Overflows in Open-Source-Lösungen und kommerziellen Produkten ist zwar weitaus größer, SQL-Injection-Attacken sind aber viel leichter durchzuführen, da ein Angreifer dazu nur einen Web-Browser benötigt. Programmierer müssen zukünftig sorgfältiger bei der Erstellung von Datenbank-Applikationen sein, um zu vermeiden, dass wichtige Daten kompromittiert werden.(dab)

---

hehe klein ist gut ;-) aber ich werds mir mal durchlesen, big thx

/e soo gut ich habs mir mal durchgelesen, und auch weitesgehend verstanden, aber wie man diese lücken erkennt, das weiss ich immer noch nicht so genau^^

ein video tut währe gut =)

nein wäre es nicht.

warum genau wollt ihr ein Video Tutorial haben? :evil: um alles nachzuklicken? außerdem ist es nicht ratsam bei dem themengebiet ein videotutorial zu machen, denn es ist von injection zu injection unterschiedlich, das kann man nicht alles in einen Topf schmeißen. Daher ist es besser das Prinzip anhand von Texttutorials zu verstehen.

Code:

---

Nachfolgend ist beispielhaft ein einfaches HTML-Formular mit zwei Eingabefeldern für Benutzername und Passwort dargestellt.

<form method="post" action="login.php">
<input type="text" name="username">
<input type="password" name="password">
</form>

Das Login.php funktioniert am einfachsten, indem eine Datenbank-Abfrage wie folgt erstellt wird:

"SELECT id
FROM logins
WHERE username = '$username'
AND password = '$password'";

Stammen die Variablen $username und $password direkt aus der Benutzereingabe, ist ein Missbrauch leicht möglich. Als Benutzername kann beispielsweise „Joe“ angegeben werden. Folgender String wird dann als Passwort verwendet: anything' OR 'x'='x

"SELECT id
FROM logins
WHERE username = 'Joe'
AND password = 'anything' OR 'x'='x'";

Da die Applikation keine richtige Prüfung der Anfrage durchführt, sondern nur eine Zeichenfolge erstellt, wird WHERE durch die Verwendung der einfachen Anführungsstriche zur Klausel mit zwei Komponenten. Ungeachtet des Inhalts der ersten Komponente ist die Komponente 'x'='x' dabei auf jeden Fall wahr.

Hierdurch ist es Angreifern möglich, das Login-Formular zu umgehen, ohne eine gültige Kombination aus Benutzername und Passwort zu besitzen.

---

Added after 1 minutes:
[

Added after 36 minutes:

Der Code für das Formular ist simpel genug um ihn auszulassen - interessant ist nur der Code, der den Login durchführt:

<% @ Language=VBScript %>
<%
strConn = "Provider=SQLOLEDB;Data Source=webdevsrv01;" & _
"Initial Catalog=Demo;User Id=sa;Password="

bValidationFailed = False

If Request.ServerVariables("CONTENT_LENGTH") > 0 Then
strUsername = Trim(Request.Form("UName"))
strPassword = Trim(Request.Form("UPwd"))
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "select count(*) from Users where UserName='" & strUsername &_
"' AND UserPassword='" & strPassword & "'" , strConn
If (rs.Fields(0).Value > 0) Then
Response.Redirect "supa.asp"
Response.End
Else
bValidationFailed = True
End If
End If
%>

Sieht doch ganz normal aus, oder? Sehen wir uns an, wie der SQL String aussieht, wenn sich der Administrator mit admin / admin einloggt:

select count(*) from users where UserName='admin' AND UserPassword='admin'

Der Administrator fällt also definitiv unter die Kategorie "Gute Menschen" - was aber würde ein Cracker versuchen? Wie wär's mit folgender Benutzername und Passwort Kombination: ' OR '1'='1 und ' OR '1'='1. Der SQL String sieht dann so aus:

select count(*) from users where UserName='' OR '1'='1' AND
UserPassword='' OR '1'='1'

Oopsie! Tja, damit sind wir schon auf der gesicherten Site gelandet - und nur weil wir die Benutzereingaben nicht validiert haben.

Aber es geht noch mehr... wie wär's mit Benutzername ' DELETE Users --?

select count(*) from users where UserName='' DELETE Users --' AND
UserPassword=''

Oopsie! Da hab' ich doch gerade sämtliche Benutzeraccounts aus der Tabelle gelöscht! Die zwei Dashes (-) leiten einen Kommentar ein, deswegen gab's mit dem nach AND folgenden String keinen Fehler.

Kein Problem, als Cracker kann man das Problem wieder beseitigen... wie wär's hiermit als Benutzername: ' insert into Users values('got','you') --"? Guess what - damit kann man sich einen Account anlegen!

select count(*) from users where UserName='' insert into Users values('got','you') --' AND
UserPassword=''

Das ist der Fahnenstange Ende leider noch nicht. Warum? Folgende weitere Dummheit im Sourcecode:

<% @ Language=VBScript %>
<%
strConn = "Provider=SQLOLEDB;Data Source=webdevsrv01;" & _
"Initial Catalog=Demo;User Id=sa;Password="
...

Wir sind der Faulheit halber mit dem sa Account eingeloggt. Nun, da würde sich doch folgendes ganz hervorragend anbieten: ' EXEC master..xp_cmdshell 'dir *.* > c:\listing.txt' --

select count(*) from users where UserName='' EXEC master..xp_cmdshell 'dir *.* > c:\listing.txt' --' AND
UserPassword=''

Das ist ein höfliches Beispiel, das "nur" das Root des Systemlaufwerks auflistet. Mit Hilfe des net Kommandos könnten wir uns aber einen User Account in der Administratorengruppe anlegen. Den Code soll sich aber jeder selber basteln.

Mit diesen Beispielen hoffe ich demonstriert zu haben, was SQL Injection ist - das Einfügen von beliebigen SQL Strings in Formulare, die dann am Server ausgeführt werden. Und warum passiert das? Weil die Formulare dem Input der Benutzer vertrauen, und ihn nicht entsprechend validieren. Generell sollte Michael Howard's Regel gelten: All input is evil, until proven otherwise!. Somit ist die Gegenmaßnahme klar: validieren, validieren, validieren

Added after 52 hours 19 minutes:

http://www.thoran.eu/?id=59

hir noch ein paar tips ;-)