ヌルバイト攻撃の対策について

ヌルバイト攻撃の対策について教えて下さい。
一般的な"\0"を削除する方法なのですが、以下の場合ですと問題無ありません。が、
$arr = "abc\0def";
if (mb_strpos($arr, "\0")) {
$arr = str_replace("\0", "", $arr);
}
echo $arr;
※結果：abcdef

POST送信された値には、全く反応しません。
$arr = $_POST["arr"];//送信データは"abc\0def"
if (mb_strpos($arr, "\0")) {
$arr = str_replace("\0", "", $arr);
}
echo $arr;
※結果：abc\0def
スクリプトコードはUTF-8で、magic_quotes_gpcはOffです。
他にどこをチェックすればよいかわからず投稿しました。
チェックすべきところを教えていただけないでしょうか？
宜しくお願いいたします。

No.5 ベストアンサー 回答者： hrm_mmm 回答日時： 2009/09/08 20:53

formの入力欄に文字列として\0を入れたのならurlencodeされて、%5C0　となります。

受信した時は、urldecode して文字\と文字0になるのでヌルバイトではありません。htmlにphpでヌルバイトを書き出してもブラウザ(operaでしかチェックしてませんが)は、その文字を無視します。データの終わりと認識するので。
$_POST をvar_dumpしてみるとよいです。
本当に悪意のあるプログラムからヌルバイトが送信されていたのなら、削除法は、ご呈示のコード str_replaceで出来ます。が、if文は必要ないとおもいます、該当文字が無ければ置き換えが行われないだけですし。また、該当文字が先頭にあった場合、0が返り、スルーされてしまいますので。もしif文で文字位置を調べるなら !== false でチェックすべきです。

この回答へのお礼

こんばんはhrm_mmmさん。
そういう事だったんですね。
とりあえずは問題無かったということで一安心です。
勉強になりました。
ありがとうございました。

お礼日時：2009/09/08 21:16

No.4 回答者： march4 回答日時： 2009/09/08 19:09

＞間違いは無いと思うのですが・・・

設定方法的には問題なさそうですが、
何らかの理由で、
「結果的にその指定が、効いてない」場合も考えられますので、
大事なのは、
そのスクリプトにおいて、
「実際に効いているのか、効いていないのか」
を確認することかな、と思います。

よって、以下の方法で確認頂くとして。
（※phpinfo();によっても確認できますが。）

get_magic_quotes_gpc();
→magic quotes gpc の現在の設定を得る
（http://php.benscom.com/manual/ja/function.get-ma …）

//そのスクリプトにおける「magic quotes gpc」の設定をチェック
//１：on　0：off
echo get_magic_quotes_gpc();

ここにも問題がないとなると、困りましたね＾＾；

ちなみに、POSTする値は、
「\0」以外にも、他の記号もエスケープされるのでしょうかね。

ダブル、シングルのクオテーションもエスケープされたり？
情報が多ければ、それだけ、レスも付きやすいかなと…。＾＾

この回答への補足

>echo get_magic_quotes_gpc();
結果は0でした。

>ダブル、シングルのクオテーションもエスケープされたり？
入力した状態でそのまま表示されますので、エスケープされていない状態かと思います。

補足日時：2009/09/08 19:26

この回答へのお礼

他のサーバーでも試してみましたが、同じ結果でした。
違う結果がでれば、何かヒントが得られるかと思ったのですが、なかなか手強いですね。
もう少しがんばってみます。
いろいろとありがとうございました。

お礼日時：2009/09/08 20:55

No.3 回答者： march4 回答日時： 2009/09/08 16:37

ちょっと補足を・・・

＞ということは、ポストされた値は何らかの処理がされていると考えるべきでしょうか？

つまり、POST経由の場合、POSTで受け取った後の時点で、
「\0」が既に無害化（文字列の「\0」へと変えられてしまっている）ということなのだと思います。
しかし、「magic_quotes_gpcはOffです。」とのことなので…
なんらかの経路で、無害化が行われていると思われます。

本当に、magic_quotes_gpcはOffになっておりますでしょうか。
phpinfo()で、今一度確認されてみてはいかがでしょう？

ちなみに、テストサーバのphp.iniと、運用サーバのphp.iniで、
設定が異なることも考えられます。
そのあたりのケアレスミスなども、疑ってみると良いと思います。

このような偉そうなことを書いてますが、
私自身、それほど詳しい人間ではないので、
あくまで、参考程度にお読み下さい。^^；
変なことを言っている可能性は「大」ですから。笑

この回答への補足

何度もありがとうございます。
.htaccessで指定してあり、.htaccessは対象ディレクトリに設置してあります。
php_flag magic_quotes_gpc Off
間違いは無いと思うのですが・・・

>なんらかの経路で、無害化が行われていると思われます。
やはり、これが一番疑わしいのでしょうか？
無害になっていれば、問題は無いと思いますが、原因がわからないと気持ち悪いですね。

補足日時：2009/09/08 17:54

No.2 回答者： march4 回答日時： 2009/09/08 16:21

こちらが参考になる気がします。

ttp://d.hatena.ne.jp/elseif/20080421/1208604585

上記ページをもとに、簡単にお話しすると、
注目すべきは、クオテーションです。

POSTでキャッチする値に含まれる「\0」をサニタイズ（洗浄）したいのであれば、
$arr = str_replace('\0', "", $arr);
と、シングルクオテーションで「\0」をくくれば、
希望とする結果が得られると思います。

「\0」は、
ダブルクオテーションでくくると、展開されてヌルバイトとして機能し、
シングルでくくると、展開されずに文字列として扱われるようです。

この回答への補足

お返事が遅くなりました。
シングルクオテーションは何度も試しましたが（もちろん今一度試しましたが）、結果は同じでした。

補足日時：2009/09/08 17:46

No.1 回答者： march4 回答日時： 2009/09/08 14:45

回答にはなっていないかもしれませんが、

$arr = "abc\0def";

//$arr = "abc\0def";をチェック
echo var_dump($arr);
echo '<br>';
echo mb_detect_encoding($arr);
echo '<br>';

//--------------------------------------

//ポストで受け取った値をチェック
echo var_dump($_POST["arr"]);
echo '<br>';
echo mb_detect_encoding($_POST["arr"]);
echo '<br>';

//--------------------------------------

として、両者を比較し、
データの型とか、文字コードの種類などに違いがないか、
チェックされてみたらいかがでしょうか。

同じ文字列であるはずの両者で、結果が異なるわけですから、
恐らく、両者の文字列で何らかの違いが生じているのでは、
と私は思います。

以上、参考までに。＾＾

この回答への補足

こんにちはmarch4さん。
ありがとうございました。

以下、結果です。
> $arr = "abc\0def";

> //$arr = "abc\0def";をチェック
> echo var_dump($arr);
> echo '<br>';
> echo mb_detect_encoding($arr);
> echo '<br>';
string(7) "abc�def"
UTF-8

> //ポストで受け取った値をチェック
> echo var_dump($_POST["arr"]);
> echo '<br>';
> echo mb_detect_encoding($_POST["arr"]);
> echo '<br>';
string(8) "abc\0def"
UTF-8

ポストされてない方は文字化けしていません。
ということは、ポストされた値は何らかの処理がされていると考えるべきでしょうか？

補足日時：2009/09/08 15:16