Bin ich vor einer mysql-Injektion sicher? [Duplikat]

Ich denke, dass Sie zwei Sicherheitsprobleme verwirren: SQL-Injektion und Cross-Site-Scripting (XSS) .

Eine Website ist anfällig für SQL-Injection, wenn nicht ordnungsgemäß bereinigte Benutzereingaben in einer SQL-Abfrage verwendet werden, die an die SQL-Datenbank gesendet wird. Dieser Code führt zum Beispiel eine SQL Injection-Schwachstelle ein:

Dieses Problem lässt sich leicht beheben, indem die Benutzereingabe mit einer Funktion wie mysql_real_escape_string :

Das ist alles, was Sie tun müssen, aber der schwierige Teil besteht darin, sich daran zu erinnern, dies für jede Benutzereingabe zu tun, die in einer SQL-Anweisung verwendet wird.

Eine Website ist anfällig für Cross-Site-Scripting, wenn Benutzereingaben in HTML verwendet werden, die an einen Client gesendet werden. Dieser Code führt beispielsweise eine XSS-Sicherheitsanfälligkeit ein:

Eine XSS-Schwachstelle wird behoben, indem die Benutzereingabe mit einer Funktion wie htmlspecialchars entkoppelt wird :

Auch dies ist leicht zu tun, aber leicht vergessen.

Normalerweise werden Benutzereingaben, die in einer Datenbank gespeichert werden, um HTML zu einem späteren Zeitpunkt zurückzusenden, unverändert gespeichert. Das heißt, nur mysql_real_escape_string wird verwendet. Sie können jedoch Benutzereingaben umgehen, um XSS zu verhindern, und anschließend die XSS-sichere Zeichenfolge umgehen, um SQL-Injection zu verhindern:

Der Vorteil ist, dass Sie nicht vergessen müssen, Werte aus der Datenbank mit htmlspecialchars zu entfernen, bevor Sie sie in HTML schreiben. Der Nachteil ist, dass einige Werte mit verschiedenen Funktionen maskiert werden müssen. Zum Beispiel würde ein Benutzername wahrscheinlich mit htmlspecialchars maskiert, aber eine "postmessage" könnte BBcode, Markdown oder eine Teilmenge von HTML erlauben. Wenn Sie alle Eingaben maskiert haben, um XSS zu vermeiden, müssen Sie Werte aus der Datenbank mit z. B. htmlspecialchars_decode .

Ein Problem besteht darin, dass das Unscaping der gesperrten Zeichenfolge nicht immer die ursprüngliche Zeichenfolge zurückgibt ( unescape(escape($orig)) ist nicht unbedingt dasselbe wie $orig ). Selbst mit htmlspecialchars und htmlspecialchars_decode wird dieses Problem durch Verwendung eines anderen Anführungsstils verursacht. Ein anderes Beispiel ist, dass, wenn strip_tags verwendet wird, Informationen unwiederbringlich entfernt werden; Sie können strip_tags nicht rückgängig machen. Daher entscheiden sich viele Entwickler dafür, mysql_real_escape_string nur zum Speichern von Werten in der Datenbank und htmlspecialchars (oder was auch immer) zu verwenden, um eine Zeichenfolge aus der Datenbank vorzubereiten, die in HTML verwendet werden soll.

mysql_real_escape_string() ist die einzige Methode, die Sie hier brauchen.
Bevor Sie Daten in Ihre Datenbank einfügen, sollten Sie weder htmlentities() noch urlencode() ausführen. Bei diesen Methoden handelt es sich normalerweise um Code beim Rendern der Ansicht, die Sie Ihren Benutzern anbieten.

Eine bessere Möglichkeit, SQL Injection zu vermeiden, ist die Verwendung von vorbereiteten Anweisungen .

Ressourcen:

• php.net - Vorbereitete Aussagen mit PDO

Zum selben Thema:

• PHP: Ist mysql_real_escape_string ausreichend für die Reinigung Benutzereingabe?

Ja, aber es gibt einen Grund, mysql_real_escape_string () nicht zu verwenden. Zuerst ist es ein Schmerz zu tippen. Zweitens müssen Sie daran denken, es jedes Mal zu verwenden. Drittens macht es deinen Code hässlich. Viertens müssen Sie daran denken, Ihre Strings zu zitieren. Fünftens ist es schwieriger, auf diese Weise Blobs in eine db einzufügen.

PDO-Lernen wird Ihr Leben auf lange Sicht verbessern. Es ist schwieriger zu lernen als einfach mysql_real_escape_string () zu verwenden, aber die langfristigen Vorteile überwiegen die Unannehmlichkeit einer Lernkurve.