Sicherheitsproblem MySQL -> SQL Injection

chaoz · User [**User**] Anmeldung: 19.05.04 Beiträge: 11

Hallo

ich wollte mal etwas nützliches beitragen, und auf eine besondere Gefahr hinweisen.

Es geht um das Problem, dass man Formulardaten die per Browser gesendet werden, oft "manipulieren" kann, da der programmcode nicht genügend gesichert ist. So ist es z.B. möglich, wenn man ein Login Form vor sich hat mittels der Eingabe: admin'-- sich als admin einzuloggen, ohne das Passwort zu wissen.

Wieso ?

Nehmen wir an, das LoginFormular übergibt "username" und "password".

SELECT bla FROM table WHERE username = '$username' AND password = '$password';

so ... wenn man nun in das username feld admin'-- eingibt. Sieht es folgendermaßen aus:

SELECT bla FROM table WHERE username = 'admin'--' AND password =
'$password';

Problem an der Geschichte ist, dass die beiden -- (Minus) , die restliche SQL abfrage auskommentieren, und die Abfrage nach password quasi nicht mehr existiert.

Glücklicherweise gibt es in der Php.ini die magic_quotes_gpc ... wenn man diese auf ON setzt werden alle ' escaped. Somit verhindert dies schlimmeres.
Selbst hamburg.de war schon von diesem Sicherheitsproblem betroffen.

Manuell kann man die Escape Zeichen auch mit addslashes() hinzufügen, was man auch undbedingt machen sollte, bei der Programmierung.

Also ich hoffe, ich konnte euch das Problem halbwegs näher bringen, was sicherlich nichts neues ist, aber gerade Jemand, der sich neu mit der Materie beschäftigt, sollte über solche Dinge informiert werden, weil sie oft zu kurz kommen.

Grüße,

Patrick

Andreas Schroth · Verfasst am: 19.05.2004, 19:33 Titel:

Hallo,

dein Sicherheits-Hinweis ist wirklich sehr interessant.

Fruetel · Erfahrener [**User**] Anmeldung: 09.04.04 Beiträge: 63

Ja, ein wichtiger Hinweis. Solche SQL-Injection Probleme tauchen auch immer wieder bei semi-professioneller Software auf, PHP-Nuke zum Beispiel hatte in der Vergangenheit öfter Probleme mit solchen Bugs. Gerade wenn der Quellcode der Scripts veröffentlicht wird, müssen die Programmierer hier sorgfältig vorgehen.

Gruss,
Thomas

RobZe89 · Verfasst am: 22.05.2004, 16:13 Titel:

Wirklich interessant! Gabs ja auch schon bei ProSieben.de, das PHPMyadmin ohne Passwort Schutz war Mit den Augen rollen

Genesis · Helfer [**User**] Anmeldung: 09.04.04 Beiträge: 183

ja sehr interessant *merk*
hehe, man braucht nur mit google nach phpmyadmin o.ä. suchen Sehr glücklich

HKff4 · Neuer [**User**] Anmeldung: 04.03.05 Beiträge: 6

Hallo beisammen,

dann mal ein Nachtrag: Injections gibt es nicht nur für SQL, das geht auch bei PHP usw.

Ein simples Beispiel, das im allseits beliebten Internetexplorer mit aktiviertem Javascript funktioniert:

In die Eingabezeile eine Eingabeformulars gebe man ein:

<img src="javascript:alert('Code Injection');">

Ein nachfolgendes Script zur Verarbeitung soll die Eingabe anzeigen, z.B. ein Gästebuch, da steht dann vielleicht:

<?php
echo $Eingabe; // wegen MagicQuotes vielleicht auch
// echo stripslashes($Eingabe);
?>

Nun, da entsteht ein rotes X, aber erst nachdem die Alertbox hochkam. Die Alertbox kann auch was anderes sein, das Nachladen eines Trojaners z.B. Und das alles nur, weil der Name des Schreiber angezeigt werden soll?

Das funktioniert einwandfrei auch im IE von WinXP mit SP2.

Fatal an der Sache: Als diese Lücke entdeckt wurde, hat so ziemlich jede namenhafte Boardsoftware diesen Fehler in den BBCodes bzw. VBTags oder wie immer man die nenne mag, nicht abgefangen.

Da hat man eingegeben: [img]javascript:alert('Code Injection');[img] was ja "hinten rum" wieder in einen HTML IMG-Tag umgesetzt wird und schon lief das wieder. Die einzige Ausnahme war damals YabbSe (inzwischen eingestellt), die haben das abgefangen.

Grundsätzlich muss also jede Usereingabe, deren Daten irgendwo hineingeschrieben werden oder die angezeigt werden, überprüfen, immer nach dem Motto: All inputs are evil until proofed otherwise. (Ist nicht von mir, hat mal ein schlauer Mensch gesagt, dessen Name mir entfallen ist.)

Ja und dann die beliebten Serverscriptsprachen, PHP:

if (!MyProof("$Eingabe")) {exit;}
if ($Eingabe=="1") {include ("action1.php);}
if ($Eingabe=="2") {include ("action2.php);}

Ok, die Eingabe wird hier in einer wie auch immer gearteten Routine geprüft, sehr löblich. Was aber, wenn ich als Angreifer hergehe und in meinem Browser aufrufe:

http://.../action1.php?Eingabe=ANGRIFF

Wird in den Includes action1.php, action2.php $Eingabe auch geprüft? Sehr oft nicht und dann ist das Tor wieder auf, sperrangelweit auf! Daraus muss den Schluß ziehen: Jeder mögliche Einspeisungspunkt von Daten durch einen Anwender muss geschützt werden, egal ob er nun gewollt ist oder durch die Programmstruktur zustande kommt.

Gruß
HKff4

Andy.C · Gast [**Gast**]

.....

HKff4 · Neuer [**User**] Anmeldung: 04.03.05 Beiträge: 6

Hi Andy,

also Nachahmer gibt es dafür schon genügend. Ich habe hier keine Lücken wirklich verraten. Die Sache mit dem Javascript durch den IMG-Tag haben die namenhaften Board Softwares alle umgehend gestopft. Nur MS im IE noch nicht.

Ich bin nicht der erste, der das veröffentlicht hat, jetzt hier. Echte Kriminelle suchen sich die Exploits der Sicherheitsdienstleister und gehen auf die Anwender los, die nicht gepatcht haben.

Aber naja: Das einschleusen von Code in eingaben, die später angezeigt werden, kann man ganz einfach verhindern:

<CODE> sei die Einagbe, die mit <?php echo $Eingabe; ?> ausgegeben wird. Die Ausführung dieses Codes ist ganz banal zu verhindern, machen wir es mal sicherer:

<?php
$Eingabe=str_replace("<","<",$_POST['Eingabe']");
$Eingabe=str_replace("<","<",$Eingabe");

echo $Eingabe;
?>

Ende Gelände, dann heisst mein Gästebuchschreiber eben wie ein Stück Code, so wie er das wollte.

Achtung halt, wenn man selbst BBCode programmiert beim [img], weil dort enthält die Eingabe keine spitzen Klammern "<>", die setzt man dann selbst um die Eingabe des Users herum. Da muss man Dinge wie "javascript" oder so ausfiltern.

Gruß
HKff4

Micha2 · Neuer [**User**] Anmeldung: 07.05.05 Beiträge: 1

hm also die lösungen finde ich nicht so gut.

vielleicht liegts daran, dass ich mit perl arbeite.
mit perl lässt sich die sql injection so verhindern:

Unsichere Variante:
prepare("Select * from ...where password = $Eingabe");
execute();

Da in Eingabe auch ein Semikolon (mit anschließendem neuen Befehl sein kann)
oder wie oben bereits beschrieben lassen sich hier Befehle einschleusen(injizieren Sehr glücklich

)

sichere Variante:
prepare("Select * from ...where password = ?");
execute($Eingabe);

Die letzte Variante mit den Daten, die der User eingegeben hat im Execute teil ist deshalb sicher, da hier keine Befehle mehr ausgeführt werden.

Ein Verändern der Daten die vom User kommen ist nicht mehr nötig! Winken

Grüße

Nemesis2010 · User [**User**] Anmeldung: 05.06.06 Beiträge: 11

In der letzten Zeit versuch ich mich vor SQL-Injektion folgendermasen zu schützen:

ich versuche die meisten Daten bzw. Abhängigkeiten in der Datenbank mithilfe von Zahlen zu lösen.
Dann kann ich mit:

eforium · Verfasst am: 27.12.2006, 22:26 Titel:

Auch wichtig ist bei includes darauf zu achten, dass man jeweilige Punkte oder Slashs löscht:

xxl_unna22 · Helfer [**User**] Anmeldung: 23.03.07 Beiträge: 237

800XE · Verfasst am: 03.05.2007, 02:01 Titel:

find ich lustig das du da einen 3 Jahre alten Post Quotest

maject · User [**User**] Anmeldung: 22.03.06 Beiträge: 13

Allgemein gesagt ist das Thema Sicherheit ein weites Feld. Jedoch sollte man sich als Softwareprogrammierer damit ausgiebig beschäftigen. Viele der Threads sprachen schon an, dass SQL-Injections über die Paramter POST und GET kommen. Wer diese vollständig abhorcht, ist im Vergleich zu semi-professioneller Software auf der guten Seite. Man sollte aber nicht vergessen, dass es auch eine SQL-Injection über die globale Variable $_SERVER erfolgen kann. Häufig nutzen zum Beispiel Statistiken die Variabale $_SERVER['HTTP_USER_AGENT'], die wie alle anderen Parameter/Variablen auch manipuliert sein kann. In diesem Falle durch einen vorgeschalteten Proxy oder mittels eines Browser-Plugins.

Auch zu der Passwort-Abfrage möchte ich mich einschalten:

Die nachfolgende MySql-Abfrage ist unsicher:

Upitis · Neuer [**User**] Anmeldung: 28.01.06 Beiträge: 2

Um XSS(Cross-Scripting) Lücken gut abzusichern gibt es folgende Tags:
strip_tags($string) >Entfernt PHP, HTML Tags
htmlentities($string) Wandelt alle Symbole, wie z.B. <> in die in HTML verwendeten Entities um.

Baut diese Abfragen ein und euer Script ist auch gegen XSS-Sicherheitslücken gefeit.