2007/04/03
【信頼されるSEへの道 第27号】セキュリティ監査とポリシー(3)
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ ┌───────────────────────────── 2007.4.3 │ │ 信頼されるSEへの道 〜成長し続けるために〜 第27号 │ │ http://blog.livedoor.jp/brave33/ │ │ メルマガインデックス−過去のメルマガ一覧 │ ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html └────────────────────────────────── ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ こんにちは、MICK です。 先週、先々週と２週続けて「NETWORKWROLD CONFERENCE 2007」で紹介された 年代別の「攻撃と防御の移り変わり」の資料を交え、近年のセキュリティ 傾向、アプリの実装コンセプトなどについてお伝えしました。 【第25号】セキュリティ監査とポリシー(1) 2007.03.20 →http://blog.mag2.com/m/log/0000208094/108366980.html 【第26号】セキュリティ監査とポリシー(2) 2007.03.27 →http://blog.mag2.com/m/log/0000208094/108390534.html その中でも攻撃全体のおよそ 61%がアプリケーションの脆弱性を狙うものと 紹介しました。 アプリケーション詳細設計の初期段階のポリシー設計については前回 お届けしました。 今回は、それらサーバの設定を行う上で、データはどのように盗聴されたり、 Session ハイジャックにあったりするのかについて、お伝えします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ <PR> 転職希望、自分の市場価値を知りたい方に朗報です！！ 「信頼されるSEへの道」が自信をもって、エージェントを推薦します ⇒ http://blog.mag2.com/m/log/0000208094/107875439.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【信頼されるSEへの道 第27号】セキュリティ監査とポリシー(3) ...先週からの続きです。 ●あなたのシステムは、これらの設定条件は満たしていますか？ 他人に見られてはまずい機能をベースに考えます。 まず、以下の項目をチェックしてみてください。 ・https ポート のみ許可し、http ポート では許可していない ・重要な Cookie (Session含む) は https のみで返すように設定している ・重要な Cookie の有効期限は 0 とし、その Session のみ有効となる ・Cookie に不要な情報を Cookie に格納してない ・GET パラメータに重要な情報(Session情報含む)を含めていない ・POST パラメータに Session情報 を含めていない ・LOGIN 画面呼出時と、ログイン成功時は新規 Session を発行している ・画面は Cache しないようにしている (InternetExplorer など一部は設定などでどうしても残る場合があります) 以下はおまけです。 ・Session 確認時、なにかしらのクライアント接続情報をチェックしている どうですか？思い当たるところはありますか？ ●上記内容をセキュリティ別に分類します ※両方にあてはまるものもあります ＜盗聴関連＞ ・https ポート のみ許可し、http ポート では許可していない ・重要な Cookie (Session含む) は https のみで返すように設定している ・Cookie に不要な情報を Cookie に格納してない ・GET パラメータに重要な情報(Session情報含む)を含めていない ・画面は Cache しないようにしている ＜Session ハイジャック：成りすまし＞ ・重要な Cookie (Session含む) は https のみで返すように設定している ・重要な Cookie の有効期限は 0 とし、その Session のみ有効となる ・GET パラメータに重要な情報(Session情報含む)を含めていない ・POST パラメータに Session情報 を含めていない ・LOGIN 画面呼出時と、ログイン成功時は新規 Session を発行している ・Session 確認時、なにかしらのクライアント接続情報をチェックしている あなたのシステムでは、Session情報 をコピー、違う端末から実行すると 簡単に処理が引き継がれてしまうようなことはありませんか？ 上記で上げたものの注意点としては、まず、通信内容を見せないこと、 その中でも Session情報 は一番重要な部類に入ります。 つまり、これが見られたり、分かったりすると、Session ハイジャックの 可能性が飛躍的に上がるためです。 上から見ていきましょう。 まず、クライアントPC内のファイルは、スパイウェアやボットが感染して いた場合、持ち出される可能性があります。 また、自分以外のユーザがあとで Cache ファイルを閲覧、取得する場合が ある、と心得てください。 ＜盗聴関連＞ ・https ポート のみ許可し、http ポート では許可していない ⇒http では当然、あらゆる情報が盗聴される可能性が出ます。 ・重要な Cookie (Session含む) は https のみで返すように設定している ⇒http に対して、Cookie を投げるような Cookie 埋め込みを行っていると それらが盗聴される可能性が出ます。 ・Cookie に不要な情報を Cookie に格納してない ⇒揮発性のない Cookie 情報はクライアントPC内に残るため、持ち出される 可能性があります。 ・GET パラメータに重要な情報(Session情報含む)を含めていない ⇒GET はリクエストURLに中身が表示されるため、https でも中身が 見られてしまいます。 非常にやりやすい盗聴パターンです。 ・画面は Cache しないようにしている ⇒Cache した html ファイル、その中の情報を持ち出される可能性があります。 ＜Session ハイジャック：成りすまし＞ ・重要な Cookie (Session含む) は https のみで返すように設定している ⇒通信を盗聴し、盗んだ Session を用い、成りすましに利用されます。 ・重要な Cookie の有効期限は 0 とし、その Session のみ有効となる ⇒揮発性のない Cookie の情報はクライアントPC内に残るため、持ち出される 可能性があります。 その Cookie ファイルを閲覧、Session を取得する場合があります。 ・GET パラメータに重要な情報(Session情報含む)を含めていない ⇒GET はリクエストURLに中身が表示されるため、https でも中身が 見られてしまいます。 Session ハイジャックでも非常にやりやすいパターンです。 ・POST パラメータに Session情報 を含めていない ⇒Cache した html ファイル、その中の情報を持ち出される可能性があります。 その中の Session 情報を取得する場合があります。 ・LOGIN 画面呼出時と、ログイン成功時は新規 Session を発行している ⇒これは、XSS などを用い、前もって決めうちした Session を埋め込み、 ログイン後にその Session を使って、盗聴するというものです。 もし埋め込まれても、重要な処理の都度、新規 Session を発行すれば、 成りすましは成立しません。 二次予防的な部分がありますが、意外と効果は高いものです。 最近では、重要な処理の前に都度ログインさせるものも増えています。 ・Session 確認時、なにかしらのクライアント接続情報をチェックしている ⇒実はこれも二次予防的な部分がありますが、非常に効果は高いものです。 もし Session が盗まれても、そのアタックを失敗させる効果があります。 実際は UserAgent(OSやブラウザ情報など)やプロバイダ名を用いて、 プロテクションを掛けたり、複数の組合せを使って強度も上げられます。 ※ただし、IP のみでのチェックは出来ません。 ケーブルTVの一部など、プロキシーサーバを複数共有し、帯域でIPを使う ため、接続の都度、IPが変わってしまうようなことがあるためです。 どうでしょうか？ 防ぐものそのものの種類は少ないですが、意外と気をつけるポイントが多い と思われたのではないでしょうか？ ●設計段階で上記を考慮していないと、、、 設計段階で上記を考慮していないと、非常に面倒なことになります。 これらは全てにおいて、基本的な部分を含んでいるためです。 サーバ、ネットワーク、アプリケーション、開発前や開発初期であれば あるほど、対応が楽になるためです。 ただし、これらはあくまで望ましいというものであり、これが即、 セキュリティホールというわけではありません。 強固なシステムにするための指針だと思ってください。 ●地道な作業ももちろん必須 これ以外にも、情報漏洩や攻撃者にヒントを与えるような点も忘れずに確認 することが重要です。 ・ドキュメントルート以下にはプログラムのソースそのものは配置せず、 ほかのフォルダ配下に置くようにする ・テストファイルや、デフォルトファイルをサーバ上に残さない ・ファイル、フォルダの権限は、最低限に設定する ・ファイルの一覧は取得できない ・変数名などが取得しにくい ・ログの出力先は、ユーザのアクセスが及ばない場所、権限に設定する ・プログラムの詳細エラーは表示させないようにする ・エラーでは必要以上の情報を出さない ●攻撃者にヒントを渡してないか？ たまに、ログインの際「ID が見つからない」とエラーを出すサイトが ありますが、これも間違いです。 「ID、もしくは、パスワードが間違えている」と出力すべきで、 「ID が存在するが、パスワードが間違えている」などと、教えては いけないわけです。 攻撃者に対して、わざわざ攻撃するためのヒントを与えるようなことを してはいけません。 これはどのような画面、データでも、同じだと考えてください。 その上で、一般ユーザが次にどういうアクションをとるべきかを示す メッセージを表示するようにして下さい。 ●最近の金融機関の新トレンドとは？ それでは以下のような実装をわざわざ行う理由とは何でしょうか？ ▲ソフトウエアキーボードがなぜ実装されるようになったのか？ ▲なぜ、ソースが閲覧しにくいのか？ 長くなってきましたので、これらについては、来週お届けします。 ●終わりに 今回は「セキュリティ監査とポリシー(3)」と題して、アプリケーションの 設計はサーバやインフラの設計も含めた初期設定も非常に重要という内容 でお届けしました。 上記の補足項目にもあるようにセキュリティ強化は意外に地道な作業です。 その上、複数の人間の目が必要です。 そうした意味でも普段から、セキュリティ監査や第三者目線でセキュリティ チェックということを意識し、心がけていただきたいものです。 次回は、今回までのおまけで、銀行オンライン系のアプリ実装などについて、 いくつか興味深い内容をお伝えしたいと考えてます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ご感想やご希望などありましたら、以下までメールください。 なにぶん忙しいので、全てに返信はできないかもしれませんが、 全てのメールに目を通すようにします。 ブログを準備しましたので気軽にコメントをお寄せください。 ※セミナー講師、新人研修の講師、コンサルティング依頼などについても、 以下までメールでお願いします。 ⇒ メールアドレス： info@yscre.com ⇒ ブログ： http://blog.livedoor.jp/brave33/ ⇒ メルマガインデックス： http://blog.livedoor.jp/brave33/archives/50529551.html ⇒ 登録・解除はこちら http://www.mag2.com/m/0000208094.html SEの方々にとっても、できるだけ役に立つ情報をお届けします。 ご友人や仕事仲間の方にも、ご紹介いただけたら、と思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ メルマガインデックス−過去のメルマガ一覧 ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html 【第1号】技術系SEの勘違い 2006.09.19 【第2号】本当に必要な新人教育 2006.09.26 【第3号】新人のときにおかれる環境 2006.10.03 【第4号】SEの常識？社会人の常識？ 2006.10.10 【第5号】信頼される上司 2006.10.17 【第6号】もう一つの組織 2006.10.24 【第7号】積極的な思考 2006.10.31 【第8号】メンバー同士の行き違い 2006.11.07 【第9号】プロジェクトのチェックポイント(1) 2006.11.14 【第10号】プロジェクトのチェックポイント(2) 2006.11.21 【第11号】プロジェクトのチェックポイント(3) 2006.11.28 【第12号】プロジェクトのチェックポイント(4) 2006.12.05 【第13号】プロジェクトのチェックポイント(5) 2006.12.12 【第14号】デバッグの方法・考え方 2006.12.19 【第15号】一年を振り返る 2006.12.26 【第16号】要件定義の重要性 2007.01.09 【第17号】要件定義から要求開発へ 2007.01.16 【第18号】要求開発−要求の分類方法 2007.01.30 【第19号】要求開発−各要求の関係 2007.02.06 【第20号】アジャイルに見る理想の開発(1) 2007.02.13 【第21号】アジャイルに見る理想の開発(2) 2007.02.20 【第22号】信頼できるパートナー(1) 2007.02.27 【第23号】信頼できるパートナー(2) 2007.03.06 【第24号】Network World Conference 2007 Spring 2007.03.13 【第25号】セキュリティ監査とポリシー(1) 2007.03.20 【第26号】セキュリティ監査とポリシー(2) 2007.03.27 【第27号】セキュリティ監査とポリシー(2) 2007.04.03 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＜お薦め書籍＞ 豆蔵セミナーライブオンテキスト(1) わかるオブジェクト指向 (単行本) 山田 隆太 (著) →http://www.amazon.co.jp/gp/product/4774124605/000jp-22 要求開発−価値ある要求を導き出すプロセスとモデリング 山岸 耕二 (著), 安井 昌男 (著), 萩本 順三 (著), 河野 正幸 (著), 野田 伊佐夫 (著), 平鍋 健児 (著), 細川 努 (著), 依田 智夫 (著), ［要求開発アライアンス］ →http://www.amazon.co.jp/gp/product/4822282686/000jp-22 NYPD No.1ネゴシエーター最強の交渉術 ドミニク・J. ミシーノ (著), ジム デフェリス (著), 木下 真裕子 (翻訳) →http://www.amazon.co.jp/gp/product/4894511851/000jp-22 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 日本一キーストロークの短いアドレス！！ ↓アドレスを短く簡単にします。↓ ⇒ http://000.jp/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ .
