SQL-Injection

[Sasser]

Hallo Leute!

Ich versuche gerade mein System abzusichern, aber wenn ich einen String bevor ich ihn an den SQL-Interpreter übergebe an die mysql_real_escape - Funktion übergebe, maskiert er die ' trotzdem nicht!? Was mache ich falsch?

Also vor der SQL-Abfrage mache ich folgendes:

$value = mysql_real_escape_string($value);

 

[splasch]

Ich versuche gerade mein System abzusichern, aber wenn ich einen String bevor ich ihn an den SQL-Interpreter übergebe an die mysql_real_escape - Funktion übergebe, maskiert er die ' trotzdem nicht!? Was mache ich falsch?

Falsch machst du das die alten sachen immer noch verwendest. Auser du möchtest was für System mit php 3 oder php4 schreiben.

Wenn du php 5 verwendest dann würd ich dir Raten die neuen Funktionen zu nutzen die sind um einiges sicherer gegen Sql injection als die Alten.

Daher verwende PDO oder Mysqli

Stichwort:

prepare
bind_param

Beispiele findest unter:
http://at.php.net/manual/de/mysqli-stmt.prepare.php

Oder für PDO
http://at.php.net/manual/de/class.pdo.php

Mfg Splasch

 

[Gumbo]

Falsch machst du das die alten sachen immer noch verwendest.

Was soll daran falsch sein? Nur weil es vielleicht nicht deiner Auffassung vom Stand der Technik ist, ist es noch lange nicht falsch.
Wenn einem die Anatomie von SQL-Injektionen und der richtigen Nutzung der mysql_real_escape_string()-Funktion bewusst ist, kann man damit genau so sichere SQL-Abfragen schreiben wie mit Prepared Statements.

 

[splasch]

Wenn einem die Anatomie von SQL-Injektionen und der richtigen Nutzung der mysql_real_escape_string()-Funktion bewusst ist, kann man damit genau so sichere SQL-Abfragen schreiben wie mit Prepared Statements.

Nein das ist nicht genau so Sicher. Es gibt lücken mit denen man das Escapen umgehen kann.

Mfg Splasch

 

[Gumbo]

Nein das ist nicht genau so Sicher. Es gibt lücken mit denen man das Escapen umgehen kann.

Und zwar welche?

 

[splasch]

Da gibst einige Methoden lies dir einfach die Securty berichte durch. Es ist einigen Hackern gelungen das auszuhebeln.
Auserdem sollte man aus Sicherheits gründen die Methoden nicht nennen sonst gibst wieder Zahlreiche script kids die das gleich Ausnutzen wollen.

Eine Methode ist wenn ich mich jetzt nicht irre war die Url code Schreib weise.
Das Bedeutet die Befehle werden in der Maschienen Sprache geschrieben und nicht im klar text. Dadurch werden Escap zeichen garnicht erst erkannt. Diese kann man dann per Get oder Post übergeben um den Sql befehl einzuschleusen.

Bei bind_param ist dies nun auch nicht mehr Möglich da der Teil vom Sql Teil getrennt behandelt wird.

Mfg Splasch

 

[Gumbo]

Da gibst einige Methoden lies dir einfach die Securty berichte durch.

Welche genau meinst du mit „die Security-Berichte“?

 

[splasch]

Hab den link momentan nicht zur Hand aber da gibst viele Internet Seiten die sich nur mit dem Thema beschäftigen. Meisten sind die aber in Englisch.

Ansonsten kanste dir auch mal die Zeitschrift Hakin9 anschauen dort werden auch alle möglichen Sicherheitslücken aufgelistet.
Manchmal linux ,php,mysql unsw. je nach ausgabe gehts da um andere Gebiete.

Mfg Splasch

 

[GelbesKüken]

Das Bedeutet die Befehle werden in der Maschienen Sprache geschrieben und nicht im klar text. Dadurch werden Escap zeichen garnicht erst erkannt. Diese kann man dann per Get oder Post übergeben um den Sql befehl einzuschleusen.

Ähhhh ich habe da gerade etwas glaub ich nicht ganz verstanden...
Du meinst also das er die "Escap zeichen" nicht erkennt ? Der Trick ist doch bei sql, etwas zu umgehen indem man Zeichen einschleust, doch mit 0 und 1 allein, was ja eig nur Zustände sind, kann ja gar nichts mitgeliefert werden und wenn dann ist es in der db aber in der Zeile wo es hin sollte.
Und die HAKIN9 empfiehlt sogar den Gebrauch der Funktion Ausgabe 2/2008 (32) Seite 36 Ab Titel Schutzmaßnahmen.
Ich denke du prahlst mit wissen, welches nur ein Halbwissen ist.

Also wenn du mir einen Link geben kannst, welcher deine Aussage beweißt, lass ich mich gern belehren, denn dann werde ich meine Anwendungen eines älteren Semesters umschreiben müssen. Solange .... .
Und sag jetzt nicht, das ist zu gefährlich einfach weiter zu geben, wir sind hier unter ern und man sollte doch schon wissen vor was man sicher schützen muss und wie man es kann. Dieses geht am einfachsten, wenn man den Angriff analysieren kann. Und ja ich habe gegoogelt, auch etwas gefunden, was aber scheinbar schon gelöscht wurde....

 

[splasch]

Ich muß hier überhaupt nix beweisen!
Und ja du hast es nicht verstanden und das ist auch so gut.Den Leute wie du sind die ersten die versuchen dies dann auszunutzen (script Kids).

Soviel will ich dir noch verraten es handelt sich nicht um eine Binär Schreibweise. Url Code schaun da etwas anderes aus Bsp. %23 unsw.
Wobei das nicht die einzige Schreibweise ist wie man Escape Zeichen umgehen kann.

Nun ob du deine Scripte umschreibst oder nicht bleibt allein dir überlassen.

Und die HAKIN9 empfiehlt sogar den Gebrauch der Funktion Ausgabe 2/2008 (32) Seite 36 Ab Titel Schutzmaßnahmen.

Warum auch sollte man keine Schutzmaßnahmen empfehlen?
Ein wenig Schutz ist immer noch besser als garkein Schutz!
(Bei php4 gibst leider noch nicht die besseren Schutz methoden viele sind erst ab php5 möglich.)

Und sag jetzt nicht, das ist zu gefährlich einfach weiter zu geben, wir sind hier unter ern und man sollte doch schon wissen vor was man sicher schützen muss und wie man es kann. Dieses geht am einfachsten, wenn man den Angriff analysieren kann

Wie man sich davor Schützen kann hab ich bereits genannt dazu muß man nicht alle Angriff Methoden kennen.
Du mußt einfach nur Aktzeptieren das es so ist.

(PDO oder Mysqli richtig angewand bieten hier deutlich den besseren Schutz)

Der Grund hierfür liegt bei der Trennung zwischen Werten von Aussen und dem Sql befehl. Einige Sprechen sogar davon das dadurch nun die Methoden imum sei gegen Sql injection.
Da für die Trennung ein eigener Treiber verwendet wird. Der explizit sagt das dieser Teil nicht als sql befehl zu prasen ist.

Hier noch ein kleine Anleitung wie man PDO einsetzt:
http://www.php-resource.de/handbuch/ref.pdo.htm

Mfg Splasch