MySQL Injection, wie am besten schützen

Professional

Thursday, August 9th 2007, 6:16pm

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

Master

Posts: 1,134

2

Thursday, August 9th 2007, 7:14pm

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

Administrator

Posts: 8,454

3

Thursday, August 9th 2007, 7:39pm

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 - mysqli_stmt_bind_param
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: http://de.wikipedia.org/wiki/SQL-Injektion

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

BendIt

Professional

Posts: 287

4

Friday, August 10th 2007, 2:41pm

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

	PHP Quellcode
1	$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

melwood

Professional

Posts: 343

5

Friday, August 10th 2007, 3:29pm

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.

melwood

SeBa

Master

Posts: 1,134

6

Friday, August 10th 2007, 7:45pm

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

Professional

Posts: 287

7

Friday, August 10th 2007, 8:18pm

Quoted

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

Master

Posts: 1,134

8

Saturday, August 11th 2007, 1:22pm

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

Professional

Posts: 216

9

Saturday, August 11th 2007, 2:25pm

mkay thx das sind doch schonmal ein paar hilfen

BennyBunny

Master

Posts: 966

10

Sunday, August 12th 2007, 1:33pm

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.

Latest blogs: Oracle übernimmt Sun, Java SE 6 Update 12 verfügbar, Java 1.6.0 Update 10

marcel

Professional

Posts: 216

11

Thursday, August 16th 2007, 5:19pm

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

melwood

Professional

Posts: 343

12

Friday, August 17th 2007, 8:49am

Quoted from "marcel"

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.

melwood

marcel

Professional

Posts: 216

13

Monday, August 27th 2007, 4:33pm

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

Intermediate

Posts: 121

14

Wednesday, November 5th 2008, 5:33pm

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:

PHP 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;
}

This post has been edited 2 times, last edit by "student2312" (Nov 5th 2008, 5:56pm)

dynambee

Professional

Posts: 291

15

Wednesday, November 5th 2008, 7:08pm

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

PHP 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:

PHP Quellcode

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

Torben Brodt

Administrator

Posts: 8,454

16

Wednesday, November 5th 2008, 7:26pm

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.

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

Lemmi

Professional

Posts: 651

17

Wednesday, November 5th 2008, 9:57pm

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:
http://www.php.net/manual/de/security.da…l-injection.php
http://www.php.net/manual/de/function.my…cape-string.php

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

eseL

Intermediate

Posts: 108

18

Thursday, November 6th 2008, 11:03am

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:

	PHP Quellcode
1	$_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

Professional

Posts: 651

19

Thursday, November 6th 2008, 6:19pm

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.