http://blog.ohgaki.net/?disp=comments ja-JP http://backend.userland.com/rss 60 Wed, 27 Aug 2008 00:01:48 +0000 Yasuo Ohgaki [メンバー] c15443@http://blog.ohgaki.net/ 企業のセキュリティ対策について最も大切なのは「セキュリティポリシー」ですと言っています。開発やプログラミングにも「セキュリティポリシー」のような物が必要です。一つ一つ、ポリシーを作る事も可能ですが問題に対する一貫した「姿勢」が大切だと考えてます。プロアクティブなセキュリティ対策を常に先に考慮し、可能な限りプロアクティブなセキュリティ対策を採用する「姿勢」が重要と考えています。<br /> <br /> 時間もあまり無かったので「ホワイトリストの作り方」はちょっと不親切な書き方でした。私もバリデーションは全てホワイトリストでやるべきだ、とは考えていません。このエントリで紹介したようにホワイトリストのつもりでホワイトリストになっていないケースも少なくありません。「ホワイトリストの作り方」で紹介したXSS Cheat Sheetを見れば、生半可なブラックリストなど全く役に立たない事が5分もあれば分ると思います。（英語サイトのなので敷居が高いのかな...)<br /> <br /> 開発やプログラミングで、セキュリティ上、最も大切なのは問題に対する「姿勢」だと思っています。受動的なセキュリティ対策は非常に採用しやすいです。設計の問題、入力／出力先の仕様など理解せず、問題が見つかって、分ってからから対処するのですから当たり前です。<br /> <br /> 能動的な対策は多くの手間が必要となります。設計上の問題、入力／出力先の仕様を正しく理解してから作る事が前提となります。全ての開発者に幅広く、そしてレベルの深い知識を要求する事は、コストが非常に高く、現実的はありません。しかし、「7つの習慣」ではありませんが「姿勢」を身につける事は容易です。<br /> <br /> 筆者はUS CERTとMSが2000年にXSS問題の提起をした時にプロアクティブなセキュリティ対策の視点から、文字エンコーディングは厳格に扱うべきと考えていました。2000年時点では壊れた文字エンコーディングを利用した、具体的な攻撃手法などを考えつきませんでしたが、隠れたリスクを予想はしていました。<br /> <br /> 実際に複数文字エンコーディングや壊れた文字エンコーディングを利用したXSSやSQLインジェクション、XMLインジェクションは何年も経ってからPoCが発表されました。<br /> <br /> このような事例は他にもあります。スタックスマッシング攻撃が実用化された当初はヒープ領域のメモリ管理問題はセキュリティ上大きな問題ではないと認識されていました。しかし、研究が進むとヒープ領域のメモリ管理問題もスタックメモリ管理の問題と同様に任意コード実行が可能である事が分りました。<br /> # 個人的にはこの経験がセキュリティ対策を能動的に考え、実践<br /> # する事の重要性を学ぶ機会になりました。<br /> <br /> 経験に学ぶより、歴史に学ぶ方が遥かにコストが少なくなります。<br /> 歴史的にはブラックリスト的、受動的なセキュリティ対策は、無意味とは言いませんが、コレに基準を定めると安全なシステム構築には有害である事は証明されていると考えています。<br /> <br /> しかし、システム開発の現場は理想主義だけではこなせないのが現実です。従って、能動的な対策を基本に置きつつ必要な妥協を行うバランス感覚も欠かせません。主従を間違えなければ、多くのプロジェクトは正しい方向で進むと思います。最初にプロアクティブな対策を考え、プロジェクトのリソース（開発者のスキル、開発期間、開発コストなど）と要求仕様を考慮して、最適なバランスで開発を進める事が重要だと考えています。<br /> <br /> Webアプリケーションの脆弱性はWebアプリケーションので対処するべきで、対策が取れるまでサイトを閉鎖するのがセキュリティ対策だけを考慮すれば最良であることは明らかです。対策が行われるまでサイトを閉鎖する事は現実的ではありません。WAFによる保護も必要となるでしょう。しかし、WAF導入等の対策はWebシステムの様に管理された環境下でのシステム開発では受動的な対策と言えます。<br /> <br /> # 立場や環境が異なればWAFも能動的な対策と言えます。<br /> # 私は基本的に「開発者」としての立場からセキュリティ<br /> # 対策を見ています。<br /> # 運用担当者の立場から見れば、WAFは能動的な対策と言え<br /> # るでしょう。<br /><br /> <br /> <br /> 私がWAFに関して危惧しているのは、FirewallやSSLによるセキュリティ対策が万能であるかのように誤解された事が、WAFでまた再現する事です。<br />
時間もあまり無かったので「ホワイトリストの作り方」はちょっと不親切な書き方でした。私もバリデーションは全てホワイトリストでやるべきだ、とは考えていません。このエントリで紹介したようにホワイトリストのつもりでホワイトリストになっていないケースも少なくありません。「ホワイトリストの作り方」で紹介したXSS Cheat Sheetを見れば、生半可なブラックリストなど全く役に立たない事が5分もあれば分ると思います。（英語サイトのなので敷居が高いのかな...)

開発やプログラミングで、セキュリティ上、最も大切なのは問題に対する「姿勢」だと思っています。受動的なセキュリティ対策は非常に採用しやすいです。設計の問題、入力／出力先の仕様など理解せず、問題が見つかって、分ってからから対処するのですから当たり前です。

能動的な対策は多くの手間が必要となります。設計上の問題、入力／出力先の仕様を正しく理解してから作る事が前提となります。全ての開発者に幅広く、そしてレベルの深い知識を要求する事は、コストが非常に高く、現実的はありません。しかし、「7つの習慣」ではありませんが「姿勢」を身につける事は容易です。

筆者はUS CERTとMSが2000年にXSS問題の提起をした時にプロアクティブなセキュリティ対策の視点から、文字エンコーディングは厳格に扱うべきと考えていました。2000年時点では壊れた文字エンコーディングを利用した、具体的な攻撃手法などを考えつきませんでしたが、隠れたリスクを予想はしていました。

実際に複数文字エンコーディングや壊れた文字エンコーディングを利用したXSSやSQLインジェクション、XMLインジェクションは何年も経ってからPoCが発表されました。

このような事例は他にもあります。スタックスマッシング攻撃が実用化された当初はヒープ領域のメモリ管理問題はセキュリティ上大きな問題ではないと認識されていました。しかし、研究が進むとヒープ領域のメモリ管理問題もスタックメモリ管理の問題と同様に任意コード実行が可能である事が分りました。
# 個人的にはこの経験がセキュリティ対策を能動的に考え、実践
# する事の重要性を学ぶ機会になりました。

経験に学ぶより、歴史に学ぶ方が遥かにコストが少なくなります。
歴史的にはブラックリスト的、受動的なセキュリティ対策は、無意味とは言いませんが、コレに基準を定めると安全なシステム構築には有害である事は証明されていると考えています。

しかし、システム開発の現場は理想主義だけではこなせないのが現実です。従って、能動的な対策を基本に置きつつ必要な妥協を行うバランス感覚も欠かせません。主従を間違えなければ、多くのプロジェクトは正しい方向で進むと思います。最初にプロアクティブな対策を考え、プロジェクトのリソース（開発者のスキル、開発期間、開発コストなど）と要求仕様を考慮して、最適なバランスで開発を進める事が重要だと考えています。

Webアプリケーションの脆弱性はWebアプリケーションので対処するべきで、対策が取れるまでサイトを閉鎖するのがセキュリティ対策だけを考慮すれば最良であることは明らかです。対策が行われるまでサイトを閉鎖する事は現実的ではありません。WAFによる保護も必要となるでしょう。しかし、WAF導入等の対策はWebシステムの様に管理された環境下でのシステム開発では受動的な対策と言えます。

# 立場や環境が異なればWAFも能動的な対策と言えます。
# 私は基本的に「開発者」としての立場からセキュリティ
# 対策を見ています。
# 運用担当者の立場から見れば、WAFは能動的な対策と言え
# るでしょう。



私がWAFに関して危惧しているのは、FirewallやSSLによるセキュリティ対策が万能であるかのように誤解された事が、WAFでまた再現する事です。
]]> http://blog.ohgaki.net/proactive-security-vs-reactive-security#c15443 Tue, 26 Aug 2008 06:20:22 +0000 SAWA, Izumi [訪問者] c15440@http://blog.ohgaki.net/ 早速のフォローありがとうございます。<br /> 再度、上記のようなエントリを作成しました。<br /> 『続・ホワイトリストとブラックリスト』<br /><br /> <a href="http://pfrb.blog114.fc2.com/blog-entry-6.html">http://pfrb.blog114.fc2.com/blog-entry-6.html</a> 再度、上記のようなエントリを作成しました。
『続・ホワイトリストとブラックリスト』

http://pfrb.blog114.fc2.com/blog-entry-6.html]]> http://blog.ohgaki.net/proactive-security-vs-reactive-security#c15440 Sat, 23 Aug 2008 21:42:13 +0000 とおりすがり [訪問者] c15438@http://blog.ohgaki.net/ 初めまして。いつも記事を読ませて頂いてます。<br /> <br /> 前回あたりから思っていたのですが、一般的な「ホワイトリスト」という言葉の使い方ではないような気がします。<br /> <br /> 根本的に「プロアクティブな対策」を推奨することと、ホワイトリストを推奨することは全く対応が異なる話だと思います。恐らく、セキュリティをやっている人間なら誰もが理解してると思いますが。<br /> <br /> 「安全なものしか通さない」というプロアクティブな考えは、セキュリティでは常識です。しかし、その方法は色々あるわけですよね。<br /> 例えば、数字x桁ならば受け付ける（それ以外ははじく）という対策は、一般的にホワイトリストとは呼びませんよね。<br /> <br /> それと、ホワイトリストが現実的でない、といっている人達も当然、上の常識は判っていて、出来るのなら当然やっているが、話題に上がっていた、XSS等といった攻撃手法を防ぐ、という幅広い話には、ホワイトリストでは対策出来ないと言っているだけではないでしょうか。シチュエーションが限定されているならばともかく、常識的に考えて「XSSを防ぐにはホワイトリストですよ」とは言えないと思います。<br /> <br /> 話の発端は、なんでホワイトリストを説明するのにXSS Cheet Sheetをだすのか、という所だったかと思いますが、あれは一般的にみてもあきらかに誤解を招くような記述だと思いました。誤解する人がわずかだが居るようだ、ではなく、誤解しない方がレアケースでしょう。<br /> なにより「いじわるな」と本人で認めているのは、全くいかがなものかと。
前回あたりから思っていたのですが、一般的な「ホワイトリスト」という言葉の使い方ではないような気がします。

根本的に「プロアクティブな対策」を推奨することと、ホワイトリストを推奨することは全く対応が異なる話だと思います。恐らく、セキュリティをやっている人間なら誰もが理解してると思いますが。

「安全なものしか通さない」というプロアクティブな考えは、セキュリティでは常識です。しかし、その方法は色々あるわけですよね。
例えば、数字x桁ならば受け付ける（それ以外ははじく）という対策は、一般的にホワイトリストとは呼びませんよね。

それと、ホワイトリストが現実的でない、といっている人達も当然、上の常識は判っていて、出来るのなら当然やっているが、話題に上がっていた、XSS等といった攻撃手法を防ぐ、という幅広い話には、ホワイトリストでは対策出来ないと言っているだけではないでしょうか。シチュエーションが限定されているならばともかく、常識的に考えて「XSSを防ぐにはホワイトリストですよ」とは言えないと思います。

話の発端は、なんでホワイトリストを説明するのにXSS Cheet Sheetをだすのか、という所だったかと思いますが、あれは一般的にみてもあきらかに誤解を招くような記述だと思いました。誤解する人がわずかだが居るようだ、ではなく、誤解しない方がレアケースでしょう。
なにより「いじわるな」と本人で認めているのは、全くいかがなものかと。]]> http://blog.ohgaki.net/proactive-security-vs-reactive-security#c15438