「ＣＳＩ ネットワークマスター虎の穴」 第７回セミナー

安全なＷｅｂサイト構築のためのポイント

三井物産セキュアディレクション株式会社
中村 隆之
2006年12月14日

三井物産セキュアディレクション とは
 設立¾ ２００１年３月２３日

 本社所在地¾ 東京都千代田区神田錦町３−２６ 一ツ橋ＳＩビル８Ｆ

 従業員数¾ １１１名（２００６年４月１日現在）

 主な業務内容¾ セキュリティ製品（サーバ、クライアント）の取り扱い¾ ＩＳＭＳやＪ‐ＳＯＸ対応に関するコンサルティング¾ Ｗｅｂアプリケーションに関する教育、脆弱性検査、コンサルティング¾ ネットワーク脆弱性検査¾ ネットワーク監視

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1

2

目次
 Ｗｅｂアプリケーションの脆弱性とその対策
 安全なＷｅｂアプリケーション開発のための基礎知識¾ 認証について¾ セッション管理について¾ セッションＩＤについて¾ 画面遷移の管理について¾ 入力値チェック Ｗｅｂサイトの企画から運用までの各フェーズにおける対策

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3

Ｗｅｂアプリケーションの脆弱性とその対策

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

2

4

Ｗｅｂセキュリティ対策は社会的要請に 経済産業省 平成18年3月2日(木) 公表「安心・安全な情報経済社会の実現のための行動計画」 p.11〜p.12 より引用
ＳＱＬインジェクション等により個人情報の漏洩が多発している最近の状況にかんがみ、政府は、個人情報取扱事業者に対して、自らの保有する情報システ
ムの点検を行い、必要な対策を施すよう、要請する。なお、本要請後にＳＱＬイン
ジェクション等による個人情報漏洩が発生した場合は、個人情報保護法に基づき、必要に応じて、これら事業者に厳格な対応を行うこととする。
※ＳＱＬインジェクション・・・Ｗｅｂアプリケーションの脆弱性のひとつ。詳細は後述。

 Ｗｅｂサイトの開発、運営を行う事業者は、利用者が安心して利用できる安全なサ
イトにするための対策をとるべきである

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

5

対策を取らないと、どんな被害が起こるのか？
 個人情報リストの漏洩
 サービス停止
 データ破壊 サービスの不正利用
 金銭的被害（オンラインバンキングなど）
 ソースコード漏洩
 他サイト攻撃のための踏み台 など

被害レベルは、サービスの種類によって異なる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3

6

Ｗｅｂアプリケーションの脆弱性とは
不正なパラメータの送信

サービス提供者- Erroneous Error Handling- Information Leakage- Session Hijacking/Replay- Session Fixation- Brute Force Password check

webアプリケーションの不備- OS Command Injection- SQL Injection- Buffer Overflow- Forceful Browsing- Parameter manipulation- Back door and Debug mode

攻撃者
通信経路での盗聴

インターネット
webサーバ

設定の不備
セキュリティパッチの未使用

ブラウザのセキュリティレベルの設定
セキュリティパッチの未使用
phishingやpharming、わなの危険

利用者- Erroneous Error Handling- Information Leakage- Cross Site Scripting ：XSS
- Cross Site Request Forgery ：CSRF

データベース- 既知の脆弱性- 製品の誤設定

設定の不備- 既知の脆弱性- 製品の誤設定

F/W

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

7

Ｗｅｂアプリケーションの脆弱性の種類
アプリケーション別の脆弱性

サイト全体の脆弱性• Buffer Overflow• Cross-Site Scripting• Parameter Manipulation• Backdoor & Debug Options• SQL Injection• OS Command Injection• Client Side Comment• Error Codes• Forceful Browsing• Unnecessary Information• HTTPS Misuse• Cross-Site Request Forgeries• Unnecessary File
• Server misconfiguration• Insecure Cookies• Session Hijack• Session Replay• Session Fixation• Known Vulnerability

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

48Buffer Overflow
 不正なプログラムを実行させることができる¾ バイナリデータを扱う言語（Ｃ言語や Ｃ＋＋など）で発生する

 ２００１年の Ｃｏｄｅｒｅｄ が有名
GET/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

 原因¾ ユーザ入力の長さチェックが行われていない

 対策¾ 長さチェックを行う

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

9

Cross-Site Scripting ユーザのブラウザ上で不正なスクリプトを動作させ、不正なページを表示させたり、認証情報を奪取することができる 原因¾ ページを出力する際、ユーザからの入力をそのまま出力してしまっている

http://www.example.com/show.cgi?text=<script>alert()</script>
この部分をそのまま出力してしまうと

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

5

10

Cross-Site Scripting （Ｃｏｎｔ ｄ）
 対策¾ ユーザ入力を次のページで出力する際は、必ずＨＴＭＬエスケープを行う（必ず ブラウザへの出力時に行うこと！） ＨＴＭＬエスケープの変換ルール
＆

→

＆ａｍｐ；

＜

→

＆ｌｔ；

＞

→

＆ｇｔ；

→

＆ｑｕｏｔ；→＆＃３９；

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

11

Parameter Manipulation
 パラメータを書き換えて送信することで、想定外の動作を起こさせることができる
 原因¾ ユーザ側に渡す必要のないパラメータが、ユーザのフォーム内（もしくはＵＲＬパラメータ内）に含まれてしまっている
例えば、ショッピングサイトで商品を購入する際、価格をユーザ側から渡す必要はない

http://www.example.com/buy.cgi?id=30&num=3&price=123
必要ない

 対策
¾ ＵＲＬ内のパラメータ、送信フォームのパラメータ（特にｈｉｄｄｅｎ）は、本当にユーザ側に渡す必要があるものか確認する¾ 改ざんされると問題があるパラメータについては、サーバ側で保持する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

6

12

Backdoor & Debug Options
 開発者がこっそりと残したもの ・・・ バックドア
 開発者が消し忘れたもの ・・・ デバッグ オプション
 攻撃者に発見された場合は、非常に深刻な被害につながる可能性がある
 バックドアに関しては、開発者が作りこむことを防ぐことは難しいが、開発工程において、チーム内でソースコードレビューを実施したりすることで、検出できることもあるのではないだろうか デバッグオプションについては、開発時の方針で、デバッグ用コードの扱い方を予め決定しておくことで、消し忘れがあったとしても、リリース前に一括して取り除くことが可能となると思われる
 対策¾ コーディング規則の作成と徹底

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

13

SQL Injection 不正なＳＱＬ文をＷｅｂアプリケーション経由でデータベース（ＤＢ）に送り、対象外
データの閲覧、改ざん、破壊を行うことができる
最近の個人情報漏洩事件は、ほとんどがこの脆弱性だと思われる
 ＤＢの内容が画面に表示されなくても、不正な入力に対するアプリケーションの挙動
によって、ＤＢの内容を抜き取る攻撃もある（Ｂｌｉｎｄ ＳＱＬ Ｉｎｊｅｃｔｉｏｎ）
 原因¾ ユーザからの入力値をそのまま使用してＳＱＬ文を作成し、ＤＢに渡してしまっている 対策¾ ＤＢにユーザ入力値を渡す場合は、ＳＱＬ文で使用される特殊文字をエスケープする¾ または、バインド変数を必ず使用する （こちらを推奨）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

7

14

SQL Injection （デモ） シングルクォートの入力でエラーが表示される
 認証を回避する
指定したＩＤ／ＰＷのアカウント情報がＤＢ内に存在すれば検索結果が得られるＳＱＬ

select id from user_table where id=‘${id}’ and pw=‘${pw}’‘ or 1=1；--

適当な文字列（abc）

select id from user_table where id=‘’ or 1=1；--’ and pw=‘abc’
where条件が必ず真になるため、このSQL文は検索結果が得られる
コメントアウトされる
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

15

SQL Injection （デモ） ＳＱＬ特殊文字の入力によりエラーは表示されないが、挙動が変化する¾ 常に真となる条件（xxx' and 1=1--）を与えると、正常遷移¾ 常に偽となる条件（xxx' and 1=0--）を与えると、エラーが発生
and 以降の条件が真偽を判定することが可能となる
これを利用することで、ＤＢ内の情報を抜き出すことができる（これが Ｂｌｉｎｄ ＳＱＬ Ｉｎｊｅｃｔｉｏｎ）

 Ｂｌｉｎｄ ＳＱＬ Ｉｎｊｅｃｔｉｏｎ のツールにより、ＤＢ内のテーブル情報を取得する¾ absinthe
http://www.0x90.org/releases/absinthe/

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

816

OS Command Injection
 任意のＯＳコマンドを実行することができる
 Ｗｅｂサーバのコンソールを奪うことに等しいため、深刻な被害に繋がる可能性がある 原因¾ ＯＳコマンドの実行が可能な、「危険な関数」を使用している¾ ユーザからの入力値に含まれる特殊文字のエスケープ処理を行っていない 対策¾ ＯＳコマンドを呼び出さないと実行できない処理なのか確認する¾ 「危険な関数」は使用しない¾ 想定している入力の文字種、フォーマットに合致しているか、入力値チェックを行う¾ ユーザ入力をシェルに渡す前に、シェル上での特殊文字をエスケープする

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

17

Client Side Comment
 ブラウザのメニューから「ソースの表示」で表示されるＨＴＭＬソースの中に含まれるコメントの中に、有益な情報が含まれていることがある
 直接被害に繋がることはないが、場合によっては深刻な被害に繋がる可能性がある（過去の検査にて、個人情報リスト漏洩の被害に繋がった例あり）
 コメントの例¾ 更新履歴¾ 送信パラメータについての情報¾ 内部ロジックに関する情報¾ 使用していないアプリケーションのＵＲＬ（古いフォーム）

 原因¾ コーディング規則で、コメントについて決められていない

 対策¾ 挙動に関するコメント類は、プログラム言語のコメント機能を使用する
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

918

Error Codes
 プログラミング言語の処理系やミドルウェアのエラーメッセージには、システム情報が含まれていることが多いため、攻撃者に有益な情報となる
 原因¾ エラーハンドリングに不備がある。エラーハンドリングは、セキュリティ対策というよりアプリ
ケーション開発での基本であるため、必ず行うべきである¾ 攻撃を受けたときだけでなく、例えばサーバの負荷が上がって内部処理が失敗した場合のエラーもあるため、パラメータ操作だけのテストでは検出できないものもある 対策¾ きちんとエラーハンドリングを行う¾ エラーが発生した場合は、カスタマイズしたエラー画面を表示する
但し、詳しいエラーメッセージを含めないよう注意！
（これをやると、Unnecessary Information の脆弱性になる）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

19

Forceful Browsing 複数の画面を経由する機能における途中の画面（例えば認証後の画面）に直接アクセスすることができる 原因¾ セッション管理の仕組みにおける不備¾ 個々のアプリケーションにおいて、統一したステータスチェックが行われていない

 対策¾ 設計段階で画面遷移図を作成し、9 認証無しでＯＫの画面
9 認証が必要な画面
9 再認証が必要な画面といった情報を記入する。
¾ 認証状態のチェックは全てのアプリケーションで共通のコードとすればミスは減るはず

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1020

Unnecessary Information
 ユーザに必要のない情報を表示してしまっている 原因¾ エラー画面で出力するメッセージが親切すぎる 例¾ ログイン失敗時に「パスワードが違います」と表示する¾ パスワードリカバリで「このメールアドレスは登録されていません」と表示する

 対策¾ 「ＩＤまたはパスワードが違います」（ログイン失敗時）¾ 「指定したメールアドレス宛に新しいパスワードを送信しました」（パスワードリカバリ）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

21

HTTPS Misuse 本来、ＨＴＴＰＳ（ＳＳＬ）を使用すべき箇所において、ＨＴＴＰを使用している
 ＨＴＴＰＳにより実現可能となることは以下の２つ¾ 通信経路の暗号化¾ 電子証明書による認証（サーバ認証、クライアント認証）

 ＨＴＴＰＳを利用する場合の注意点¾ 画面構成¾ サーバ負荷¾ フォーム入力画面もＨＴＴＰＳで保護¾ ＨＴＴＰＳのサイトでのセッション管理でＣｏｏｋｉｅを使用する場合は、ｓｅｃｕｒｅ属性を付けて発行する（後述の Ｉｎｓｅｃｕｒｅ Ｃｏｏｋｉｅを参照）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1122

Cross-Site Request Forgeries
 処理のコミット（登録完了、メール送信、振込完了、購入完了、等）を強制的に実行させられてしまう
 発生する被害は、実行させられてしまう機能に依存する
 原因¾ 送信ＵＲＬ、送信パラメータを攻撃者が推測可能である
ショッピングサイトでの購入完了リクエストの例
http://www.example.com/buy.cgi?productid=AX123&num=10&action=finish
すべて推測可能 対策¾ 送信するパラメータの中に、攻撃者が推測できない値を入れておく
例えば、
9 Ｃｏｏｋｉｅに入っているセッションＩＤと同じ値を hidden に入れておく
9 ワンタイムトークンを生成し、hidden に入れておく

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

23

Cross-Site Request Forgeries （デモ）
 罠を踏んでしまうと強制的に退会させられてしまう

認証用Cookieも送信

退会完了までの正常遷移
ＩＤ

ログイン完了ＰＷ

メニュー画面

退会しますか？

認証用Cookieも送信
サーバから認証用Cookie発行

退会完了

退会完了リクエストをリンク形式にする<a href=http://www.example.com/taikai.php?action=finish>○△サービスご利用の方へのお知らせ</a>¾ 上記の罠ＵＲＬを、ログイン中のユーザが踏んでしまったらどうなるか？
→ 認証済みのユーザが踏むと、認証用Ｃｏｏｋｉｅも一緒に送信されるため、退会処理が完了する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1224Unnecessary File
 公開する必要のないファイルがサーバ上に置かれていることがある¾ バックアップファイル¾ 開発中のファイル¾ アプリケーションが使用しているデータ（例： 問い合わせデータ）

 「サーバ上」とは、Ｗｅｂサーバの公開ディレクトリ上のことを指す
これらのファイル、ディレクトリは
全て公開対象となる

例/var/www/htdocs/

Image/
css/
script/data/
toiawase.dat
exec.cgi
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

25

Unnecessary File （Ｃｏｎｔ ｄ）
 対策¾ 本番サーバ上では開発・編集作業は行わない¾ 不要なファイルがないかどうか定期的にチェックする¾ 一時的なキャンペーン等で使用したアプリケーションは、サーバから除去する（ＨＴＭＬ内でコメントアウトされたフォームから発見されてしまう）¾ サーバ製品の初期インストール状態では、サンプルアプリケーションやマニュアル類も一緒に入ることが多いため、これらがインストールされた場合は除去する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1326

Server misconfiguration
 Ｗｅｂサーバ、アプリケーションサーバ、ＤＢサーバなどの設定ミスによる問題
 例¾ ディレクトリ内のファイル一覧が表示されてしまった¾ ＣＧＩが実行されずに、ＣＧＩのソースコードをそのまま出力してしまった¾ 不要なＨＴＴＰメソッド（ＷｅｂＤＡＶなどのメソッド）が動作している

 対策¾ マニュアルを必ず読み、設定項目を理解して設定を行う¾ 設定変更時に毎回チェックする

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

27

Insecure Cookies
 ＨＴＴＰＳのサイトで発行されるＣｏｏｋｉｅにｓｅｃｕｒｅ属性が付いていないため、ＨＴＴＰ
でサイトにアクセスするときに、平文でＣｏｏｋｉｅを送信してしまう
このサイトは、ポート４４３番（ＨＴＴＰＳ）しか開いていない 例
https://www.example.com/
Set-Cookie: ssid=1392383
http://www.example.com:443/
Cookie: ssid=1392383
 対策

ポート４４３番にＨＴＴＰでアクセスするリクエストでは、
Ｃｏｏｋｉｅを送出してしまう¾ ＨＴＴＰＳだけで使用するＣｏｏｋｉｅには、ｓｅｃｕｒｅ属性を付けて発行する

Set-Cookie: ssid=HKHD3kSA31GAK9F; secure
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

14

28

Session Hijack ユーザになりすましてアクセスすることができる 原因¾ セッションＩＤが推測可能

 セッションハイジャックが可能なセッションＩＤの例¾ 年月日・時間だけで生成した数字列
５５０６１２１７０４１１ （２００６年１２月４日１１時５５分１７秒 を、分年月秒日時 に変換）

 対策
¾ 推測不可能で十分長い値を使用する¾ ミドルウェアが発行する値を使用する
詳細は、後述する「セッション管理について」で解説

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

29

Session Replay
 何らかの方法で入手した他人のセッションＩＤをそのまま再利用することで、サイトにアクセスすることができる
 主な原因¾ セッションＩＤが不変情報だけで生成されている¾ 有効期限がない、もしくは長すぎる¾ セッションＩＤをＵＲＬパラメータ（http://server/aa.cgi?ssid=XXXXXX）に含めている 対策¾ セッションＩＤの生成要素には、可変情報を含める¾ 有効期限は必ず設ける¾ ログアウト機能では、サーバ側でセッションＩＤを無効化し、ユーザ情報を切り離す¾ 重要な処理を行う箇所（登録情報の表示・変更、商品購入、退会、など）では、必ずＩＤとパスワードを求める（再認証）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

15

30

Session Fixation
 攻撃者が指定したセッションＩＤを、正規ユーザに使用させることができる
 例¾ ＵＲＬからセッションＩＤを受け付ける仕様のミドルウェアも存在する

http://www.example.com/index.php?PHPSESSID=abcdefg
http://www.example.com/index.jsp;jsessionid=jk3lsw8fjhgyt10
 対策¾ ログイン成功後に新しいセッションＩＤを発行する¾ ユーザから送られてきたセッションＩＤを受け付けないようにミドルウェアの設定を行う

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

31

Session Fixation （デモ）
正規ユーザ

攻撃者

Ｗｅｂサイト<a href="http://www.example.com/index.php?
PHPSESSID=abcdefg">ログイン画面</a>①メールや掲示板などで、罠のＵＲＬを提示

http://www.example.com/index.php?PHPSESSID=abcdefg②罠を踏んで、アクセスしてしまうと③Cookieがセットされてしまい、

Set-Cookie: PHPSESSID=abcdefg④そのままログインしてしまうと

Cookie: PHPSESSID=abcdefg
ログイン成功⑤攻撃者による不正アクセスが成功する

Cookie: PHPSESSID=abcdefg
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1632安全なＷｅｂアプリケーション開発のための基礎知識

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

33

安全なＷｅｂアプリケーション開発のための基礎知識
 認証
 セッション管理 セッションＩＤ
 画面遷移の管理 入力値チェック

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1734

認証についてCopyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

35

Ｗｅｂアプリケーションにおけるユーザ認証方法
 認証（Authentication）とは¾ ログインしようとするユーザが、本当にそのユーザであるか確認する方法

 考えられる方法¾ パスワード
9 実装は容易。文字種や長さ、有効期限などに気をつける必要がある¾ クライアント証明書
9 非常に強固。Ｂ２Ｂのような、特定少数の相手との通信では有効である¾ ＩＰアドレス9 ユーザまでは識別できないが、特定の企業からのアクセスを許可する、といった使い方では有効¾ バイオメトリクス（指紋、静脈など）
9 入退室やキャッシュカードの認証用に使われており、強固である。但し、生体情報は変更できないため、偽装されてしまっても変更がきかないため注意が必要である（参考）金融取引における生体認証について 2005.4 横浜国立大学 松本教授

http://www.fsa.go.jp/singi/singi_fccsg/gaiyou/f-20050415-singi_fccsg/02.pdf

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

18

36

安全なパスワードを使用させるには パスワードは、文字種、長さ、含まれる文字列に制限を設ける 文字種¾ 英数字＋記号（英字のみ、数字のみ ではダメ）

 長さ¾ 攻撃速度とパスワード空間、パスワードの寿命から求める¾ ８文字以上が安全（但し、ＢｕｆｆｅｒＯｖｅｒｆｌｏｗを防ぐため、最大長の制限も設定する）

 含まれる文字列¾ ユーザＩＤや生年月日の情報が含まれている場合や、辞書に記載されている単語、その他、よく使用されるパスワードについては、パスワードとして使用させない

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

37

パスワードクラックに必要な時間 （参考）
ネットワーク経由でパスワードクラックを行った結果（100MbpsLANを使用）
平均的PC１台使用時
文字数

パスワードファイルを
ローカルマシンでクラック

文字数

時間

時間

１

１

0.00062秒

２

3分30秒

２

0.038秒３

3時間30分

３

2.38秒

４

9日

４

2.46分

５

1年半

５

2.54時間

６

95年

６

6.57日

７

5,900年

７

13.58月

８

36万年

８

69年

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

1938パスワードの設定方法
 ユーザ自身が設定する¾ 前述した制限（文字種、長さ、含まれる文字列）に引っかからないように設定させる

 サーバ側で発行したものを使わせる¾ 複雑なパスワードを設定できるため、安全性は向上する。但し、ユーザがパスワードをどこかに書き留めてしまう可能性がある

 完全にランダムなものより、ユーザが覚えていられる文字列、かつ、制限（文字種、長さ、含まれる文字列）に引っかからないようなパスワードが好ましい

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

39

パスワードのハッシュ化
 サーバ側で記録しておくパスワードはハッシュ化しておく これにより、ＤＢの情報漏洩があっても、パスワードが漏洩することがない ハッシュ関数¾ データを受け取り、ある一定範囲の値（ハッシュ）を生成する関数¾ 似たデータから近いハッシュが生成されない¾ ハッシュが同じとなる元データの生成が困難 ハッシュアルゴリズムについて¾ ＭＤｘやＳＨＡ‐ｘといったアルゴリズムがある（例えば、ＭＤ５やＳＨＡ‐１）¾ ＭＤ５は脆弱性が指摘されているため、使わないこと¾ ＳＨＡ‐１も、新たな攻撃方法が見つかっており、当初よりは安全性が低下している¾ 今後は、ＳＨＡ‐２に移行していくようである（ハッシュについての詳細は、暗号に関する文献を参照のこと）
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

2040パスワードのハッシュ化 （Ｃｏｎｔ ｄ）
 ハッシュ化したパスワードを使用して認証を行う方法② 受け取ったpwをハッシュ化
hash(“ieog39sj”)① ＩＤ／ＰＷ送信（id=naka, pw=ieog39sj）④ ③の結果、一致していればログイン成功

Pc0gGUJNM4fr4
MHn+9JhQQ③ ②とＤＢ内のハッシュ値を比較
naka, Pc0gGUJNM4fr4MHn+9JhQQ
IDとハッシュ化されたパスワード

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

41

セッション管理について

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

21

42

セッション管理の必要性
 セッション管理が必要な理由¾ 同じユーザの連続したアクセスを追跡するため
9 ログインしていなくても、同じユーザからの接続であることを維持する必要がある場合もある
例： 買い物かごの中身の維持¾ 認証状態を維持するため
9 ＩＤ／ＰＷを送信するのは、ログインのときだけであり、以降は何らかの方法でその状態を維持する必要がある ＨＴＴＰについて¾ Ｗｅｂで使用されるプロトコルのこと¾ 基本的に、１リクエストに対して１レスポンスを返して終了（※）¾ そのためセッションを維持するためには、別の仕組みが必要¾ ＨＴＴＰＳとは、ＳＳＬ上でＨＴＴＰを使用すること（※）通信効率を上げるために、通常は1回の送受信でコネクションが切断されることはない （Keep-Alive）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

43

ＨＴＴＰのリクエストとレスポンス （参考）
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwaveflash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET
CLR 1.1.4322)
Host: www.example.com
Connection: Keep-Alive
HTTP/1.0 200 OK
Date: Wed, 29 Nov 2006 08:21:21 GMT
Server: ApacheContent-Length: 17463
Connection: close
Content-Type: text/html; charset=Shift_JIS<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN“（以下省略）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

22

44

セッション管理の方法
 ＢＡＳＩＣ認証
 Ｄｉｇｅｓｔ認証（ＢＡＳＩＣ認証を改良したもの）
 ＣｏｏｋｉｅにセッションＩＤを入れる ｈｉｄｄｅｎにセッションＩＤを入れる
 ＨＴＴＰＳのクライアント認証を使う
あまり推奨できない方法
 ＵＲＬパラメータにセッションＩＤを入れる
ダメな方法 ログイン後はパラメータに含まれるＩＤだけでユーザを識別する
 ＩＤとパスワードをパラメータに含めて、アクセス毎に認証モジュールを経由させる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

45

ＢＡＳＩＣ認証 ＨＴＴＰの仕様に含まれる認証方法であり、ＨＴＴＰヘッダに認証情報を含めることで毎回認証を行うことにより、セッションを維持する
 改良版であるＤｉｇｅｓｔ認証があるので、そちらを使うべき
GET /auth/index.html HTTP/1.1
Accept: */*Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET
CLR 1.1.4322)
Host: www.example.com
Connection: Keep-Alive
Authorization: Basic Z3Vlc3Q6Zm9vYmFy

認証情報

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

23

46

ＢＡＳＩＣ認証 （Ｃｏｎｔ ｄ）
 利点¾ Ｗｅｂサーバの設定により簡単に実現可能¾ 拡張モジュールを使用することで、ＤＢやＬＤＡＰでユーザ情報を管理できる¾ ＨＴＴＰＳと組み合わせれば、安全性は高くなる

 欠点¾ 認証時にダイアログボックスがポップアップするため、見た目が良くない¾ 「ログアウト」機能が、仕様に含まれていないため、ログアウトできない¾ ＨＴＴＰヘッダ内に含める認証情報が、ＩＤとＰＷをＢａｓｅ６４エンコードしただけであるため、ネットワーク盗聴により、ＩＤ／ＰＷが漏洩する（ＨＴＴＰＳ未使用時）$ perl -MMIME::Base64 -e 'print MIME::Base64::decode_base64("Z3Vlc3Q6Zm9vYmFy");'guest::foobar

簡単に逆変換可能¾ ＸＳＴ（Ｃｒｏｓｓ‐Ｓｉｔｅ Ｔｒａｃｉｎｇ）攻撃により、認証情報が奪われる可能性がある

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

47

Ｄｉｇｅｓｔ認証
 ＨＴＴＰ／１．１ で策定された、Ｃｈａｌｌｅｎｇｅ＆Ｒｅｓｐｏｎｓｅ方式による認証
GET /auth2/index.html HTTP/1.1
Accept: */*Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET
CLR 1.1.4322)
Host: www.example.com
Connection: Keep-Alive
Pragma: no-cache
Authorization: Digest username="guest", realm="sec", qop="auth", algorithm="MD5",
uri="/auth2/index.html",nonce="yFgKVbIjBAA=2a8b5d8f5e1d4f4f342a457d8b604640f5
1347d5", nc=00000001, cnonce="bfae40a7d3fdeb264eb078563de43943",response="44985ca43eb4c7001c9948efcfa23a1f"

認証情報
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

24

48

Ｄｉｇｅｓｔ認証 （Ｃｏｎｔ ｄ）
 利点¾ Ｗｅｂサーバの設定により簡単に実現可能¾ ハッシュ化した認証情報を使用するため、ＢＡＳＩＣ認証での欠点である、ＸＳＴやネット
ワーク盗聴により、認証情報が漏洩するという欠点が解消されている

 欠点¾ 認証時にダイアログボックスがポップアップするため、見た目が良くない¾ 「ログアウト」機能が、仕様に含まれていないため、ログアウトできない

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

49

ＣｏｏｋｉｅにセッションＩＤを入れる
 標準的な実装方法
 利点¾ ＪａｖａやＡＳＰ，ＰＨＰなどのミドルウェアの仕組みを使用することで簡単に実現可能¾ ＨＴＴＰＳを使い、Ｃｏｏｋｉｅにｓｅｃｕｒｅ属性を設定することで、安全性が高くなる

 欠点¾ ブラウザの設定でＣｏｏｋｉｅを受け付けないようにしているユーザには対応できない¾ ＸＳＳによりＣｏｏｋｉｅが漏洩する可能性がある

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

25

50

ｈｉｄｄｅｎにセッションＩＤを入れる
 重要なアプリケーションでは、この方法を取られていることが多い
 利点¾ Ｃｏｏｋｉｅと異なり、セッションＩＤが漏洩する可能性が低い¾ ＣｏｏｋｉｅにセッションＩＤを入れる方法と組み合わせることで、より強固になる

 欠点¾ 全てのリンクをＰＯＳＴメソッドでアクセスすることになるため、ＪａｖａＳｃｒｉｐｔを使用してフォー
ムをＳＵＢＭＩＴすることになる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

51

ＨＴＴＰＳクライアント認証
 サーバとＳＳＬコネクションを確立する際に、クライアント証明書を要求し、正規に発行したクライアント証明書だけを受け付ける
 利点¾ 正しいクライアント証明書を持つユーザだけしかアクセスできないため、なりすまし攻撃を受ける可能性が非常に低い

 欠点¾ 証明書の発行はお金がかかるため、不特定多数のサービスには向かない¾ ユーザのブラウザにクライアント証明書のインストールを強要しなければならない¾ 正規のユーザでも、クライアント証明書が入ってない別のＰＣからはサービスを利用できな
くなる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

26

52

セッション管理方式のまとめ
 Ｄｉｇｅｓｔ認証¾ 特定の集団にのみアクセスを許可させたいサイト
9 通常は、ＩＤ／ＰＷ情報をサーバ上のファイルで管理するため、多くのユーザを登録したい場合には向いてないので、グループに対して１つのＩＤ／ＰＷを発行する方法となる¾ ログアウトが必要ないサービスを提供するサイト

 ＣｏｏｋｉｅにセッションＩＤを入れる¾ 個人情報を扱うが、それほど重要性が高くないサイト

 ｈｉｄｄｅｎにセッションＩＤを入れる¾ 機密性の高い情報を扱うサイト

 ＨＴＴＰＳクライアント認証を使う¾ Ｂ２Ｂなど、特定少数のユーザ向けのサービスで、重要な情報を扱うサイト

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

53

セッションＩＤについて

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

27

54

セッションＩＤの生成アルゴリズム
 ＪａｖａやＡＳＰ、ＰＨＰなどのミドルウェアが生成するセッションＩＤを使用するのであれ
ば、アルゴリズムについて特に気にする必要はない（最新バージョンを使用していれば、まず問題ない）
 独自に生成したセッションＩＤを使用する方法は、なるべく避ける もしセッションＩＤを独自生成したいのであれば、以下の点に注意する¾ 必ずハッシュを使用する（解読できないようにするため）¾ 生成には可変情報を取り入れる（毎回同じ値が生成されないようにするため）¾ 十分長い値を生成する（総当り攻撃を不可能にするため）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

55

セッションＩＤの発行タイミング 毎回同じセッションＩＤを使用する

×¾ 一度漏洩したら、必ずなりすましに成功されてしまうため、推奨できない ログイン毎に異なるセッションＩＤを発行する¾ 一般的な方法であり、推奨できる¾ セッションＩＤの生成に可変情報が使われていれば必ず異なるセッションＩＤが生成される

 認証毎に異なるセッションＩＤを発行する¾ 登録情報参照や、重要な処理のコミット時には再認証を求めることが多いが、このときに、
もうひとつのセッションＩＤを発行し、Ｃｏｏｋｉｅによるセッション管理と、ｈｉｄｄｅｎによるセッショ
ン管理を併用すると、安全性が高くなる Ｃｏｏｋｉｅとｈｉｄｄｅｎを組み合わせた方法で、ｈｉｄｄｅｎの値をアクセス毎に変化させる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

28

56

セッションＩＤの発行タイミング （Ｃｏｎｔ ｄ）
 必ず ログイン成功後 に発行しなければならない
 最初にＴＯＰページにアクセスしたタイミングで発行するのではダメ？
攻撃者にセットされたセッションＩＤでログインしてしまうと、Ｓｅｓｓｉｏｎ
Ｆｉｘａｔｉｏｎ 成功となる

 ログイン実行時に発行するのではダメ？
ログイン失敗時に発行されるセッションＩＤを攻撃者にセットされてし
まうと、Ｓｅｓｓｉｏｎ Ｆｉｘａｔｉｏｎ 成功となる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

57

画面遷移の管理について

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

29

58

画面遷移管理の必要性
 画面遷移管理とは¾ ①入力フォーム、②確認、③送信完了、という画面遷移において、直接「③送信完了」のリクエストを送信させないよう、必ず「②確認」の画面を経由させるようにする仕組み

 なぜ必要か¾ 処理のコミットを行うリクエストを直接送信させられてしまう脆弱性「ＣＳＲＦ」の対策となる

 厳密に管理すると、ユーザビリティが低下する¾ Ｗｅｂアプリケーションの場合、ブラウザを複数開くことが一般的であり、１つのセッションにおいて、複数の画面状態が存在することになるため、厳密に管理しようとすると、不正な画面遷移が多発してしまう

利便性と安全性のバランスを、サイトの重要度を考慮して決定する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

59

画面遷移の管理方法
 Ｒｅｆｅｒｅｒを使う¾ 以下の理由のため推奨できない
9 Ｒｅｆｅｒｅｒを送信しないブラウザもある → サービスが提供できない

 サーバ側でセッションＩＤと画面状態を管理する¾ 利点
9 正確な管理が可能¾ 欠点
9 複数のブラウザを開いた場合の正常遷移には対応できない
9 正しい画面遷移を行っての攻撃は防げない

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

30

60

画面遷移の管理方法 （Ｃｏｎｔ ｄ）
 必ず経由させたい画面のみで発行するパラメータを導入する¾ 確認画面を経由していることを保障するには、確認画面を経由しないと生成されないパラメータを追加し、処理の確定時に、このパラメータが有効かどうかチェックすればよい
確認画面<input type=“hidden” name=“sec_key” value=“ALG2K9Q0E”>

この値をセッション変数にも格納しておく¾ 利点

9 実装は簡単。但し、パラメータ生成方法には注意が必要¾ 欠点
9 正確な画面遷移までは追跡できない（この方法は、厳密に管理する目的の方法ではないので、欠点とまでは言えないかも）

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

61

入力値チェック

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

31

62

入力値チェック
 ユーザから渡されるデータ（ＨＴＴＰリクエスト全体）は、不正なデータが含まれている可能性があるため、処理する前に必ずチェックしなければならない
例： ＨＴＴＰリクエストヘッダ内の Ｕｓｅｒ‐Ａｇｅｎｔ 入力値の文字種、フォーマット、長さが事前に想定可能な場合は、その情報を用いてチェックを行い、想定外の入力については、エラーとして処理すべき
 特にフォーマットがない場合でも、制御文字や記号類については受け付ける必要がない場合が多いはず 正規表現を正しく理解すること¾ 数字だけを許可する場合

×$str =~ /¥d+/;○$str =~ /^¥d+$/;これだと、文字列の一部に数字が入っていればいいことになる

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

63

Ｗｅｂサイトの企画から運用までの各フェーズにおける対策

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

32

64

Ｗｅｂサイトの開発から運用までの各フェーズにおける対策
 企画
 発注
 設計
 開発
 検収
 運用

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

65

企画時のポイント Ｗｅｂサイトの分類の明確化¾ Ｂ ｔｏ Ｂ （企業間取引システム）¾ Ｂ ｔｏ Ｃ （企業対一般消費者取引システム）¾ Ｃ ｔｏ Ｃ （一般消費者間取引システム）¾ 社内向けシステム

 サービス内容の明確化¾ 問い合わせ¾ オークション¾ ショッピング ・・・ ｅｔｃ

 対象ユーザの明確化¾ 不特定多数¾ 特定多数¾ 特定限定Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

33

66

企画時のポイント （Ｃｏｎｔ ｄ）
 サイトで扱うデータ（資産）の明確化¾ 会員情報（氏名、住所、電話番号）¾ 決済情報¾ 問い合わせ情報¾ 有料情報（音楽、映像、画像）

 どのような脅威が考えられるか？
¾ 不正にサービスを利用される¾ 会員情報が漏洩する¾ 決済情報が改ざんされる¾ 有料情報が盗まれる など

 資産と脅威から、サイトの重要度を決定する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

67

発注時のポイント サイトの重要度に応じて、業者に対する条件を設定する¾ 開発経験（開発サイト数）¾ セキュリティに関する知識を持っている人の割合

 脆弱性が作りこまれないように、要件（非機能要件）を設定する¾ 以下の対策を施すこと
9 不正な入力に対する入力値チェックおよび無害化
9 ＳＱＬインジェクション
9 ＯＳコマンドインジェクション
9 認証回避9 セッション乗っ取りなど、脆弱性に対する対策
9 機密情報の漏洩防止
9 なりすましによる不正アクセスの防止など、被害を防ぐ対策

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

34

68設計時のポイント サイトの重要度によって、アプリケーションの仕様も変わってくる¾ ユーザ登録の方法
9 オンラインで登録し、即登録完了
9 オンラインで申込書申請、申込書を郵送
9 窓口で登録¾ 認証方法9 「認証について」を参照。Ｗｅｂサイトの分類（Ｂ２Ｂ，Ｂ２Ｃなど）によって変わる¾ セッション管理方法
9 「セッション管理について」を参照。Ｗｅｂサイトの重要度によって変わる

 設計書のレビューには、セキュリティに詳しい人間を必ず含める¾ 設計の根本に脆弱性があると作り直しになってしまうため、大きな問題点は、この時点で指摘、修正する必要がある

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

69

設計時のポイント 〜安全性を保つ設計方針
 外部からの入力は全てチェック¾ 入力形式が決まっているなら、その形式であるかどうかの判断を行う

 不要な情報をユーザ側から受け取らない¾ ログインしているユーザのＩＤは、セッション情報が取得できる¾ 商品の価格は、商品ＩＤだけ提示してもらえればサーバ側の商品テーブルから取得できる¾ 選択画面では、選択肢の番号だけ提示してもらえればよい 必要最小限の権限しか与えない¾ ＯＳ、ﾌァイルシステム、ＤＢ 、アプリケーションなどにおける権限は最小限に設定する

 フェイルセーフ¾ システムに問題が発生した場合は、誤動作で想定外の動作をしないよう、サービスを停止するといった動作をさせる¾ 想定外の動作は異常状態と判断する
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3570設計時のポイント 〜安全性を保つ設計方針（Ｃｏｎｔ ｄ）
 多重防御¾ ファイアウォールで不正な接続は拒絶する¾ ＯＳ、Ｗｅｂサーバなどのバージョンは全て脆弱性対策済み（最新版ｏｒ最新パッチ）¾ 会員向けサービスでは、全ての処理で認証済みであることを確認する¾ 不正な入力は拒絶する¾ アプリケーションからアクセスできるファイルシステムは一部に制限する¾ アプリケーションをＯＳ上で実行するユーザの権限は最小限に制限する¾ アプリケーションからアクセス可能なＤＢの範囲は一部のテーブル、コマンドに限定する¾ ネットワーク上で、Ｗｅｂサーバからアクセス可能なホストを制限する

 既にあるものは新規に開発せず、それを使用する¾ セッション管理の仕組み（Ｊａｖａ、ＡＳＰ、ＰＨＰなど）¾ 暗号アルゴリズム

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

71

開発時のポイント 必ずコーディング規則を作成し、遵守させる¾ ソースコードレビューの負荷を軽くする¾ コードを見るだけで、間違いが分かるようにする
9 ＨＴＭＬエスケープに関するルール– 必ず出力時にエスケープする– 未エスケープの文字列の変数名の接頭後を「xss_」とする、など

9 ＳＱＬ文生成時のルール– 必ず、バインド変数を使う。それ以外の記述方法は許可しない、など

 認証、セッション管理、入力値チェックなど、重要なコンポーネントは、少数精鋭のチームが開発し、全てのアプリケーションに同じルールで実装させる¾ これらのルールについても、コーディング規則に含めて徹底する 単体テストや結合テストなどでは、セキュリティに関するテストも実施する

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3672

検収時のポイント 必要とされる機能が動くことは当然。それよりも、不正操作時の対策が取られているかどうかが重要 発注側でも、セキュリティに関するテストを行い、挙動を確認する¾ "><script>alert()</script> と入力した場合、スクリプトが動作しないように、ＨＴＭＬエス
ケープが行われているか¾ 「 」（シングルクォート）を入力した場合、おかしな挙動をしたり、ＤＢのエラーが出力されたりしないかどうか

 重要度の高いサイトの場合は、外部のセキュリティ検査ベンダーに検査を依頼し、その結果に応じて、検収の合否判定を行うという方法もある

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

73

運用時のポイント ＯＳやＷｅｂサーバ、データベースなどのサーバアプリケーションのバージョン管理 Ｗｅｂアプリケーションの機能追加や改修手順¾ 追加する機能の情報や影響範囲に関する情報を提出させる¾ 機能追加後に必ずセキュリティに関するテストを実施する

 ログの管理¾ どこまで記録できるのかを知っておく必要がある
9 Ｗｅｂサーバのログ ・・・ アクセス時刻、メソッド、ステータスコード、ＵＲＬパラメータ
9 アプリケーションのログ（作り込んでいるならば） ・・・ ログイン失敗、不正入力¾ 保管
9 一定期間保管することが望ましい

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3774

運用時のポイント （Ｃｏｎｔ ｄ）
 不正アクセス発覚時の対応手順¾ バグによるシステム停止と同じように、不正アクセスされた場合の手順も明確にしておく¾ 可能であれば、フォレンジックについての知識も身に付けておくとよい
9 フォレンジック ・・・ 法的手段の証拠とするために、不正アクセスの痕跡を調査する手段¾ 不適切な手順の場合、復旧までのコストや期間の増加だけでなく、再び攻撃される場
合もある

 重要なサイトの場合、セキュリティ監視サービスを受ける方法もある

Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

75

Ｑ
Copyright 2006 Mitsui Bussan Secure Directions, Inc. All Rights Reserved.

3876