mysql_real_escape_stringの主な欠点 、または一般的なmysql_拡張機能の場合、他の最新のAPI、特にプリペアドステートメントよりも正しく適用するのが難しいということです。 mysql_real_escape_string 引用符で囲まれたSQLステートメントの値として使用されるテキストコンテンツをエスケープするという1つのケースでのみ使用されることになっています。例：
$value = mysql_real_escape_string($value, $link);
$sql = "... `foo` = '$value' ...";
^^^^^^
mysql_real_escape_string $valueが 上記のコンテキストでは、SQL構文を台無しにすることはありません。あなたがここで考えるかもしれないようにそれは機能しません：
$sql = "... `foo` = $value ...";
またはここ：
$sql = "... `$value` ...";
またはここ：
$sql = mysql_real_escape_string("... `foo` = '$value' ...");
SQLステートメントで引用符で囲まれた文字列以外のコンテキストで使用される値に適用すると、誤って適用され、結果の構文が混乱したり、SQLインジェクション攻撃を可能にする値を送信できるようになる場合があります。 mysql_real_escape_stringのユースケース 非常に狭いですが、正しく理解されることはめったにありません。
mysql_real_escape_stringを使用してお湯に入るもう1つの方法 間違った方法を使用してデータベース接続エンコーディングを設定した場合です。これを行う必要があります：
mysql_set_charset('utf8', $link);
できます ただし、これも行います：
mysql_query("SET NAMES 'utf8'", $link);
問題は、後者がmysql_ APIをバイパスすることです。これは、latin1を使用してデータベースと通信していると見なします。 （または、他の何か）。 mysql_real_escape_stringを使用する場合 これで、データベースが後で解釈するのとは異なる方法で、間違った文字エンコードとエスケープ文字列を想定します。 SET NAMESを実行する クエリでは、mysql_ client APIが文字列を処理する方法と、データベースがこれらの文字列を解釈する方法との間に亀裂が生じています。これは、特定のマルチバイト文字列の状況でのインジェクション攻撃に使用できます。
mysql_real_escape_stringには基本的なインジェクションの脆弱性はありません 正しく適用されているかどうかを知っています。 繰り返しになりますが、主な問題は、誤って適用するのが非常に簡単であり、脆弱性が発生することです。