Ist „mysql_real_escape_string()' wirklich sicher gegen SQL-Injection oder gibt es subtile Schwachstellen?

Ist mysql_real_escape_string() fehlerfrei?

Obwohl mysql_real_escape_string() häufig zum Schutz vor SQL-Injection-Angriffen eingesetzt wird, kann es umgangen werden, wenn auch in seltenen und komplizierten Fällen.

Das Geniale Angriff

Mit einer sorgfältig erstellten Nutzlast in einem hochspezifischen Zeichensatz kann mysql_real_escape_string() ausgenutzt werden. Hier ist eine Aufschlüsselung:

1. Zeichensatzauswahl: Der Verbindungszeichensatz des Servers muss auf einen eingestellt sein, der sowohl einen ASCII-Backslash ('') als auch ein Zeichen unterstützt, dessen letztes Byte ein ASCII ' ist. Beispielsweise erfüllt „gbk“ dieses Kriterium.
2. Nutzlast: Es wird eine Nutzlast ausgewählt, die aus der Bytesequenz „0xbf27“ besteht. In „gbk“ ist es ein ungültiges Zeichen, während es in „latin1“ „¿“ darstellt.
3. mysql_real_escape_string(): MySQLs Implementierung dieser Funktion erkennt den Verbindungszeichensatz ( in diesem Fall „gbk“) und wendet Escape gemäß seinen Regeln an. Der Client geht jedoch immer noch davon aus, dass die Verbindung „latin1“ verwendet. Wenn daher die Bytesequenz mit „mysql_real_escape_string()“ maskiert wird, wird ein Backslash eingefügt.
4. Die Abfrage: Die resultierende Zeichenfolge enthält ein frei hängendes '-Zeichen: '縗' ODER 1=1 /*' in 'gbk'. Dies ist die bösartige Nutzlast, die für den Angriff benötigt wird.

The Glaring Vulnerabilities

1. PDO-emulierte Anweisungen:PDO emuliert standardmäßig vorbereitete Anweisungen mit mysql_real_escape_string(), was es dafür anfällig macht Angriff.
2. mysql_real_escape_string() Fehler: Vor MySQL 4.1.20 und 5.0.22 hatte mysql_real_escape_string() einen Fehler, der ungültige Multibyte-Zeichen als einzelne Bytes behandelte, selbst wenn der Client dies tat über die korrekte Verbindungskodierung informiert, was diesen Angriff ermöglicht erfolgreich sein.
3. Eingeschränkte Sicherheitsmaßnahmen von PDO: Der in PHP ≥ 5.3.6 eingeführte DSN-Zeichensatzparameter von PDO wird nicht durchgängig für alle Befehle unterstützt. Dies lässt Spielraum für Ausnutzbarkeit.

Die Schatten zerstreuen

1. Sichere Zeichensätze: Die Verwendung unverwundbarer Zeichensätze wie „utf8“ oder „utf8mb4“ mildert Dieser Angriff.
2. NO_BACKSLASH_ESCAPES SQL Modus: Das Aktivieren dieses Modus ändert die Funktionsweise von mysql_real_escape_string() und verhindert die Erstellung gültiger Zeichen in anfälligen Codierungen.
3. Moderne MySQL-Versionen und vorbereitete Anweisungen: MySQL-Versionen 5.1 (später) , 5.5 und höher sowie echte vorbereitete Anweisungen (z. B. in MySQLi) sind dagegen immun ausnutzen.

Zusammenfassend lässt sich sagen, dass mysql_real_escape_string() zwar im Allgemeinen effektiv ist, in bestimmten Szenarien jedoch umgangen werden kann. Moderne Versionen von MySQL, geeignete Zeichensatzauswahl und echte vorbereitete Anweisungen gewährleisten vollständigen Schutz vor diesem komplizierten Angriff.

Das obige ist der detaillierte Inhalt vonIst „mysql_real_escape_string()' wirklich sicher gegen SQL-Injection oder gibt es subtile Schwachstellen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!