Wady mysql_real_escape_string?

Główna wada mysql_real_escape_string , lub ogólnie rozszerzenia mysql_, jest to, że jest trudniejsze do prawidłowego zastosowania niż inne, bardziej nowoczesne interfejsy API, zwłaszcza przygotowane instrukcje. mysql_real_escape_string ma być używany dokładnie w jednym przypadku:ucieczka treści tekstowej, która jest używana jako wartość w instrukcji SQL między cudzysłowami. Np.:

$value = mysql_real_escape_string($value, $link);
$sql = "... `foo` = '$value' ...";
                     ^^^^^^

mysql_real_escape_string upewnia się, że $value w powyższym kontekście nie psuje składni SQL. To nie działa tak, jak myślisz tutaj:

$sql = "... `foo` = $value ...";

lub tutaj:

$sql = "... `$value` ...";

lub tutaj:

$sql = mysql_real_escape_string("... `foo` = '$value' ...");

W przypadku zastosowania do wartości, które są używane w kontekście innym niż łańcuch w cudzysłowie w wyrażeniu SQL, jest on niewłaściwie zastosowany i może zepsuć wynikową składnię i/lub pozwolić komuś na przesłanie wartości, które mogą umożliwić ataki typu SQL injection. Przypadek użycia mysql_real_escape_string jest bardzo wąski, ale rzadko jest poprawnie rozumiany.

Inny sposób na wejście do gorącej wody za pomocą mysql_real_escape_string ma miejsce, gdy ustawisz kodowanie połączenia z bazą danych przy użyciu niewłaściwej metody. Powinieneś to zrobić:

mysql_set_charset('utf8', $link);

możesz rób to także:

mysql_query("SET NAMES 'utf8'", $link);

Problem polega na tym, że ten ostatni omija API mysql_, które nadal myśli, że rozmawiasz z bazą danych za pomocą latin1 (albo coś innego). Podczas korzystania z mysql_real_escape_string teraz przyjmie nieprawidłowe kodowanie znaków i łańcuchy ucieczki inaczej niż baza danych będzie je później interpretować. Uruchamiając SET NAMES zapytanie, stworzyłeś rozdźwięk między tym, jak interfejs API klienta mysql_ traktuje ciągi znaków, a tym, jak baza danych będzie je interpretować. Może to być użyte do ataków wstrzykiwania w niektórych sytuacjach z wielobajtowymi ciągami.

W mysql_real_escape_string nie ma podstawowych luk dotyczących wstrzykiwania wiem, czy jest stosowany prawidłowo. Ponownie jednak głównym problemem jest to, że przerażająco łatwo jest go niewłaściwie zastosować, co otwiera luki.