Reicht htmlspecialchars aus, um eine SQL-Injektion einer in einfachen Anführungszeichen eingeschlossenen Variablen zu verhindern?
Lesezeit: 2 Minuten
gekerbt
Obwohl viele Quellen die zitieren htmlspecialchars Funktion mit ENT_QUOTES sein nicht genug, um eine SQL-Einschleusung zu verhindern, keiner von ihnen liefert einen Beweis für das Konzept. Ich selbst kann mir keine Möglichkeit vorstellen.
Betrachten wir das folgende Beispiel:
$username = htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');
$sql = "SELECT * from user WHERE name="$username"";
mysql_query($sql,...);
Kann jemand ein Beispiel geben, außer denen, die von dem Fall abgedeckt werden, wenn die SQL-Injektion mysql_real_escape_string () umgeht?
Was macht mysql_real_escape_string?
– Mohammed
1. März 14 um 16:50 Uhr
PHPs htmlspecialchars Die Funktion dient zum Escapezeichen von Zeichen mit besonderer Bedeutung zu einem Browser, wie z. B. spitze Klammern, damit sie als normale Zeichen erscheinen und nicht als HTML-Markup interpretiert werden. Es hat nichts mit SQL zu tun oder SQL-Injection zu verhindern.
– Wyzard
1. März 14 um 16:57 Uhr
Gumbo
Der Charakter das htmlspecialchars kann das kritische Zeichen nicht codieren (NUL-Byte), b (Rücktaste), sowie die Charakter.
Um dies auszunutzen, benötigen Sie eine Anweisung mit mehreren Injektionspunkten. Damit können Sie das schließende Trennzeichen eines String-Literals maskieren und so bis zum nächsten beginnenden Trennzeichen des nächsten String-Literals erweitern. Drei String-Literale mit jeweils einem Injektionspunkt können dann in zwei String-Literale umgewandelt werden.
Beispielsweise:
SELECT * from user WHERE (name="$login" OR email="$login") AND password='$password'
Jetzt mit folgenden Werten:
login: ) OR 1=1 /*
password: */--
Die resultierende Anweisung sieht folgendermaßen aus:
SELECT * from user WHERE (name=") OR 1=1 /*" OR email=") OR 1=1 /*") AND password='*/--'
Was äquivalent ist zu:
SELECT * from user WHERE (name=") OR 1=1 /*" OR email=") OR 1=1
Strings sind nicht das Einzige, womit SQL interagiert.
$result = "SELECT * FROM user WHERE id = " . htmlspecialchars($_GET['id']);
Hier sind parametrisierte Abfragen sehr praktisch.
Auch mysql_real_escape_string hilft hier nicht. Dies ist also kein Argument, warum htmlspecialchars in diesem Vergleich unsicher ist.
– gekerbt
1. März 14 um 16:31 Uhr
@mithy Ja, deshalb sollten Sie parametrisierte Abfragen in MySQLi oder PDO verwenden. mysql_real_escape_string ist zusammen mit dem Rest von veraltet mysql_ Funktionen. Ich habe ein Beispiel für Ihre Frage bereitgestellt – eine Situation, in der htmlspecialchars bei Benutzereingaben macht die SQL-Abfrage nicht sicher. Die Frage wurde nicht erwähnt mysql_real_escape_string überhaupt.
– ceejayoz
1. März 14 um 16:34 Uhr
Ich denke, er erwartet welche Eingabe von $_GET[‘id’] kann zu SQL Injection führen, wenn htmlspecialchars wird mit verwendet ENT_QUOTES
– Manuel
1. März 14 um 16:36 Uhr
@Manu In diesem Beispiel $_GET['id'] Sein 1 OR 1=1 würde als Injektion funktionieren, und htmlspecialchars würde es überhaupt nicht beeinflussen.
– ceejayoz
1. März 14 um 16:38 Uhr
.
5014400cookie-checkReicht htmlspecialchars aus, um eine SQL-Injektion einer in einfachen Anführungszeichen eingeschlossenen Variablen zu verhindern?yes
Was macht mysql_real_escape_string?
– Mohammed
1. März 14 um 16:50 Uhr
PHPs
htmlspecialchars
Die Funktion dient zum Escapezeichen von Zeichen mit besonderer Bedeutung zu einem Browser, wie z. B. spitze Klammern, damit sie als normale Zeichen erscheinen und nicht als HTML-Markup interpretiert werden. Es hat nichts mit SQL zu tun oder SQL-Injection zu verhindern.– Wyzard
1. März 14 um 16:57 Uhr