Twelve rules for developing more secure Java code
http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
仕事関連で調べ物。
とはいえ、少なくともWebアプリでは外部からのクラスを追加とかムリッポソウだし･･･
Appletなら十分意味のある対策かも知れんけど･･･
ま、JAVAのこと知らないので感想が間違ってる可能性は高いけど･･･
セキュリティ要件
いくら開発者サイドでXSS対策をどうたら、SQL Injectionをどうたらと言っていても、依頼サイドが要件としてあげていなければ、無駄なコストだったり、不要な機能だったりするわけで、開発者のモチベーションなんてあがりゃしないし･･･
ということで、セキュリティ要件が必要なんだが、セキュリティ要件ってどうやって決めればいいんだろう?
思いっきり手を抜くのであれば、「適切なセキュリティ対策を施すこと」みたいなのでもOKなのか?
じゃ、「適切なセキュリティ対策」って何よってことにつながるんだよなぁ。でもって、「適切なセキュリティ対策」というものがあいまいなために、受け入れ側も、それで十分かどうかというのが疑問だったりするわけだ。要件定義たるもの、「何」を「どうする」のかをきちんと示さなきゃいけないと思うわけで。
となると、最も手っ取り早いのはリスク分析を行って、そこからセキュリティ要件を出すことだと思うんだけど、リスク分析という手法自体かなり難しいところがあるからなぁ。これを毎回開発案件毎にやるのは手間だし、顧客サイドには難しいかもしれない。
リスク分析のパターンを作って各案件毎にそれを適用するしないを判断するというのが出来れば、簡単に行えるかもしれないなぁ。その上でセキュリティ要件をデザインパターンみたいにパターン化してしまうともっと簡単になるかなぁ?
で、その幾つかは第1回のSKUFでも資料として乗っけてみた。
http://skuf.s-lines.net/presen/20050903/skuf-meeting-0903-ikepyon.lzh
何とか網羅的にセキュリティ要件をパターン化してみんなで使えるようにしたいなぁ。
誰か作ってくれないかな、と他力本願になってみるw
一応こういうのもある
http://www.jnsa.org/active/2005/active2005_1_4a.html (from yamagataさん)
http://www.ipa.go.jp/security/ccj/archive/cc_cem/CCpart2_v13-j.pdf
http://www.ipa.go.jp/security/jisec/documents/jisec_system_st_v1.1.pdf
しかしなぁ、JNSAの奴はどうも開発サイドからの視点っぽいので、これが必要かどうかの判断が今一分かりづらいかも･･･
CCとかSTはあまりにむずすぎるのでちょっとした開発案件では適用するのは難しいし･･･
イメージ的には機能毎に脅威が記述してあって、それに対する対策が書かれているマトリックス表みたい
なのがあれば簡単かなぁと思ったりするんだけどなぁ。
「脆弱性を解説するウェブコンテンツ制作および部品素材制作」に係る公募について
http://www.ipa.go.jp/security/kobo/18fy/vulcontents/index.html
おお、「絵で見るWebアプリケーションセキュリティ」が出来るのかな?
ちょっと期待。
ありえない対策
まっちゃさんとこでJavascriptを使ってXSSの対策をとったところがあるというのを見たけど、どうも開発者がHTTPとかJavascriptとかの仕組みを理解していないっぽい。
HTTPとJavascriptの仕組みを理解していればこのような対策はとらないと思うんだけど･･･
XSSが発生する原因の根本は、Webアプリケーション側で制御できないブラウザで問題が発生するためだけど、それがわかってないっぽい。
XSSだけでなく、SQLインジェクションも、コマンドインジェクション、LDAPインジェクション、などなどインジェクションという名前の付くものは多分全て、Webアプリケーションのプログラムが制御できない自分以外のアプリケーションで、プログラマの意図しない動作をしてしまうことが原因だ。
制御できないというのはWebアプリケーション側から受け取った命令が正しいかどうか受け取った側からは分からないということだ。その為、受け取った側はそれが全て正しい命令として解釈しようとするので、こういった問題が発生する。
だから、プログラムと外部プログラムの境界部分(この場合だとHTMLを返す部分)で、外部プログラムが意図しない動きをしないかどうかをチェックする必要がある。
入力でチェックすりゃええやんという意見もあるだろうけど、処理した結果、どの様になるか分かりづらいことがあったりするので可能なら出力直前にチェックする方が望ましい。
最も、出力直前だけでいいかというと、例えばバッファオーバーフローのように、入力直後にチェックしたほうがいいものもある。これはXSSや、SQLインジェクションなどと異なり、受け取ったプログラム自体が誤動作するものがあるからだ。
とはいえ、これら一部の例外についてももっと小さな単位(関数やらメソッドやら)で見た場合、同じことが言える。そのスコープが大きいか小さいかの違いだけで、考え方は同じなんだけどね。
バッファオーバーフローのように呼び出す関数若しくはメソッドの引数として使う直前にチェックする方が安全といえるんだけど、毎度毎度同じチェックをその関数とかを呼び出す直前にチェックするのは手間なので、受け取った関数、メソッドの側で問題が無いかチェックしたほうがよい。
だから、場合場合によって入力と出力のどちらでやるか検討がしたほうが良いと思うんだな。
