その文字列はセーフ？ 本当は奥深いデコード処理：もいちどイチから！ HTTP基礎訓練中（4）（3/3 ページ）

制御文字がデコードできてしまうということは

　　　　　　　　　　　　　　　　　　　　　 　＠IT messenger v1.4

クウ　……ふむふむ。なるほど

ジュン　特に最近話題になってるのは、バイナリセーフな関数とかバイナリセーフじゃない関数とかを交ぜこぜで使うと困ったことになる、ってとこかなぁ。

クウ　バイナリセーフ……ですか？ 言葉は聞いたことあるけど……。

ジュン　んっと。バイナリをちゃんとバイナリとして扱えるってのが、バイナリセーフかな？

クウ　ふむ……。

ジュン　制御文字とかが交ざってるときに、文字列として扱わないと困るときがあるからねー。

クウ　むむむ……

ジュン　具体的な例の方がいいよね。特に問題になることが多いのは、%00のNULL文字かな。

クウ　NULL文字っすか。それならギリギリ分かりそうっすね。

　制御文字の中でも特に「%00」などで表すことができるNULL文字を、Webアプリケーションに渡される文字列の中に混入することで、意図しない動作を引き起こす可能性がある。バイナリセーフの場合、NULL文字も文字として扱われるが、非バイナリセーフの場合、NULL文字を「文字列の終了」と見なしてしまうため、以降の文字を扱えず、この挙動の差から問題が発生する。

入力と処理、それぞれの「バイナリセーフ」

　例えば、Webアプリケーション内で利用されている関数に、バイナリセーフの関数と非バイナリセーフの関数が混在している際に「abcd%00efg」という文字列が渡されたとすると、以下のような挙動となってしまうことが想定される。ここでは、例として、「入力チェック」と「処理の実行」を対にして説明を行うが、この限りではない。

　入力チェックで、NULL文字以降の文字列「efg」が入力チェックを通過する条件になっている場合（例えば後方一致など）に、処理の実行で本来あるべきNULL文字以降の文字列が存在しないため想定外の動作となる可能性が存在する。

　非バイナリセーフの関数を用いた入力チェックでは、NULL文字以降がないものとされ、不正な文字が混入していても検知することができなくなる。しかし、入力チェックの後に同じ文字列に対しバイナリセーフの関数を使用すると、NULL文字以降に不正な文字が挿入されている場合、想定外の動作を行う可能性がある。

　バイナリセーフ、非バイナリセーフの関数が混在していない場合でも、入力された文字列の後方に特定の文字列を追加することで処理の制御を行っている場合（例えばファイルの拡張子など）、非バイナリセーフの関数に与えられた際にその制限を回避されてしまうこととなる。

　また、NULL文字だけではなく改行（%0d%0a）のような制御文字で問題が発生する場合も多く存在する。

　このような問題が起きないようにするために、制御文字が混入することを想定し、バイナリセーフか否かを意識する必要がある。しかし、すべての関数について把握するのは非常に困難となるため、実際に制御文字がどのように扱われるかを試してみるのもよいだろう。

　　　　　　　　　　　　　きょうの格言

　　　　パーセントエンコードを軽視することなかれ！

　

　　　　　　　　　パーセントエンコードについて、

　　　　　　　入力が可能な文字について正しく理解し、

　　　　Webアプリケーションが誤作動を起こさないようにしよう。