「サニタイズ言うなキャンペーン」に癒されてみる2006年11月29日 11時15分15秒

言いだしっぺの高木先生お墨付き。一応、原典についてもリンクを示しておこうかしら。

てゆか、「やっぱりそれでいいんだよなぁ」と内心「ホッとした」というのが正直な感想。

思うんだが、「セキュリティー対策」と「セキュリティーホール対策」は、分けて考えるべきだと思う。

「セキュリティー対策」ってのは、その名の通り、セキュリティーを積極的に向上する為の対策であって、主な内容としてはウイルス対策ツールの導入だとか、プライベートファイヤーウォールの導入だとか (Unix 風 OS の常識から言えば、ポートフィルタリングは施していて当たり前とも思うが)、パッチを自動更新するだとか、バックアップを毎日取る ;-) だとか言ったような、ユーザーが (目的に応じて) 行う行動のことを指す。

「セキュリティーホール対策」ってのは、実態としては対策でもなんでもなくて、よーするに開発者が、欠陥のないプログラムを書くことを指す。積極的な対策の内容としては、せいぜい「ちゃんと勉強する」とか、「潜在要求の洗い出しをしっかりやる」とか、「よく考えて設計する」 (あるいは「レビューをしっかりやる」) とか、「ソースや文書の履歴管理をきっちりやる (cvs とか使って)」とか、「効率よくテストする」とか、「不具合管理を徹底する」とか、そんなところになるんではないかと思う。よーするに、ソフトウェア開発の現場に立つ人間であれば、誰でもやっているはずのことでしかない。

「サニタイズ」って言葉は、まるでプログラムが危険ゴミを見つけ出して一つ一つ取り除かなきゃいけないような印象を受ける。そもそも、そのデータ (の中の特定要素) が危険ゴミになるような場所に、危険ゴミが混入し得ないシステムとして設計されていれば、「サニタイズ」なんて意識する必要などないはずだ。

「でも、事実としてそういうシステムになっていないじゃないか」というのならば、その辺は自分でフォローすべきだと思う (ていうか、そうするしかないだろう)。たとえば、PHP で変数を HTML 出力するシーンでは、echo htmlspecialchars のラッパーを、俺様ライブラリとして用意すれば良いんではないかと思う。

<?php
define("HTML_CHARSET", "UTF-8");

function spill($text) {
    echo htmlspecialchars($text, ENT_COMPAT, HTML_CHARSET);
}
?>

で、実際の出力時はこんな感じで。

<table>
  <tr>
    <td>氏名</td>
    <td><?php spill($name); ?></td>
  </tr>
  <tr>
    <td>住所</td>
    <td><?php spill($address); ?></td>
  </tr>
  <tr>
    <td>電話番号</td>
    <td><?php spill($tel); ?></td>
  </tr>
  <tr>
    <td>メールアドレス</td>
    <td><?php spill($email); ?></td>
  </tr>
</table>

もっと複雑なケースではどうすべきか? って議論もあると思う。例えばユーザーの入力した HTML を部分的に許可したい場合とか、Wiki 文法を HTML 化したい場合とか。それらのケースでは、フィルタリング用のメソッドを設けて、そのメソッドの中で出力を行うようにすればいいと思う。あくまで、責任の所在は出力を生成する箇所であると決めてしまえば、設計上はすっきりするのではないかと思う。

<h2><?php spill($subject); ?></h2>
<div id="detail">
<?php
    $detail->filter();  // メソッドの中で、然るべき変換を行う
?>
</div>

こうやって詰めていけば、プログラムも設計も実にシンプルに考えることができるはずなのに、実際にはそんな単純じゃないんだーなどと勝手に思い込んじゃう人ってのは少なくないようで、その為に何だかかみ合わないやり取りが延々続くということはおいらも何度か経験があります。まさに、

ていうかこんな当たり前のことを改めて書かなくても、 という話だと思うのだが、どうもたとえば「PHPのmagic quoteはおかしい」 とか「ASP.NETのValidateRequestは本質的な対策になってない」とか言っても 通じない人に私はたまに会うし、高木さんに 「プログラミング解説書籍の脆弱性をどうするか」の記事で批判された 後藤さんの反論で、

htmlspecialchars() は、2重にかけるとおかしくなる関数です。リクエスト変数について「かけないこと」ほどは問題にならないものの、「かけすぎ」ればやはりおかしく表示されます。

こういう意見が出てくるのはいかがなものか、と私には思える (件の本は読んでないので、本そのものについて私は何も言えませんが)。

…というようなことが度々あって、しかもそういうことを言う人が、物凄く自身ありげに「俺様はこっち方面に詳しいんだぜ」ってオーラを醸し出してくれちゃったりされてしまうと、ビビリなおいらとしては微妙に自信なくなってしまう (とか言いながら自分で作るものについてはまったく気にも留めなかったりするわけですが)。

そういう意味では、この「サニタイズ言うなキャンペーン」はおいらにとってはとても癒されるキャンペーンであり、もっともっとこの輪が広がってくれることを願って止まないのであります。。。(;_;)/

ところで。。。

変だ変だと思いつつもそうした、というのには、 「PHPの郷に入ったら郷に従うべきなのかなあ」と思ったとか、 いくつか理由はあるのだが、やっぱりまずいと思うので注釈を追加しました。

個人的には、magic_quote_gpc が ON でも OFF でも良いように、以下のような入力用のラッパーを作ってあげるとよいのではないかと思っています。

function readPost($key) {
    return get_magic_quotes_gpc() ?
        stripslashes($_POST[$key]) :
        $_POST[$key];
}

しかしこんなことを強要する PHP って言語はつくづくアレだよなぁ。。。

コメント

_ O_O ― 2006/11/30 14:56:40

確かに、最初から「価格や個数といったデータにhidden属性を与えないようにする」
http://www.atmarkit.co.jp/aig/02security/hiddenmanipulation.html
ではなく「最後で品番と個数のみから必要な処理をする」という設計をすべきが理想。
しかし、実際はすでに構築された後で、運用の名目で人はついていても、
ソースを書いた/追える担当者が既にいなくなっていた場合、木を見て森を見ず、
系統だった知識で対策できない、あるいは突貫対応せざるを得なくなってしまう。

例えば、指摘される時、ソースが見られた上で直接的原因を指摘されるのでなく、
表面的に「クォート入れたら次の画面でバグった」のように連絡が入ってきたとする。
そこで、正しいプログラマは原因を根本からかもしれないけど、一度構築したら
プログラマはお払い箱にしてデザイナーにメンテさせてる場合などがある。
そこで、下手に勉強しちゃう勤勉なデザイナーはとDBに対しても危険だから入力時にも
「サニタイズ」しておくとか余計な機転をきかしちゃったりするんだな。

攻撃方法を示せるだけの似非プログラマな自己目的化したセキュリティ屋が生きていられるのも、
指摘された/発見された時に専門知識がないのに突貫で対応する必要がある人たちが居て一番簡単な
(設計レベルに戻らない)それをピンポイントで知りたいニーズがあって重宝されるからでしょう。
自己目的化してる人は、無意識に自己の立場を守ろう/必要とされたいと思っているのかも。
わざわざ難しく言ったり、言語選択含め根本的に設計が悪い事に気づかせない防御線を引いたり。
自己保身の聖域を作る人には、セキュリティの専門家は向いていないかも。

_ T.MURACHI ― 2006/11/30 17:48:30

>O_O さま

えっと。。。「瑕疵保証契約ぐらい交わせ」で F.A. で ok?
ソフト屋としては、できれば有償の保証契約を交わして頂きたいところではあるのですが。。。(^_^;

_ O_O ― 2006/12/01 11:06:57

>T.MURACHI
大体において、(形骸化していない前提で)些細な事でも契約書を交わす
ようなシステムや、組織、環境は見えないコストの説明しやすいのだけど、
実際には、元より自給労働者を使い捨てたり、オフショア丸投げも多いですからね。
瑕疵保証契約より、有償の保証契約や正社員雇用の意義を知って欲しいというか。
まあ愚痴になるので、それはその辺で(苦笑)

高木さんの「己の無知を知れ」って指摘を、「似非プログラマな自己目的化したセキュリティ屋」ではなく
本来業務とは違うけど付加価値をつけたいのか勤勉なデザイナーが深刻に受け止め、
当のセキュリティ屋は霊感商法のように不安を煽っている構図があって。
MURACHIさんのいう、「俺様はこっち方面に詳しいんだぜ」ってオーラを醸す人の話が、
ありがたく積極的に採用されている背景のように思ったのですね。

_ T.MURACHI ― 2006/12/01 13:49:22

>O_O さま

それだ! なるほど。
セキュリティ屋を雇うデザイナー屋さんは、そもそもセキュリティ屋さんが自らの (本質的には間違っちゃった) 見識を曲げないことを安心感の担保としている。確かに、「この人に任せておけば大丈夫」と人は思いたいものだし、そういう人の意見を翻してしまうと、そもそも安心の担保にはならなくなってしまう。
で、そういう局面で働くセキュリティ屋さんは、生き残る為に自然とそういう雰囲気を醸し出す能力を身に付けていくものなのかもねw あるいは、最初っからそういう能力に長けている人が生き残りやすい世界なのか。。。鶏卵論に興味はないけど、とにかくそういうことなのかも。

まぁ、そういうタイプのプログラマーさんもいたりするので、それもまた困りものだったりするのですが。。。(((((/;^^)/

しかし反面教師、自分もまた、そういうタイプの人間になっていやしないか、気をつけないとなぁ。。。

_ O_O ― 2006/12/07 11:28:14

実態は、意見を翻すと担保にならないという勤勉なデザイナーさんの事情よりも商売にならないと言う霊感商法屋さんの事情のほうが切実な気がしますけどね。
だから、やはり高木さんが「駄目な技術文書の見分け方 その1」の中であげていた、断定できないことを言うときの逃げ口上パターンランゲージで煙に巻いてしまう。
該当する条件と該当しない条件という前提があり、顕在化しないリスクは敢えて無視が出来るという事を示さずにセキュリティ向上には終わりは無いという、
一方で事実だが具体策のない精神論ばかり強調して、全て知っていなければいけないように問題を難解/専門化するなんて霊感商法の常套手段ですから気をつけないといけませんね。

PHPって言語はつくづくアレと言われるのは尤もですが、ざっとあげるだけでも以下のような特徴からデザイナーさんのプロトタイピングにPHPは向いています。
 ・HTMLにロジックを記述するだけで習得が優しい
 ・フリースペースでも、JSPやASPより採用されている
 ・LAMPスタックといえば商売になる時代があった
 ・XAMPPのようなオールインワン環境で導入が容易
デザイナーさんは設計レビューやコードレビューが本業ではないため、プロトタイプと割り切れば問題ないはずですが、そのままサービスインする受け入れ方針や、
上で書いたようなプログラマをお払い箱にしてデザイナーさんがビュー程度のカスタマイズする方針、コスト削減を理由に選択するそれにPHPの特徴がピッタリはまった。
そして、問題が発生した時にデザイナーさんが担当しなければならなくなり、事後対策ノウハウばかりが重宝される状況が多発してきたのかもしれません。
そして、他の言語に比べてPHPは霊感商法屋さんがカモを見つけやすい構造になった…と。
PHPのアレな部分を引き受ける人材がいないのに、目先の恩恵ばかり優先している環境が悪いのであってPHPが悪い訳ではないでしょうけどね。
(個人的には、PHPのアレな部分は他の言語のアレ部分より苦かなあ → 宗教戦争になるので自粛)

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※投稿には管理者が設定した質問に答える必要があります。

名前:
メールアドレス:
URL:
次の質問に答えてください:
おいらがやっている会社の名前をひらがな4文字で。

コメント:

トラックバック

このエントリのトラックバックURL: http://harapeko.asablo.jp/blog/2006/11/29/975138/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。