MySQL Injection, wie am besten schützen

marcel · 9. August 2007, 18:16

hallo bin grade dabei unsere Seite aufzubauen... so nach und nach !
bloß da man momentan viel von SQL Injection hört würde ich gerne wissen welche mittel man benutzen muss um sich gut vor injections zu schützen denn es gibt ja mehrere wege solche injections zu betreiben!
und da würde ich schon gerne mal wissen was man dagegen tun kann oder besser gesagt wie man sich am besten davor schützt...
währe net wenn mir der eine order andere dazu informationen geben kann oder sogar eigene Erfahrungen mit solchen sachen etc.. bloß bitte keine englischen tutorials oder informationsblätter !
thx im voraus

SeBa · 9. August 2007, 19:14

SQL-Injections beruhen eigentlich immer auf dem selben Fehler. Nämlich darauf das ungeprüfte (und folglich unmaskierte) Eingaben an die Datenbank gereicht werden. Wenn du das nicht machst, bist du davor geschützt.

Torben Brodt · 9. August 2007, 19:39

Da spielen auch Datentypen und sauberes Coden eine große Rolle. Integer solltest du z.B. auch als Integer übergeben.

Ansonsten: Nutzt du PHP5? Dann verwende die MySQLI Schnittstelle - [phpdoc]mysqli_stmt_bind_param[/phpdoc]
Wenn du Variablen auf diese Art als Parameter übergibst, dann übernimmt PHP das Prüfen.

Aber das ganze schützt natürlich nicht vor Unwissenheit: In der Wikipedia ist das auch auf Deutsch ganz gut erklärt: de.wikipedia.org/wiki/SQL-Injektion

BendIt · 10. August 2007, 14:41

Du solltest wie schon gesagt vermeiden werte ungeprüft in eine query zu setzen... sprich

Quellcode

$sql = 'SELECT * FROM table1 WHERE user = '.$_GET['usr'].' AND pwd = '.$_GET['pwd'];

ist die perfekte möglichkeit für injections.

außerdem auf die übertragung per GET verzichten wenns geht und auf POST ausweichen (auch nicht sicher aber es ist nicht so offensichtlich wie bei GET) ich sag nur HTTPLiveHEADER Plugin etc.

mfg da BendIt

70abc · 10. August 2007, 15:29

Hallo,

ich denke, d0nUt hat das wichtigste zu dem Thema schon gesagt. Will man Datenbank unabhängig bleiben, ist das Pear "DB" Paket zu empfehlen.
Das Paket bringt u.a. entsprechende Funktionen zum "escapen" von schädlichem "Code" mit, egal welche Datenbank man verwendet.

70abc

SeBa · 10. August 2007, 19:45

Das wichtigste hat er tatsächlich gesagt, allerdings in eher in seinem letzten Satz. Auch wenn einem vieles weitgehend abgenommen wird, ist Unwissenheit immer ein Risikofaktor.

P.S. POST oder GET macht bei Injections quasi keinen Unterschied.

BendIt · 10. August 2007, 20:18

P.S. POST oder GET macht bei Injections quasi keinen Unterschied.

hab auch nix anderes behauptet. mir ging es darum das der anreiz eines potentiellen angreifers möglicherweise dadurch beeinflusst wird wenn der aufbau einer url direkt in der adress zeile sichtbar ist und zum "manipulieren" einlädt. zumindest macht POST es etwas schwieriger den aufbau sofort zu erkennen da wie allseits bekannt die daten nicht offensichtlich über die url erkennbar werden.

mfg da BendIt

SeBa · 11. August 2007, 13:22

Ja allerdings sollte man bedenken, dass Leute eine SQL-Injection machen wollen, durchaus wissen, wie man POST-Variablen manipuliert. Das W3C hat eine Art Empfehlung wie man POST/GET einsetzen sollte, die durchaus Sinn macht. Da spielen andere Faktoren (Usability, Internationalization, URL-Länge, ...) eine größere Rolle als der Versuch etwas zu verschleiern.

marcel · 11. August 2007, 14:25

mkay thx das sind doch schonmal ein paar hilfen

BennyBunny · 12. August 2007, 13:33

Man kann natürlich auch Prepared-Statements verwenden!

Injections bei PHP-Anwendungen sind meiner Meinung nach recht selten geworden, da meistens magic_quotes aktiviert sind und diese die Chancen verwundbare Stellen zu finden, recht beschränkt.

marcel · 16. August 2007, 17:19

das mag ja sein aber was ist wenn magic_quotes off ist ?

70abc · 17. August 2007, 08:49

marcel schrieb:

das mag ja sein aber was ist wenn magic_quotes off ist ?

Ich bevorzuge diese Einstellung eigentlich, weil man dann wirklich immer "roh" Daten hat. Man kann/muss dann eben selber entscheiden, wann man die Daten wie weiter bearbeiten muss. Mit ein bisschen Erfahrung ist das aber nicht schwer und man wird viel sensibler für Probleme.

70abc

marcel · 27. August 2007, 16:33

hmm bloß was ist, wenn jemand die einstellung doch OFF hat und das script so geschrieben wurde, dass diese Einstellung On ist ? dann hat man keine rohdaten mehr

und da manche hoster in dieser frage sehr schlampig arbeiten kann dadurch doch ein großes problem entstehen

student2312 · 5. November 2008, 17:33

Hallo zusammen,

Ich greif mal hier den etwas verstaubten Thread auf zum Thema SQL Injections auf.
Ich habe leider erst etwas spät entdeckt, dass es bereits tolle Klassen zur SQL Sicherung gibt, deshalb wollte ich fragen, ob Ihr folgendes für sicher haltet:

Quellcode

$_GET = secure($_GET);
$_POST = secure($_POST);
$_SESSION = secure($_SESSION);
$_COOKIE = secure($_COOKIE);
function secure($bad_array){
foreach($bad_array as $key => $value){
switch ($key){
case 'id':
case 'm_id'://Haupt IDs
$secure_array[$key] = intval($value);
default:
if(get_magic_quotes_gpc()){
$secure_array[$key] = stripslashes($value);
}
$secure_array[$key] = mysql_real_escape_string($value);
}
}
return $secure_array;
}

Alles anzeigen

dynambee · 5. November 2008, 19:08

Habe gerade nur ein paar Minuten Zeit und hab deshalb nur mal schnell drüber gelesen. Dabei ist mir eins aufgefallen:

Quellcode

if(get_magic_quotes_gpc()){
$secure_array[$key] = stripslashes($value);
}
$secure_array[$key] = mysql_real_escape_string($value);

Muss doch eher wie folgt heißen:

Quellcode

if(get_magic_quotes_gpc()){
$value = stripslashes($value);
}
$secure_array[$key] = mysql_real_escape_string($value);

Torben Brodt · 5. November 2008, 19:26

Ich setze PHP in Version 5 inzwischen überall voraus. Daher arbeite ich nur noch mit dem PDO.
Keine Ahnung ob du auf Abwärtskompatiblität achten musst - Falls nicht, dann steige auch aufs PDO um.

Lemmi · 5. November 2008, 21:57

PHP 5 auf allen Servern, auf denen ich arbeiten muss, voraussetzen zu können, ist ein Traum. Aber gerade wenn du Kunden bekommst, die sparen wollen oder überhaupt keine Ahnung haben und sich dann selbst einen Server zugelegt haben, ist die Sache echt schwierig.

Hier zwei vielleicht hilfreiche Links:
php.net/manual/de/security.database.sql-injection.php
php.net/manual/de/function.mysql-real-escape-string.php

Aber im Grunde wurde hier schon viel richtiges genannt. Selbst der Tipp von d0nut ist im Glücksfall wohl der beste.

eseL · 6. November 2008, 11:03

Ich tummel mich auch mal dazu... Bin nun nicht wirklich fitt im Coden aber ich tu alle Formulareingaben mit real_escape_string prüfen...

also ich frage euch mal ob das genug sicherheit bietet oder ob ich meine daten anders prüfen sollte.. ich mach das so z.b:

Quellcode

$_POST['passwort'] = mysql_real_escape_string($_POST['passwort']);

is das ausreichend? oder wie soll ich besser sichern?

edit: außerdem gibts niemals zugriff auf die mysql tabelle "users" (wär auch doof ^^) und ich für die online anwendungen immer nur benutzer mit readonly rechten ausstatte. dazu werden passwörter als md5 hash gespeichert.

Lemmi · 6. November 2008, 18:19

Vor Injections bist du damit auf jedenfall schon mal sicher. Ansonsten gibt es die geposteten Informationen aus den letzten Beiträgen, die sich dazu äußern, und natürlich Google, aber das kennt man ja.

student2312 · 6. November 2008, 18:23

Hab mich mal ein bisschen in PDO eingelesen, und das scheint echt eine gute Sache zu sein. Ich werde das mal ausprobieren!

MySQL Injection, wie am besten schützen

MySQL Injection, wie am besten schützen

Quellcode

marcel schrieb:

Quellcode

Quellcode

Quellcode

Quellcode

Teilen

Benutzer online 9

Tags