Lucky Lovely Laboratory

■ セキュリティ要件

発注元は、黙っていてもセキュアなものを作るだろうと期待しているが開発元は要件にない限り実装しない。そういった認識の齟齬が生まれているように感じる。

要件にない限り実装しないとはいえ、最近では全くセキュリティを考慮していないものは作成されていないように見える。これは職務の知識から。それでも穴が出来てしまう原因は更に別の考察が必要になるが、ざっくりと以下のものを考えている。

• 開発者の知識不足

  脆弱性の知識を持っていないケースは多々ある。また、日々開発に追われる開発者はセキュリティを専門とする人間に比較してそのような知識を得るチャンスが少ない。また、その暇がないことも十分に考えられる。開発手法やマネジメントの問題でもある。

• 検査手法の知識不足

  これは単純。見つけることが出来ないから穴が空いたまま。ikepyon氏作成の「受入れテスト用セキュリティチェックリスト for Webアプリケーション」を見よう。

• 法的責任の有無

  これは大きいと思う。現状ではソフトウェアのバグは信用の低下くらいにしか繋がっていない。信用の低下は大きなものではあるけれども、あくまで開発元と発注元の関係でしかない。発注元と利用者が異なっている場合、利用者は開発元が同じだからと言ってそこを避けたりはしないものだし、特にWebアプリケーションでは開発元を知ることも少ないだろう。ソフトウェアに製造物責任法を適用できればいいと考える人は多いと思うのだが、何故かそういったものはない。

ああ、発注元にもセキュリティの要件を書かせようという観点があるんだが、眠くなったのでまた今度。まとめにもなっていない。

■ 知識不足

引越しを真面目に考えはじめた。分譲・賃貸両方考慮してマンションを探しているのだが、真面目に検討するのは初めてなので知識不足は否めない。本でも買ったほうがいいのかな。とりあえず住宅情報系のWebサイトをいくつか巡回してみている。

■ ネコソギラジカル(下)

買った。ついに最終巻か。読売の作者インタビューでセカイ系の説明と共に作者の

『セカイ系』と言うが、逆に、そうでない問題って小説になるの？

という疑問が提示されている。俺もセカイ系という単語には違和感を感じていて、問題の大小に違いがあるだけだと思っている。ちなみに小さな問題しかない小説はつまらなく感じる。そんなものは現実のほうが面白い。より荒唐無稽で楽しいものを求めているから俺は小説を読む。

そういう人には、この戯言シリーズはお勧めである。

■ 的確

ROの友人uに「無責任かつ面倒見が良い」と評された。なんて的確なんだ。

■ 灼眼のシャナ11

…薄い。いくら続き物とはいえ、今までの伏線に何一つ決着がついていないのはいかがなものか。話を短くして12巻に組み込んでも全く問題がない。作者も承知しているようで外伝が2冊続いたと述べているが…。ちょっとこの巻は評価低いぞ。

■ 封建社会

某カンファレンスに潜り込んでる。日本のISMS取得企業が1100社超あって、英国より多いらしい。講演者は右に習えの日本らしいと評していたが、日本らしさと言えば権威への弱さじゃないかな。

■ Auto-ID Labs羽田氏の講演

映画のように遠距離からタグを読み取られて監視されるような事態は技術が相当進化しないと無理だと述べておられた。進化したときを想定して規格を制定してほしいんだけど。ついでに言うなら羽田氏の言うところのプライバシー論者は遠距離スキャンは当面の問題とはみなしていないと思うんだけどな。

俺が気にするのはリーダが小型化して無差別に読み取られることなんだけど、それに関してはGoogleIDなんてものができたらという視点で書いてたのがちょっと面白かった。確かにスキャンしたものをガリガリネットワーク上に流して、それをGoogleで検索できるようであれば脅威だ。口頭でも説明してほしかったな。

上記のGoogleIDのような話を既存のネットワークの問題であってRFIDの問題ではないとするのはいただけない。固有IDを使わなければいい話だ。固有IDを使わせたいのは販売・流通側の事情のほうが大きいのだから、その説明責任を果たさずにネットに流れたプライバシー情報の回収ができないのは現状でも同じとするのはおかしい。

[追記]2005/11/18 0909

Auto-ID LabsをAutoIDセンターと誤記していたので訂正。申し訳ありません。

■ mixi

最近使ってないや。自分のお気に入りのサイトをぶち込んでおけるアンテナやRSSリーダとかソーシャルブックマークの方が性に合ってるみたい。ということで最近ははてなにどっぷり浸かってます。

はてなダイアリーを使わないのは二つもBlog持てない（ここですら更新は良くて週1）し、有料レンタルサーバを借りている身として何か負けた気になるから。

■ 競合他社の方のセッションを聞く

Webアプリケーションの脆弱性について、普段自分がお客様に説明していることと大差なかった。脆弱性検査ツールを開発する部門の方とのことだったので、もう少し細かい話を期待してたんだけどな。

まあ、Webアプリケーションのセキュリティは、セッション管理を除けば入力値の妥当性の確認と出力値の無害化でほとんど説明できてしまうんだけれども。

■ ときめきメモリアルオンラインβ2

2月延期だってさ。せっかくひなたの中の人と「お姉様ぶるよ！」「妹ぶるよ！キャラ作りだよ！」とか盛り上がってたのに。

β2でろりぃな外見でお姉様ぶるキャラを見かけたら、それは俺かも知れません。うひひ。

■ Webアプリケーションへの攻撃の基礎

Webアプリケーションファイアウォールの必要性（2）多様化するWebアプリケーションへの攻撃まずはこの@ITの記事をご紹介。それに対するツッコミが早速高木浩光＠自宅の日記に掲載された。見過ごせない部分が多かったようだが、合わせて読めば知識にはなるだろう。

さて、先日俺は自社の新人教育としてWebアプリケーションセキュリティについての講義（というほど大した物ではないが）を行った。そこでまとめとして述べたのは以下の2点のみである。

1. あらゆる入力を信用するな

   入力とはアプリケーションへの入力を指すのでクライアントからの情報のみならず、DBからの情報すら疑うことも考慮する。入力された値が想定範囲内に収まっているかを確認する必要がある。

2. データの出力時はエスケープ処理を行うこと

   コマンドインジェクションもXSSも出力先のアプリケーション(DBやWebブラウザ)が出力文字列をコマンドであると理解することによって生じる。これらを防止するためには、コマンドであると認識でないようにすればよい。逆に言えば、そうしなければWebアプリケーションとして正常に稼働しないことを認識すべきである。

上記2点でフォローできない脆弱性として思いつくのはとりあえずCSRFがある。これはいかにして本人認証を行うかという問題である。簡単な対策はやはり秘密情報である（はずの）Cookieに記されたセッションIDをhiddenフィールドに埋め込み、POSTデータにも入れることだろう。

徹夜でもう書けん…誰か突っ込んでください。

■ はやぶさ

まだ確証はないが、惑星間探査機はやぶさが小惑星イトカワへの接地に成功した模様。少なくともサンプル取得のための弾丸は打ち出された。

これは偉業である。

不当に「失敗ばかり」というイメージを与えられてきた日本の宇宙開発にとっても喜ばしい。

あとは無事帰還を望むばかりだ。

■ たまには素晴らしく個人的なことを

新居ほぼ決まりました。さいたま市内のマンションの購入契約を結びましたので銀行の審査に落ちない限り*1、4月からはさいたま市民となります。

気にしてくれた(た)氏に感謝いたします。

で、いつ飲みに行きましょうかね＞諸氏（つまり自己申告制）