状況によっては、1 行以上が返されることがあります。ここで何が起こっているのか分析してみましょう。

1. 文字セットの選択

   $pdo->query('SET NAMES gbk');
   

   この攻撃が成功するには、サーバーが接続時に想定しているエンコーディングが'ASCII でエンコードされていること (つまり ) 0x27 、および最終バイトが ASCII である文字が含まれていること (つまり )\が必要0x5cです。MySQL 5.6 では、デフォルトで 、 、 、 の 5 つのエンコーディングがサポートされています。big5ここcp932でgb2312はgbk選択sjisしますgbk。

   ここで、 の使用に注意することが非常に重要です。これにより、サーバー上のSET NAMES文字セットが設定されます。これを行う別の方法もありますが、すぐに説明します。

2. ペイロード

   このインジェクションに使用するペイロードは、バイト シーケンス で始まります0xbf27。 ではgbk、これは無効なマルチバイト文字です。 ではlatin1、これは文字列 です¿'。latin1 および gbkでは、0x27それ自体はリテラル'文字であることに注意してください。

   このペイロードを選択したのは、これを呼び出すと、文字の前にaddslashes()ASCII が挿入されるから\です。その結果、 になり、これは2 つの文字シーケンス の後に が続きます。つまり、有効な文字の後にエスケープされていない が続きます。ただし、 は使用しません。それでは、次のステップに進みます...0x5c'0xbf5c27gbk0xbf5c0x27'addslashes()

3. $stmt->実行()

   ここで理解しておくべき重要なことは、PDO はデフォルトでは実際に準備されたステートメントを実行しないということです。PDOはそれらをエミュレートします (MySQL 用)。したがって、PDO は内部的にクエリ文字列を構築し、mysql_real_escape_string()バインドされた各文字列値に対して (MySQL C API 関数を) 呼び出します。

   への C API 呼び出しは、接続文字セットを認識している点mysql_real_escape_string()で と異なりますaddslashes()。そのため、サーバーが期待する文字セットに対して適切にエスケープを実行できます。ただし、この時点では、クライアントは接続にまだ を使用していると考えています。これは、他の方法を指示していないためです。サーバーにを使用しているlatin1ことを伝えましたが、クライアントは依然としてであると考えています。gbklatin1

   したがって、 の呼び出しによってmysql_real_escape_string()バックスラッシュが挿入され、「エスケープされた」コンテンツに自由にぶら下がっている文字が存在します。実際、文字セットを'見ると、次のようになります。$vargbk

   縗' OR 1=1 /*

   まさにそれが攻撃に必要なことです。

4. クエリ

   この部分は単なる形式的なものですが、レンダリングされたクエリは次のとおりです。

   SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
   

おめでとうございます。PDO Prepared Statements を使用してプログラムへの攻撃に成功しました...

簡単な解決策

ここで注目すべきは、エミュレートされた準備済みステートメントを無効にすることでこれを防ぐことができるということです。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

これは通常、真の準備されたステートメント（つまり、クエリとは別のパケットでデータが送信される）になります。ただし、PDOは暗黙的に後退するMySQLがネイティブに準備できないステートメントをエミュレートします。リストされているマニュアルに記載されていますが、適切なサーバー バージョンを選択するように注意してください。

正しい修正方法

ここでの問題は、SET NAMESC APIの代わりにを使用していることですmysql_set_charset()。そうでなければ、攻撃は成功しません。しかし、最悪なのは、PDOがmysql_set_charset()5.3.6までC APIを公開していなかったため、以前のバージョンでは、あらゆるコマンドに対してこの攻撃を防ぐことができなかったことです。現在は、DSNパラメータ...の代わりに これを使用する必要があります。SET NAMES

これは、2006年以降のMySQLリリースを使用している場合に限ります。それ以前のMySQLリリースを使用している場合は、バグではmysql_real_escape_string()、ペイロード内の無効なマルチバイト文字は、クライアントが接続エンコーディングを正しく通知されていたとしても、エスケープの目的で1バイトとして扱われ、この攻撃は成功していました。このバグはMySQLで修正されました。4.1.20、5.0.22そして5.1.11。

救いの恵み

冒頭で述べたように、この攻撃が機能するには、データベース接続が脆弱な文字セットを使用してエンコードされている必要があります。utf8mb4脆弱性はなく、すべてのUnicode文字をサポートしているので、代わりにそれを使用することを選択できますが、MySQL 5.5.3以降でのみ利用可能です。代替案としては、utf8これも脆弱性がなく、Unicode全体をサポートできる。基本的な多言語面。

あるいは、NO_BACKSLASH_ESCAPESSQL モードは、（他の機能の中でも） の動作を変更しますmysql_real_escape_string()。このモードを有効にすると、はではなく に0x27置き換えられ、したがって、エスケープ処理では、脆弱なエンコーディングで以前に存在しなかった有効な文字を作成できません（つまり、はまだなど）。そのため、サーバーは文字列を無効として拒否します。ただし、0x27270x5c270xbf270xbf27@eggyal の回答この SQL モードの使用によって発生する可能性がある別の脆弱性 (PDO 以外)。

安全な例

次の例は安全です:

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();