Datenbankqueries und Hochkommatas

M

milkboy

Aktives Mitglied
Ich habe ien kleines Gästebuch geschrieben. Jedesmal, wenn jemand ein Hochkomma eingiebt wird der Eintrag nicht zur Datenbank hinzugefügt.
Ich habe es mal mit folgendem Code versucht:

CODE $message = preg_replace("'", "\'", $message);


aber das funktioniert irgendwie nicht
sad.gif


kennt jemand dieses Problem?
 
Ich denke es ist genug str_replace für das.

str_replace("'","\\'",$message);

Josh, hat recht, für regular expressions musst du die expression mit slahes aufbauen /EXP/

Gruss
Steven


 
Beim Umgang mit Usereingabe und Hochkommas sollte vielleicht mal das Wort Sql Injection fallen.
Es besteht grundsätzlich die Möglichkeit über Usereingaben das SQL-Statement zu manipulieren, wenn man nicht Sicherheitsmassnahmen trifft.

Addslash alleine reicht übrigens nicht aus um alle Gefahren auszuschalten. Bsp.:
DELETE FROM article WHERE id = [parameter]
Über den User kommt der Parameter => 3 OR (1 = 1) sorgt da sicher für viel Spaß
blink.gif
ph34r.gif


Mehr dazu unter ist http://uk.php.net/manual/en/security.datab...l-injection.php nachzulesen.
 
@ hatschi:

Interessanter Einwand. Wäre es eine Lösung, einfach *alle* Parameter in Hochkommatas zu stellen?

DELETE FROM article WHERE id = '3 (OR 1=1)'

Damit wäre nix zu holen für den Hacker... Werde den Artikel mal durchlesen, danke für den Link.
 
Numerische Werte wie z.B. ID's filtere ich immer über intval(). Dadaurch erledigt sich eigentlich alles weitere..

Ich baue meine Query's wenn möglich so auf, dass soweit als möglich keine Strings ins Query kommen. Ich arbeite vorzugsweise praktisch nur mit ID's. Kommt ein String rein, wird er vorher escaped. Gab bis jetzt nie Probleme mit diesem Ansatz.
 
Escapen alleine reicht nicht, da habe ich auch schon Beispiele gesehen die das umgehen (z.B. mit \'):
SELECT id FROM article WHERE id = '\''; DROP TABLE users; --';

Schöne Beispiele:
http://www.unixwiz.net/techtips/sql-injection.html

Da gibt es auch Unterschiede zwischen den Datenbanken wie man die angreifen kann.

Im Endeffekt lohnt es sich wohl 2 Sicherheitsebenen zu haben:
1. Input validieren (Typ, Sonderzeichen, Länge)
2. SQL-Statement absichern

Die MySql-Experten unter uns können uns sicher beantworten warum es bei Zahlen nicht so sinnvoll ist im SQL-Statement quotes herumzugeben. Ich kann mich dazu jetzt nicht genau erinnern (schäm).

Mehr Lesestoff:
http://uk.php.net/manual/en/function.mysql...cape-string.php

Ich habe selbst erst kürzlich eine Mail Injection Attacke erleben dürfen, das hat mich daran erinnert, das sich Sicherheit doch lohnt.....
 
Interessanter Artikel, auch wenn Subselects in MySQL (noch) nicht möglich sind und mysql_query() immer nur ein einzelnes Query ausführt. Danke für den Link.
 
Soweit ich das überblicke kann ein Angreifer, der es schafft das SQL-Statement zu manipulieren, über union durchaus auch noch anderes (update und delete) ausführen.

Der Hauptpunkt ist diese Gefahr allgemein zu kennen, da man als Techniker wohl auch mal mit anderen Systemen zu tun haben wird. Die Prinzipien bleiben gleich, wobei hier leider auch einzelne Gefahren wohl unterschiedlich sind.
 
Also wenn das erste Query ein Select war, dann kann jedes weitere Union-Query auch nur ein Select sein, mit selbiger Spaltenzahl und Namen (bzw. Aliase). Alles andere wäre mit komplett neu und unlogisch.

Also ich finde den Einsatz von escape, bzw real_escape genügend. Bei Datensätzen, wo mit Sicherheit nur 1 Wort vorhanden sein wird, noch alles nach dem ersten Leerzeichen entfernen und gut ists. ID's mit intval filtern, da kann auch nichts schief gehen..
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben