「逆」にしたERBが登場27日の「(略)とかERBとか、逆だったらよかったのに」の件、大岩さんが、逆にしたERB改造版を作ってくれた。(2005-12-29)さて、使い勝手はどうだろうか。いるらしいので、結論から順に整理しなおしてみる。「サニタイズ」という言葉を使うのを避けてみてはどうか。説明することの困難から逃げようとしないで。万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄することを、サニタイズと言うのはかまわない。既存のシステムに応急手当としてCGIの入力段階でパラメタに処置をする場面では、サニタイズと言うのはかまわない。「サニタイズせよ」というスローガンは、「危険な文字列は削除する」のが本来的な対策であるかのように誤解させる。「危険な文字は変換する」のが本来的な対策であるかのように誤解させる。セキュアプログラミング編」における(B)の解説。エスケープしましょう」という大間違いな解説。削除という対策は別の危険をもたらす場合がある。「..././」が「../」に変換されて攻撃が成功してしまうという、対策の失敗。一部の脆弱性について、たしかに文字削除をするのが妥当な対策である場合もあるため、その削除処理が「サニタイズ」と呼ばれるようになり、次第に意味を拡大させて使用されるようになったのではないか。インジェクション系の脆弱性では、メタ文字をエスケープするのが正しい。パス名パラメタのチェックおよびディレクトリトラバーサルでは、異常時には例外処理に飛ばすのが正しい。「サニタイズせよ」というスローガンは、「CGIの入力パラメタに対して処置する」のが本来的な対策であるかのように誤解させる。CGIパラメタがプログラム中のどこでどのように用いられるかを把握せずに安全なプログラムにできるはずがなく、その把握は一般には困難である。「セカンドオーダーSQLインジェクション」(後述)。既存のシステムに応急手当としてCGIの入力段階でパラメタをサニタイズすることが、セキュリティ対策屋の仕事として普及したが、これが間違って、新規開発の場面でなすべきこと(セキュアプログラミング)として広まってしまったのではないか。「サニタイズする」という対策屋発想には、「不用意にプログラムの挙動を変えてはいけない」という背景があるように思える。入力段階ではなく「出力段階」で。「出力」というのは(出力というより)、問題を起こす場所。「サニタイズせよ」というスローガンは、「CGIの入力パラメタに依存した式に対してだけ処置すればよい」というプログラミング手法で十分であると思わせてしまう。書籍「PHPサイバーテロの技法—攻撃と防御の実際」における(C)のコード。書籍「PHPサイバーテロの技法—攻撃と防御の実際」における、cookieの値をHTML出力するときにエスケープするべきかを議論したコラム。サニタイズ漏れを起こしやすくなる。値を表示しようとした場合に、クロスサイトスクリプティング脆弱性を生みやすいことが古くから知られている。対策コードが整然とせず煩雑なものとなりやすいため、Webプログラミングの解説本で、対策を入れることが敬遠されがち。書かれていることの確認がやりにくくなる。処置はCGIパラメタの入力段階で行うのではなく「出力段階で」ないし「出力の直前で」なすべきだと理解していても、貧民的プログラミングの発想があるため、「サニタイズ」という語感によって、入力に依存するところだけやっておこうというプログラミングスタイルをもたらしているのではないか。文法のあるテキストを文字列連結で生成するときは、全ての箇所で、文法に応じて存在し得るメタ文字をエスケープするのは、本来やるはずのこと(セキュリティに関係なく)。(正常系の実装が優先するという発想)に陥りがち。Webプログラミングの解説書で、後付けの対策として書かれてしまう。セキュアプログラミング編」で、いきなり最初のサンプルコードからしてクロスサイトスクリプティング脆弱性がある。いはずという直感が働くため。インジェクション系などの脆弱性では、その「対策」と呼ばれるものは、セキュリティ対策という以前に、正常系の実装として本来なすべき処理。セキュリティと無関係なところでのバグの例。プログラミングを理解していない対策屋でも、「それさあ、サニタイズしてないのがいけないんだよねー」と、訳知り顔で語ってみせることができてしまう。誤った対策方法を教える解説や中身のない解説を増やしてしまう。どのあたりが「質の低い」ものなのか、いくつか挙げておく。複数ページ間におけるセッションを管理するために、Webブラウザの持つCookie(クッキー)という仕組みが利用されることが多い。いうものは、要約するとユーザーがWebページのフォームに入力した情報を一時的にクライアントPCに保存しておき(保存された情報をCookieと呼ぶ)、Webサーバ側で何らかのフォームを表示するときにCookie情報を使い、フォームの表示データを整形するというものだ。このため、悪意あるスパイウェアなどでCookie情報を抜き取るような行為が問題視されている。「フォームの表示データを整形」というのが意味不明。抜き取る原因を「スパイウェア」としているのがおかしい。う接続詞が前後の文脈につながっていない。プログラム側にバグがない場合でも個人情報が保存されているファイル自体のパーミッション設定(ファイルの読み出しや実行権限などの属性設定)が不適切になっていると、前述のようにブラウザで(ファイル名までの)URLを直打ちするだけで、誰でもそのファイル内容が参照できてしまうことになる。設定の問題と捉えているところが、いかにも素人臭い。何が言いたいのかサッパリな記事。明されてないし、「漏洩パターンの真実」なんぞ書かれていない。ブラウザ上で動作するスクリプトコードとしては、従来からJavaScriptが存在するが、最近はJavaScript自身のバージョンも上がっており、表現力が増している。悪意あるスクリプトコードを受け取って対策が講じられていないと、ローカルPCから情報が抜かれてしまい任意のサーバなどへ自動送信といったこともできてしまう。IEなどで使われるActiveXは、仕様上でレジストリの読み出しも可能としているため厳重な注意が必要となる。便利さゆえの機能ではあるが、セキュリティと利便性は裏腹ともいえるのだ。2005年12月20日なんじゃこりゃ。べつに「表現力が増している」わけじゃないし。「CGIセキュリティホールの落とし穴」は全然書いてないし。Perlは“手続き型言語”の一種であり、何らかの処理を行わせたい場合には、あらかじめ用意されている関数を呼び出すことで処理が可能となる。このことはPerlに限らず、ほかのプログラミング言語でも考え方が変わらない。何を意味するかというと、次のような具合だ。2005年12月21日まったく無駄な段落。いえ、タグの無効化だけでWebアプリケーションのセキュリティホール(脆弱性)がすべてなくなるというわけではない。サニタイズはセキュリティホール(XSS)対策のための一手段にすぎないことを認識しておいてほしい。予期せぬ情報漏えいを防ぐための、最後の切り札と考えておくのがよいだろう。デベロッパーのためにもう少し突っ込んだ見解も示しておこう。(略)Perlではコメントを「#」で始まる一行で記述することができる。コメントはプログラムの動作には何ら影響を与えないものだが、ソースコードの可読性を良くするために残すものだ。コメントが適切に付けられたコードは、メンテナンスが必要なときに読みやすいプログラムとなる。Perlでは変数を「$」で始まる文字列で利用することができる。プログラムにおいて変数はいわば一時的なメモリ領域である。「デベロッパー」にとってまるっきり無駄な段落。実際の処理はタグの置換というシンプルなものだが、プログラム本来の処理ではないため意外と見落とされやすい。オンライン・ムック「スパム時代のサニタイズ開発手法」では、これまで情報漏えいに対する防御策をさまざまな観点から解説してきた。例にして防御策の重要性を示した。サイトで重要視しなければならない防御ノウハウばかりだ。2005年12月28日7回も連載してきてそれだけか。Perlのopenの話と、XSSが書いてあるだけだ。今のご時勢にこれだけってのは、アリエナイ。思い知らされた記事だった。「じゃあなんと言えばいいのか」って?次のような疑問が出てくるかもしれない。それこそ「サニタイズ」なんじゃないの?答えは簡単。普通の言葉で言えばよい。いうように説明すればよい。最近では、万能な意味で「サニタイズ」を使う人が増えてきた。害化する」と訳す人が目立つようになってきた。イズと呼びたい」という思考が働いているのだろう。いうニュアンスがあるように思える。