孤高さんのところから手繰ったネタ。
ではなぜ、解説書でさえ(C)のようなコードを書いてしまうのか。3つ考えられる。1つ目は、貧民的プログラミングの発想。2つ目は、煩雑な見栄えを嫌がってということがあるだろう。
まず、「htmlspecialchars」という名前が長い。これをあちこちに埋め込まないといけない。文字列連結している文の部分部分に htmlspecialchars を入れて、入れて、入れていかないといけない。これが嫌で嫌で堪らないプログラマが、それでも「セキュリティ対策しないと……」ということで仕方なく必死に作業していくと、必要最小限の場所にだけ htmlspecialchars と書くことになりがちだ。
その結果として何が起きるかというと、いわゆる「サニタイズ漏れ」だ。それを目を皿にして探していく作業も、たいへんなコストがかかることになる。
上に挙げた(A)の事例について、こうした脆弱性を指摘された本の著者はこう反論するかもしれない。「PHPの入門書なので、まずは PHP による HTML formの基本的な書き方を説明したいだけ。最初からそこらじゅうに htmlspecialchars と散りばめたのでは、読者がついてこなくなってしまう。セキュリティ対策の方法は後半で書いているのだから、これでよいのだ……」と。
事実、2002年に、ある@ITの解説記事の脆弱性を指摘したとき、関係者の方から
記事の主旨はサーバサイドアプリケーションの諸環境の紹介を第一としておりますことご了解いただけますと幸いです
という釈明を受けたことがある。また同じころ、知人が書いていた書籍について、出版前に読んで欲しいと依頼されて読ませてもらったところ、やはり、 SQLの使い方を紹介する章のサンプルコードがモロにSQLインジェクション脆弱性のある安易な書き方になっていて、「こういう書き方、やめようよ」と言ったことがあるのだが、著者は、「ここはSQLの使い方をわかってもらうためだから余分なコードは入れたくない」と主張して、全面的な書き直しはしなかった（注意書きが添えられ、後ろの章にセキュリティ対策の章が付け加えることで対処された）ということがあった。このように、コードの見た目が煩雑になることがプログラマ達に嫌われていて、特に解説本の著者がひどく嫌っていることがわかるが、それが脆弱プログラマを増殖させる原因となっている。
そして3つ目の原因が、「サニタイズ」という言葉が安易に流行りすぎていることの弊害である。
「サニタイズ」というのは、「無害化」という意味の言葉であることから明らかなように、あくまでも「セキュリティ対策」としての文脈でしか語られない。そうすると、「CGI入力の（に依存した）変数はサニタイズせよ」というスローガンになってしまう。これが悪しきプログラミングスタイルを助長して困る。
正しくは全ての変数をエスケープ対象とせよが基本であるし、変数だけじゃなくて式全体をエスケープの対象とするべきなのに、「サニタイズ」という言葉で教育が行われていると、その考え方に至る機会が殺がれてしまう。
だから、「サニタイズ言うな」なのだ。
なるほどと思う。まず大前提として、「セキュリティ意識の低いプログラマ」というものを大量生産している背景には「サニタイズ」という言葉で「ごく普通のセキュリティ対策」を何か特別な処理のように思わせてるという状況が存在するので、そんな特別な言葉をお前ら使うなという主張は理解できる。
んで、高木氏はhtmlspecialchars抜けなどよくある例として指摘されているのですが。諸事横着でめんどくさがりなおいらは、「そんなのHTML_Template_Flexy使えば一発じゃーん」って考えてしまいます。これなら変数出力は基本エスケープ済みなので楽です。SQLは DB::prepare()を使いましょうｗ これでクロスサイトスクリプティング脆弱性もSQLインジェクション脆弱性もばっちりカバーです。
もちろん、あらゆる原則には例外が存在するように、これらのPEARライブラリではどうにもならないケースというのもあるのですがね。
