Webアプリセキュリティ対策入門という本を読んでいるが…
「Webアプリセキュリティ対策入門」
大垣靖男というPHPの専門家らしい人の書いたこの本、色々な攻撃手法が挙げられていて面白そうなので買ってみた。まだ途中までしか読んでないんだけど、ちょっと突っ込みどころがある。
- クロスサイトスクリプティングのリスクについて
CHAPTER4-1：クロスサイトスクリプティングの「リスク」としてクッキー漏洩しかないかのような書き方をしている。これは文章表現がまずいというレベルではなく、
一方HTTPセッション管理を行っていないWebサイトでは重大な問題ではありません。（P48）とまで言い切っているので著者の確信なんだろう。そして、著者のこの認識は間違っていると思うよ。
クロスサイトスクリプティングによってJavaScript（VBSもあるけど）で可能なことは何でも実行されてしまう危険性があるわけ。たとえば、フィールドに入力した内容がどこか知らないところに送信されてしまったり、画面の内容が改ざんされて表示されたりとか、できるんじゃないかなあ。この具体例は大雑把な考察だからもっと詰められると思うけど、少なくとも、クッキーの漏洩だけがリスクだと言うのは問題を正しく捉えられていない。
- 入力値チェックと出力時のエスケープについて
今、CHAPTER4の核攻撃手法について読み進めているところだが、この著者ことあるごとに「入力値のチェックをしろ」と太字で書いている。これが気持ち悪い。と言うのも、本来XSSやSQLインジェクションを防止する方法の基本は「出力先に応じたエスケープ」であるからだ。
入力値のチェックは本来的にはアプリケーションの機能要件である。その副作用で偶然セキュリティ対策の漏れを救うことはあると思うし、セキュアな実装に傾けるという意味から入力値チェックを行うのも良いことだと思う。しかし、「出力先に応じたエスケープ」という基本の方がよっぽど大事だし、入門を謳う本ではこの基本を強調するべきじゃないのかな。変なところにこだわりを見せて分かりにくくなっている印象。
読む気が萎えてきてるが、がんばって後ろの方の章も読めたら、最終的なレビューを書くかも、書かないかも。
Dependsに任せた方が楽か
昨日書いた実行形式モジュールのAPIプロファイリングの件、Dependency Walkerのコマンドラインモード出力を集計すれば簡単かな。実現可能性はどういう内容が出力できるかにもよる。
自宅がMacだとこういうときすぐに試せないのがよろしくないですな。
実行形式モジュールのプロファイリング
ふと思いついたのでメモ。既存でありそうな気もするが。
ネットから入手したちょっとしたアプリなど、安全であることを期待して実行するわけだけど実際のところわからない。たとえば姓名判断プログラムの振りをしたスパイウェアだっとしても気がつかないかもしれない。
そこでだ、モジュールが使うAPIを分析して、このアプリはネットワークに接続するとかレジストリを触るとか、そういうプロファイリングしてくれると参考になりそう。基本的にWindowsで言うとDependency Walkerのやってることが出来れば良いわけで。あとはプログラミングの知識がない人が見てもわかるような言葉で結果を出力するだけ。
Windows用なら作ろうと思えば時間さえあれば自分でも作れそうだけど、完成度を高めるのが面倒に思われる。ネットワークにつなぐAPIはこれとこれとこれと…とか、そういう情報をちゃんとデータ化しないとアカンからなあ。あと、動的ロードを解析するのは難しそう。
たとえば100年じゃ足りないか？（DRM）
文章がまとまっていないのと著作権やDRMの仕組みなど未確認事項も残ってるのとが気になるけど上げる。
先日、iTunes Music Storeが10億ダウンロードを達成した。
これに関して、iTMSをはじめとしたDRMで保護されたコンテンツを配布しているサービスについて、漠然と疑問に思っていることがある。と言うのも、サービス提供者はDRMが有効である間はそのコンテンツの管理情報を保持し続けなければならない。それってものすごく大変なことではないだろうか。
話を単純にするためにiTMSで曲を購入した場合で考える。
保持してるデータは？
購入したファイルを再生する場合、iTMSアカウントに紐づいたパソコンじゃないと再生できない。
つまりサーバDBには
- 曲ファイル - iTMSアカウント
の対応付け情報が保存されている必要がある。
この情報がサーバDBにないと、例えばパソコンが壊れて買い換えました、って時に曲ファイルをバックアップから戻しても、そのパソコンで再生できるようにする手立てがなくなってしまう。
いつまで経っても？
1年後にパソコンが壊れた時も、10年後に壊れた時も、100年後でも再生できることを期待してユーザーは曲を購入している。
じゃあ、未来永劫そのデータを保持し続けなければならないのか？いや、DRMは著作権保護なので、著作権が切れれば、パブリックドメインになってしまえば、保護しなくていいのだ。その時は
- 曲ファイル - iTMSアカウント
の対応データを捨てて、誰が買った曲ファイルであろうと再生OKにしてしまえばいい。
100年？
じゃあ、何年経ったら著作権が切れるのか。現行の日本の法律だと著作権者の死後50年だ。アメリカだと死後70年。曲を購入した時点から、著作権者が30年間ご健在だとすると、日本で80年間。アメリカだと100年間、データを保持しなければならない。更に日本でもアメリカに合わせて70年間に延長しようという動きがある。
ええい、大雑把に言って100年間だ！
一曲売ってAppleの取り分はどれくらいだったか。例えば売り上げの30%とか、そんなもんだったような気がする（かなりあいまい）。その中には100年間データを保持し続ける手間賃も含まれているのだなあ。いや、含まれてるのかな？？iTMS以外のサービスにしても同様ですけど。
Flash Playerの脆弱性
標題の通り、AdobeからFlash Playerの「クリティカル」な脆弱性に対するアップデートが提供されてる。
ITMediaのニュース記事
Windows Updateは世間的に定着してきているけど、この件については認識自体薄いだろうなあ。会社なんかでWindows Updateを実施しろっていうお達しは出されるけど、こういのは来ないというのがありそうなパターン。
信頼していないWeb上のコードをユーザのアクション無しで実行するという意味で、Flashやその他ブラウザのプラグインは常に危険最前線に立たされていると考えるべきだと思います。
■
はてなの使い方がわかってないのでリファレンス張ったりできないけど。
はてなトップページの最近の人気記事ってところから「mixiを使った、トラフィックの個人追跡システム」が可能であることを知った。
- 自分のサイトから自分のmixiページを見えない状態でロード（フレームなりimgなり）
- 足あとに自分のサイトを訪れた人の履歴が残る
という仕組み。読みやすい解説はここ。
http://www.fladdict.net/blog-jp/archives/2005/12/mixi.php
雑感
- mixiログインし放しっていうのはそもそも感覚的に気持ち悪い。それに以前はまちちゃん問題もあったとこだし、この件もあるし。
- 利用者側の対策としてはmixi専用に使うWebブラウザを用意すればログアウトしなくても大丈夫かも。これを機にFirefoxとかOperaがシェアを伸ばしたらおもしろい。
- サーバ側としてはリファラ見てはじくのが手っ取り早い。リファラ無しの場合もはじいてしまえ、って思うけど、ブラウザのブックマークに登録する場合もあるから、そうもいかないか？携帯は携帯の話で対処可能だと思う。
以上
