こっちに書いてなかったので転載しておく。
http://internet.watch.impress.co.jp/cda/news/2008/06/18/19989.html
http://d.hatena.ne.jp/ikepyon/20080619#p1
以下、社内向けに投げたやつ
古いネタでアレですが、サウンドハウスの社長さんの報告が赤裸々すぎてとても興味深いです。
最後のほうが私見を入れすぎてて少し読みにくいですが。
http://www.soundhouse.co.jp/shop/News.asp?NewsNo=1561
http://www.soundhouse.co.jp/news/20080418.pdf
スラドにもストーリーができてます。
http://slashdot.jp/security/article.pl?sid=08/04/18/071215
PDFを読んでいくつか気になるところがあったのでちょっと書きます。
# 先週末に情報処理技術者試験 テクニカルエンジニア（情報セキュリティ）を受けてきたのですが、設問のなかのケースがほんとにこんな感じでさもありなんだなーと思いました。
■IDS(侵入検知システム)は有効なのか
http://itpro.nikkeibp.co.jp/article/OPINION/20080403/297948/
IDSのシステムはわりと単純なようなので、気合いを入れたクラッカーには対応できないみたいですね。
■HACKER SAFEを導入していた
これはポートスキャンして脆弱性を教えてくれるもので、webアプリケーションの安全性を担保してくれるものではない。
そして、DBが使うポートをインターネットに公開していた。そりゃいかんわ。
■3Dセキュアが有効に作用しなかった
これがよくわかりません。
3Dセキュアはカード会社のドメインでパスワードを扱うと思うので、サウンドハウス側が知れることはないとおもうのですが。
ユーザーが、サウンドハウスのサイトのパスワードと3Dセキュアのパスワードを同じにしていたということなのかなー。
■2006年から侵入されていた
なんというか息の長い話で、本気の業務のような感じですね。
そういえば、最近は個人情報が流出し過ぎてて、値段が下がってるらしいですね。
なんともいえない話です。
◆対応とか
webアプリの脆弱性のパターンはそれほどなくて、今のところはこれくらいを対応しておけばいいはず。
・SQLインジェクション
バインド機構をつかう
・ディレクトリトラバーサル
そもそもユーザーが入力したものを、ファイルシステムにアクセスするところに使わない
・XSS
http://openmya.hacker.jp/hasegawa/public/20061209/momiji.html
http://www.atmarkit.co.jp/fsecurity/index/index_hoshino.html
このあたりのことを考えると、ホワイトリストを作らないと対応できないとか、そもそも、cookieにセッション情報入れないとかでしょうか。
マジメに考えると重すぎるのであんま考えてないですけど。
・XSRF
トークンを使う
・image attack
http://labs.cybozu.co.jp/blog/takesako/2007/08/llspirit_imagefight.html
対策は…正直、シンドすぎる。image sanitizeするしかないかなぁ。
んで、社内のプロジェクトならパーシステント層もプレゼンテーション層もなんらかのフレームワークを使っているはずで、一番メジャーなSQLインジェクションとXSS（の簡単なやつ）はフレームワークのところで防げてると思うので、あとは、個別に必要なセキュリティ対策をとればいいと思います。
◆さらにFYI
セキュリティ系のネタはこのあたりを見ておくと
新鮮なネタでも対処できるようになると思います。
