Hat mysql_real_escape_string () vollständig schützen vor SQL-Injection?

Question

http: // www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this gibt es einen Abschnitt, den Sie behauptet, kann mysql_real_escape_string mit bestimmten asiatischen Zeichenkodierungen umgehen

  

Umgehen mysql_real_escape_string () mit BIG5 oder GBK

     

"injection string"
  に 関 す る 追加 情報:

     

die oben genannten Zeichen sind Chinese Big5

Ist das wirklich wahr? Und wenn ja, wie würden Sie Ihre Website gegen diese schützen, wenn Sie keinen Zugriff auf vorbereitete Anweisungen hatte?

Answer 1

Nach Stefan Esser, "mysql_real_escape_string() [ist] nicht sicher, wenn SET NAMES verwendet wird."

Seine Erklärung, aus seinem Blog :

  

SET NAMES ist in der Regel verwendet, um die Codierung zu wechseln, was Standard ist, was die Anwendung benötigt.   Dies wird in einer Art und Weise geschehen, dass mysql_real_escape_string nicht darüber weiß. Das bedeutet, wenn Sie zu einem gewissen Multi-Byte-Codierung wechseln, die Backslash als 2. 3. 4. ermöglicht ... Byte Sie in Schwierigkeiten geraten, weil mysql_real_escape_string nicht richtig entweichen kann. UTF-8 ist sicher ...

     

Sichere Art und Weise Codierung zu ändern, ist mysql_set_charset, aber das ist nur in neuen PHP-Versionen verfügbar

Er erwähnt, dass UTF-8 ist sicher, though.

Answer 2

Dies ist ein MySQL-Server Fehler, der wie verlautet zurück Mai 2006 festgelegt wurde.

Siehe auch:

• MySQL Bug # 8303 : Stringliterale mit Multi-Byte-Zeichen enthalten \ sind gelext falsch
• MySQL Bug # 8317 : Zeichensatz Einführungs in Abfrage nicht außer Kraft setzen Verbindungszeichensatz
• MySQL Bug # 8378 : String entkam falsch mit Client-Zeichensatz ' GBK '
• MySQL 5.1.11 Changelog .

wurde der Bug gemeldet fixiert in MySQL 4.1.20, 5.0.22, 5.1.11.

Wenn Sie 4.1.x verwenden, 5.0.x oder 5.1.x, stellen Sie sicher, dass zumindest auf die kleineren Versionsnummern aktualisiert.

Als Abhilfe können Sie auch den SQL-Modus aktivieren NO_BACKSLASH_ESCAPES die Backslash als Zitat-Escape-Zeichen deaktiviert.

Answer 3

Ich bin mir ziemlich sicher, dass es nicht nur funktionieren, wenn Sie SQL verwenden, um die Zeichen-Kodierung zu ändern.

Answer 4

Wie andere haben gezeigt, mysql_real_escape_string() können in obskuren Rand Fällen umgangen werden. Das ist eine bekannte Strategie für die austretende Logik umgehen, aber es könnte auch andere unbekannte Schwachstellen sein, die noch nicht entdeckt haben.

Die einfache und effektive Art und Weise zu SQL-Injection in PHP verhindern zu verwenden ist Prepared Statements , wo Sie können und eine sehr strenge Weiße Liste, wo man nicht.

Prepared Statements, wenn tatsächlich verwendet und nicht durch den PDO-Treiber emuliert, sind beweisbar sichere (zumindest in Bezug auf SQL-Injection), da sie ein grundsätzliches Problem mit der Anwendungssicherheit zu lösen: Sie trennen die Daten aus den Anweisungen , die auf den Daten arbeiten. Sie sind in separaten Paketen gesendet; die parametrierten Werte nie eine Chance haben, den Query-String besudeln.

Es ist 2015 nicht mehr entkommen und verketten. Sie sollten sich trotzdem Ihre Eingaben nach Anwendung bestätigen (und wirtschaftlichen) Logik, sondern nur vorbereitete Anweisungen verwendet werden.