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

__________________
http://www.verena-verbindet.de - Linkhandel-Börse

Hallo,

dein Sicherheits-Hinweis ist wirklich sehr interessant.

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

__________________
Webmaster Homepage

Wirklich interessant! Gabs ja auch schon bei ProSieben.de, das PHPMyadmin ohne Passwort Schutz war :roll:

__________________
Wir erstellen Ihre Traum Homepage
Ideal für kleine Firmen und Einzelunternehmer

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

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]javascript:alert('Code Injection');[/img]

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

__________________
one-way.de - New Service

.....

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("<","&lt;",$_POST['Eingabe']");
$Eingabe=str_replace("<","&lt;",$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

__________________
one-way.de - New Service

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 )

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!

Grüße

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:
überprüfen ob der Wert "echt" ist.

Von festen Angaben erstelle ich einen md5 Wert und nur dieser wird an die Datenbank anfrage weitergegeben. (z.B. Passwort, Benutzername, ...) Dieser enthält dann natürlich keine Sonderzeichen mehr.

Und wenn man keine MD5 werte in der DB haben will könnte man das noch anders lösen, was aber mehr Serverleistung kostet.
Man könnte doch in einer Schleife jede Zeile der Tabelle auslesen und diese dann mit den übergebenen Werten vergleichen. Wenn nach ablauf der Schleife kein Treffer vorkommt, ist die Abfrage dann FALSE.

Und noch eine, leichtere Methode die DB abfrage abzusichern ist folgende:
Mithilfe von mysql_real_escape_string($string) wird $string maskiert, so das dieser "gefahrlos" an die DB übergeben werden kann.

War für euch was interessantes Dabei ?

__________________
Mein aktuelle Projekt