mysql_real_escape_string() と mysql_escape_string() は MySQL アプリケーションを保護するのに十分ですか?

MySQL セキュリティ: mysql_real_escape_string() と mysql_escape_string() は適切ですか?

アプリケーション セキュリティに対する mysql_real_escape_string() と mysql_escape_string() の有効性いくつかの議論を引き起こしました。これらの関数は既知の SQL インジェクション ベクトルを防止しますが、その制限により、より高度な攻撃に対して脆弱になる可能性があります。

SQL インジェクションの脆弱性

mysql_real_escape_string() を使用しているにもかかわらず、 PHP 変数がクエリに統合されているシナリオでは、依然として SQL インジェクションの影響を受けやすくなります。たとえば、次のコードを考えてみましょう:

<code class="php">$sql = "SELECT number FROM PhoneNumbers " .
       "WHERE " . mysql_real_escape_string($field) . " = " . mysql_real_escape_string($value);</code>

高度なハッカーは、次の入力でこのクエリを悪用する可能性があります:

<code class="php">$field = "1=1"
$value = "1"</code>

これにより、意図されたロジックがバイパスされ、代わりに (潜在的に) すべてのレコードが返されます。

LIKE 攻撃

mysql_real_escape_string() は、次のような LIKE 攻撃を防ぐのには効果がありません。

<code class="php">$sql = "SELECT number FROM PhoneNumbers " .
       "WHERE " . mysql_real_escape_string($field) . " LIKE " . mysql_real_escape_string($value);</code>

A悪意のあるユーザーが $value を % に設定してすべてのレコードを取得すると、機密データが公開される可能性があります。

文字セットの悪用

Internet Explorer は、2011 年現在でも、文字セットの悪用に対して脆弱なままです。この脆弱性により、SQL インジェクションと同様に、攻撃者がデータベースを制御できるようになる可能性があります。

準備されたステートメント: プロアクティブなアプローチ

mysql_real_escape_string() と mysql_escape_string() の両方が脆弱です。それらは事後的な防御メカニズムです。一方、準備されたステートメントは、プロアクティブなソリューションを提供します。プリペアド ステートメントは、有効でプログラムされた SQL のみを実行するため、基礎となるデータベースの脆弱性に関係なく、予期しない SQL が実行されるリスクを大幅に軽減します。

プリペアド ステートメントを使用した例を次に示します。

<code class="php">$statement = $pdo->prepare('SELECT url FROM GrabbedURLs ' .
                           'WHERE ' . $column . '=? ' .
                           'LIMIT ' . intval($limit));
$statement->execute(array($value));</code>

準備されたステートメントは安全であり、mysql_real_escape_string() を使用する場合よりも冗長ではありません。既知および未知の脅威から身を守るために、データベース サーバーの保護手段に依存しています。

以上がmysql_real_escape_string() と mysql_escape_string() は MySQL アプリケーションを保護するのに十分ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。