情報セキュリティセミナー 2006 技術コース専門編 本テキストの pdf ファイルは よりダウンロードできます Copyright 2006 独立行政法人情報処理推進機構情報セ

情報セキュリティセミナー2006

技術コース 専門編

本テキストのpdfファイルは

http://www.ipa.go.jp/security/event/2006/sec-sem/kaisai.html

技術コース 専門編について

対象

企業のウェブサイト、ネットワークの安全性

向上に関して理解を深めたい方

ポイント

ウェブサイトやネットワークの安全な運用

管理方法について、ケーススタディを通して

技術コース 専門編

ケーススタディ

１．ファイル共有ソフトに絡んだ情報流出

２．SSH経由の不正アクセス

３．SQLインジェクション

４．クロスサイト・スクリプティング

ケーススタディ １

ファイル共有ソフトに絡んだ情報流出

Winnyを使っていないのに機密情報が流出?!

ファイル共有ソフトに絡んだ情報流出

1.1 事例の背景

1.2 情報流出はいかにして起こるのか？

1.3 原因は何だったのか？

1.4 Winnyによる情報流出への対策

1.5 流出した情報への対応

1.6 それでも収束しない情報流出

1.7 IPAで対応した、実際の相談事例

ケーススタディ １

1.1 事例：ファイル共有ソフトに絡んだ情報流出

• Aさん：まじめなサラリーマン

– Winnyなんて使ったこともない！ヤバいんでしょ?!

– セキュリティポリシーは面倒だが、規則なので

しっかり守る、というタイプ

– ウイルス対策、OSのアップデートはきっちり

言われたとおりに実施している

• Aさんの息子B：大学生

– 実はWinnyのヘビーユーザー

■Ａさんの日常

• 普段は仕事用PCと自宅内共用PCを、

きっちり使い分け

• ある日、仕事用PCの調子が急に悪くなった

• USBメモリで自宅PCに移せば仕事は

できるが・・・

– セキュリティポリシーに反するはず・・

• いつも急ぎの仕事、ましてや家庭でどうして

も仕事する場合は・・・

– 仕事のためなんだから、今回だけ規則破っても・・

■家庭マシンで仕事をする準備

• ウイルススキャン

• OSのアップデート （Microsoft Updateなど）

• 会社のマニュアルどおりの点検作業を

確実に実施・・・ → 異常なし

• ただし、会社のセキュリティポリシーには違反

• 仕事終了後、ホッとしてしまってうっかり

■息子Ｂの行動

• 実はダウンロード中毒

• ニュースを見て、Winnyは削除

– もうダウンロードからは足を洗ったけど・・

• 警察、自衛隊の資料、機密流出！

• またまたダウンロードしたい欲求

■息子Ｂの行動 （つづき）

• Winnyは怖いがWinMXなら大丈夫かも?

• 警察のものと思しきファイルを（複数）

ダウンロード

• 開く前には当然ウイルスチェック

• 最初のファイルは破損していて開け

なかった（ように見えた）

実は山田ウイルス！

■翌日会社で・・・

• 情報流出のうわさ

• 流出したファイルには顧客情報満載

• 他にも暴露されるとマズイ情報が多数

• もちろん、Aさんが使った（作った）データ

ファイル共有ソフトWinMXのネットワークから

ダウンロードしたファイルが山田ウイルスで

あり、それに感染したPCがWebサーバと化し、

■事後処理

• 謝罪、謝罪、また謝罪

• 苦情殺到

• 大きな損失（緊急、恒久対応費用）

• 出入り禁止、取引停止

■A氏のその後

• クビは免れたが・・・

• 自主退職

• 家庭崩壊

1.2 情報流出はいかにして起こるのか？

• 会社でWinny？

• 自宅でも仕事？

• 管理領域の考え方

–自宅に存在する「会社」エリア

–逆もアリ？

• どこから流出しているのか？

1.3 原因は何だったのか？

• 秘密情報取り扱いのまずさ

– 企業/組織の機密情報、個人情報

• 「匿名によるファイル共有」の危険性を

認識していない

• ウイルス感染

■問題の本質はファイル共有ソフトではない

• そもそも、そのデータを社外に持ち出し

て良かったのか？

– 持ち出しを規制する技術的仕組みは

無かったのか

– 紛失しても他人が読めないならOK？

• 一度社外に持ち出された情報は、どこ

から流出するか分からない

■公私の区別を明確に

• いくら会社でも、自宅PC環境までは

縛れない

• 会社の管理責任範囲を明確にする

ことが必須

• 会社は、管理責任範囲では最大限の

対策努力をすべき

• 会社の管理範囲外での行動も、常識の

範囲で守らせるよう努力すべき

■自宅内共用PCを仕事で使うと、

安全のグレーゾーンができてしまう

企業や組織

自宅

安全が確保されているエリア

グ

レ

ー

ゾ

■Winnyネットワークのしくみ

キャッシュ

漏洩

データ

キャッシュ

漏洩

データ

キャッシュ

漏洩

データ

キャッシュ

漏洩

データ

キャッシュに入った

ファイルは公開状態

ファイルは「どこかのコンピュータ」のキ

ャッシュという部分に存在する。しかし、

それがどこなのか、何カ所なのかを利用

者が知ることは非常に困難。

1.4 Winnyによる情報流出への対策

• Winnyによる通信を捕捉

– 捕捉できなければ止められない

• Winnyをインストールさせない

• Winnyを実行できないようにする

• 情報流出を引き起こすウイルス感染を予防

• 機密情報取り扱いルールを策定し、遵守させ

ること

■Winnyを実行できないようにする方法

• Winnyの利用禁止と削除

（Microsoft exConn blogs ウィンドウズ開発統括部）

http://www.exconn.net/Blogs/windows/archive/2006/05/11/10625.aspx

• ソフトウェア制限のポリシーで P2P ファイル

共有ソフトを実行させない方法

1.5 流出した情報への対応

• 基本的には、消えるのを待つしかない

• 流出の事実を公表する場合は、タイミン

グに注意

• 流出データの追跡サービスを利用する

• プロバイダ経由削除依頼が利く場合も

1.6 それでも収束しない情報流出

• なおもWinnyを使い続けるユーザー

• 不安を持っていても、書籍やWeb媒体などに

あおられてついやってしまう

• 事件報道によって新規参入者が・・

• そもそも危険であることを知らない

– “バッファオーバーフロー”って何？

• 「自分は感染しない」「自分だけは大丈夫」

という過信

1.7 IPAで対応した、実際の相談事例

• ウイルス対策ソフトでは何も検知されなかった

ので、情報漏えいは起きていないと考えていい

でしょ？

• 自宅で、プライベートアドレスを使って、ルータ

も使っているから、情報流出は起きないでしょ?

• パソコン自体にはWinnyを入れず、外付けの

HDDにWinnyを入れて利用しているから、

■まとめ：ファイル共有ソフトに絡んだ情報流出

• 情報流出はファイル共有ソフトとは関係なく起こりうる

– 社内にある情報へのアクセス制限やコピー制限が有効

– 機密情報の暗号化が有効

• 少なくとも、会社が管理する範囲から情報流出する

ことは、絶対にあってはならない

• 技術的に取りうる対策はできる限り施す！

– ファイル共有ソフトのトラフィックをツールで完全遮断

– ファイル共有ソフトの検知ツールでチェック

– ファイル共有ソフトを実行させない

– ウイルス対策

ケーススタディ ２

ＳＳＨ経由の不正アクセス

侵入された被害者なのに同時に加害者?!

ＳＳＨ経由の不正アクセス

2.1 減らない不正アクセス

2.2 事例：SSH経由の不正アクセス

2.3 原因は何だったのか？

2.4 何をしていたら防げたのか？

2.5 どのようにすれば検知できたのか？

2.6 自前で調査する場合の材料は?

2.7 対応、調査のために必要な

事前準備

ケーススタディ ２

2.1 減らない不正アクセス

• サイバー犯罪の「道具」としての不正アクセス

• 金銭が目的という傾向へと変化

• ツールによる自動攻撃など、手口も変化

• 初心者は防御が手薄になりがちで、被害を

受けやすい

• 推測容易なパスワード、脆弱性の放置、

単純な設定ミスなどが原因として多い

事例：SSH経由の不正アクセス

• 中小企業Ａ

– 社員数100名、国内拠点3箇所

– 各拠点に、自社管理のサーバを置いている

– 本社から、SSHを利用しリモートアクセスで

管理

– 社内に情報システム部門は無く、

技術系社員の有志が本来業務

の片手間に本社でサーバ管理

事例の背景

• Webの公開サーバーは本社にのみ設置

• WebDAV ＋ HTTPS により、拠点間で

安全にデータやり取り

• 管理用にSSH用ポートを開けていた

• 不要なサービス、プロセスは止めていた

– telnet、ftp、Xなど

■サーバ管理者の日常

• 事実上、社内のIT関連全ての“ヘルプデスク”

• オフィスアプリの操作一つにしても、電話一本

で呼び出される

• 本来業務をこなすと、サーバを止めずに運用

するだけで手一杯。メンテなんて不可能

• 何か問題が起きても、常に後手後手の対処

しか出来ていないのが現状

• 社内でのセキュリティ意識は低く、

予算取りもままならない

■インシデント発生

• 社外からの苦情

– 「お宅の管理下にあるマシンから、SSHスキャン

を受けているだけど？何とかしてよ」

– 「侵入はされてないけどいい加減うっとおしい」

• うちが加害者？

– 確かに社内から社外に向けて大量のSSHアクセ

スが発生していた！

■急ぎ、応急処置

• 内部から外部へのSSHアクセスを遮断（FW）

• 当該のサーバをネットワークから外す

– しかし、外部に公開しているウェブサーバでもあっ

たので・・・

• とりいそぎの代替サーバを用意し、「工事中」を

アナウンスするページを公開

■調査を進めると・・・

• パスワードクラッキングされ、侵入を許していた

– SSHで使用しているポート(22/tcp)への大量のアクセス

– アカウントやパスワードを変更させながらログイン操作を

繰り返し試みていた（辞書攻撃）

– テスト用に用意していたアカウントとパスワードが利用さ

れ、侵入を許してしまった

• 不審なツールのインストールと実行

– SSHスキャンツール？

– ボット？

2.3 原因は何だったのか？

• パスワード認証によるSSH接続

– 総当り攻撃や辞書攻撃により侵入される可能性

• 不要なアカウントの存在とパスワード管理の甘さ

– テスト用管理者アカウントが残っていた

– テスト用としたため、推測が容易なパスワードだった

• アクセス制限がない

– IPアドレスによる制限を設けていなかった

• ログチェックの不履行

– 業務多忙につき。。。

– そもそも、システム管理に関する取り決めがない

2.4 何をしていたら防げたのか？

• 公開鍵認証によるSSH接続

– SSHはデフォルトではパスワード認証のみ

– サーバおよびクライアントに別途設定が必要

• 適切なアカウント・パスワード管理

– 不要なアカウントは無効化（削除）する

– 強固なパスワード運用

• アクセス制限

2.5 どのようにすれば検知できたのか？

• SSHのログチェック

– SSHへのアクセス状況から推測

• IDS/IPSの導入

– ツール等による外部からのSSHへの攻撃を検知

– 「仕掛け」による内部から外部への攻撃を検知

• ファイアウォールのログチェック

– ボットによるIRC接続試行などを検知可能

• ファイル改ざん検知システムの導入

– フィッシングサイト用のファイル設置に有効

2.6 自前で調査する場合の材料は？

• 正常な状態の記録

– プロセス、サービス、各種設定ファイルなど

• 各種ログ

– SSH、ファイアウォール、IDS/IPS、ルータなど

– Mailサーバ、Webサーバソフトなど

正常状態を把握しないと、異常を判断できない

2.7 対応、調査のために必要な事前準備

• 代替サーバの用意

• 組織内の連絡網

• 証拠保全手順

（参考 RFC 3227※）

• 調査手順

• 汚染されていないコマンド（rootkit対策）

■初動対応に関する留意点

• 調査・解析を誰が実施するのかを明確に

– 自前？ 外部の業者・専門家に依頼？

• 適切な対処方法を知らないならヘタに触らない

– ネットワークケーブルを抜いても大丈夫？

– ログインして調査しても大丈夫？

• 電源をそのまま落とす（緊急措置）

– 放置しているとシステムが破壊されていくようで

■まとめ： ＳＳＨ経由の不正アクセス

• セキュアな運用をする

– SSHの利用には公開鍵認証を用いる

– 多重防御の原則

• 異常を早期発見するための手立てを持つ

– IDS/IPS、ログ解析ツール、改ざん検知ツールの

導入など

• 何か起きた時にどう対応するかを決めておく

– 専門家に頼む、捜査機関に頼むことも検討する

– 初動対応が重要

ケーススタディ３

SQLインジェクション

ショッピングサイトの顧客情報漏洩

SQLインジェクション

3.1 SQLインジェクション概要

3.2 事例：SQLインジェクション

3.3 問題のポイント整理

3.4 なぜ SQL 文の挿入が可能か？

3.5 エラーメッセージについて

ケーススタディ ３

3.1 SQLインジェクション概要

データ

ベース

ウェブ

アプリケーション

データベースへの命令文

を構成する入力値を送信

情報閲覧

改ざん、消去

データベースへ

命令を送信

SQLインジェクションの脆弱性

があるウェブアプリケーション

【ショッピングサイト S通販】

• 社員数１０名、小規模ショッピングサイト

• 個人情報はウェブフォームからDBに保存

• サーバは自社管理、技術系社員２名が担当

• セキュリティは万全（？）

– 最新パッチの適用、ユーザ管理、アクセス

制限

3.2 事例：SQLインジェクション

• 不審人物からの脅迫

– 郵送物：S通販の顧客情報の印刷物

– 発信元非通知の電話

• S通販の顧客情報を入手した

• 要求を飲まなければネットに公開する

• S通販の対応

– 警察に相談

■顧客情報漏えい疑惑

■流出経路の想定

• 印刷物の廃棄不備？

• 内部犯行？

• Winny？

■流出経路の想定（続き）

• 印刷物の廃棄不備？

– 送付された顧客情報の印刷物をチェック

– S通販の印刷フォーマットと異なる

→ 可能性 「低」

• 内部犯行？

– 顧客情報はDB管理、技術系社員２名が運用

• Winny？

– 社内利用は禁止

– そもそも流出する情報を社員は持っていない

→ 可能性 「低」

• サイトへの不正アクセス？

– リモートアクセスを利用しているが・・・

– ウェブサイトを狙った攻撃か？

■流出経路の想定（続き）

まずはシステムの状況確認

• プロセス稼働状況

（タスクマネージャ、ps、top など）

• サービス稼動状況

（netstat など）

• ログイン、ログアウト

（w、last など）

• コマンド履歴

（history など）

確認結果

■何を調査する？

• ログの保存場所、参照方法の把握

• ログの読み方の理解

– 詳しく調べるときは生ログから調査する場合も

• ツールの導入

– Apache であれば analogなど

• 複数のログを比較

– 異常値やエラーなどの発生時刻から

• ログ取得の検討（調査前）

– デフォルトではログを記録しないサービスも

– 詳細のログまで取得するかどうか

– 保存期間、ローテート

■ログ調査のポイント

サービスログ

• リモートサービス（SSH）

/var/log/secure など

• ウェブサーバ

/var/log/httpd/以下, System32/LogFiles/W3SVC1 など

• データベース

.mysql_history, /var/lib/mysql/*.log など

• その他

■ログ調査の対象

May 7 09:27:32 shops sshd[1533]:

Failed

password

for invalid user

abe

…

May 7 09:27:33 shops sshd[1536]:

Failed

password

for invalid user

andou

…

May 7 09:27:33 shops sshd[1539]:

Failed

password

for invalid user

a-imai

…

■ログ調査：リモートサービス（SSH）

• 不正アクセスらしきものがあった

• ログインは成功はしていない

SEARCH /¥x90¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1

¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02

¥xb1¥x02¥xb1¥x02¥xb1¥x02¥xb1¥x02...(略)...¥x90¥x90¥x

90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x

90¥x90¥x90¥x90¥x90¥x90¥x90¥x90¥x90...(略）

■ログ調査：ウェブサーバ

• IIS の脆弱性を狙ったワーム

例：less /var/log/httpd/access_log

GET /user.cgi?uid=11%20...SELECT%20xxx%20FROM...

GET /user.cgi?uid=12%20...SELECT%20xxx%20FROM...

GET /user.cgi?uid=13%20...SELECT%20xxx%20FROM...

GET /user.cgi?uid=14%20...SELECT%20xxx%20FROM...

GET /user.cgi?uid=15%20...SELECT%20xxx%20FROM...

GET /user.cgi?uid=11%20...

SELECT%20xxx%20FROM...

GET /user.cgi?uid=12%20...

SELECT%20xxx%20FROM...

GET /user.cgi?uid=13%20...

SELECT%20xxx%20FROM...

GET /user.cgi?uid=14%20...

SELECT%20xxx%20FROM...

GET /user.cgi?uid=15%20...

SELECT%20xxx%20FROM...

• GETメソッドの通信に不審な文字列？

GET /user.cgi?

uid

=11%20...

SELECT%20xxx%20FROM...

GET /user.cgi?

uid

=12%20...

SELECT%20xxx%20FROM...

GET /user.cgi?

uid

=13%20...

SELECT%20xxx%20FROM...

GET /user.cgi?

uid

=14%20...

SELECT%20xxx%20FROM...

GET /user.cgi?

uid

=15%20...

SELECT%20xxx%20FROM...

• GETメソッドの通信に不審な文字列？

• パラメータ（uid） に SQL文？

• 同時刻帯に同様の通信が大量発生

Query

SELECT...WHERE uid=11...

Query

SELECT...WHERE uid=12...

Query

SELECT...WHERE uid=13...

Query

SELECT...WHERE uid=14...

Query

SELECT...WHERE uid=14...

less /var/lib/mysql/ipa.log

■ログ調査：データベース

Query

SELECT...WHERE uid=11...

SELECT xxx FROM...

Query

SELECT...WHERE uid=12...

SELECT xxx FROM...

Query

SELECT...WHERE uid=13...

SELECT xxx FROM...

Query

SELECT...WHERE uid=14...

SELECT xxx FROM...

サーバー：メッセージ245、レベル16、状態1、行1

構文エラー。varchar値'情報太郎'から int データ型に

変換できませんでした。

• 構文エラー発生

• 攻撃失敗？

サーバー：メッセージ245、レベル16、状態1、行1

構文エラー

。varchar値'情報太郎'から int データ型に

変換できませんでした。

サーバー：メッセージ245、レベル16、状態1、行1

構文エラー

。varchar値'

情報太郎

'から int データ型に

変換できませんでした。

クエリ

SELECT...WHERE uid=11...

SELECT xxx FROM...

実行結果

xxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxx

xxxxxxx

xxxxxxxxxx

Microsoft OLE DB Provider for ODBC Drivers エラー '8

0040e07 [Microsoft][ODBC SQL Server Driver][SQL S

erver]構文エラー。varchar 値

‘

情報太郎

' から int データ...

...構文エラー...'

03-5978-7527

' からint データ...

...構文エラー...'

東京都文京区本駒込

...

' からint データ...

...構文エラー...'

[email protected]

' からint データ...

■不審なログの検証（続き）

ブラウザの表示画面

(IISの場合)

■調査結果

• ウェブサーバへのリクエストを通じ、データ

ベースへ不正なアクセスがあった

• 顧客情報は、エラーメッセージの表示を

通じて入手された可能性が高い

• サーバに直接侵入された形跡はなかった

3.3 問題のポイント整理

• 外部から SQL 文の挿入が可能であった

– SQL 文を構築する際のコーディングの問題

– 設計やコーディングの見直しが必要

• エラーメッセージをブラウザに表示していた

– 開発時には必要だったが・・・

– 設定やコーディングの変更が必要

$p

=foo

'

or

'

a

'

=

'

a の場合：

SELECT * FROM a WHERE id=' ';

$p

=foo の場合：

SELECT * FROM a WHERE id=' ';

$p

=foo の場合：

SELECT * FROM a WHERE id='foo';

3.4 なぜ SQL 文の挿入が可能か？

•

特別な意味を持つ記号文字の扱いが不適切

SELECT * FROM a WHERE id='

$p

';

$p

=foo

'

or

'

a

'

=

'

a の場合：

SELECT * FROM a WHERE id='foo

'

or

'

a

'

=

'

a';

変数中の

記号文字

が意味のある文字として解釈される

■どうすればよいか？

• エスケープ処理の実施

特別な意味を持つ記号文字

が

普通の文字

として解

釈されるように処理する

例：' → ''（同じ文字の繰り返し）

$p

=foo

'

or

'

a

'

=

'

a の場合：

■エスケープ処理の実装方法

• バインド機構の利用

（プレースホルダ、バインド変数、Prepared Statement）

• エスケープ関数の利用

（DBI の quote() など）

• 置換演算子の利用

（ s/'/''/g; など）

$sth = $dbh-

>prepare(

"SELECT id, name, tel, address, mail FROM usr

WHERE uid=

?

AND passwd=

?

");

$sth-

>execute(

$uid

,

$passwd

);

プレースホルダ

バインド変数

■エスケープ処理の実装例（参考）

• バインド機構を利用

$sth=$dbh-

>prepare(

"SELECT id, name, tel, address, mail FROM user

WHERE uid='

$uid

'and passwd='

$passwd

'");

$sth-

>execute();

$sql

="SELECT id, name, tel, address, mail FROM user

WHERE uid='".

$uid

."'and passwd='".

$passwd

;

$sth=$dbh-

>prepare("

$sql

");

$sth-

>execute();

■危険なコーディング例（参考）

• SQL文の組み立てにパラメータ値をそのまま利用

xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxx

xxxxxxxxxx

SQL(

select uid, name, tel, birth, address,

mail from userinfo where uid=

)の実行に失敗

しました。理由： ERROR: syntax error at end

of input at character 109

3.5 エラーメッセージについて

• 攻撃者の心理

– DB 使用 → SQL インジェクションの脆弱性

■エラーメッセージを非表示にする

• コーディング（エラーハンドリング）で対応

• 設定で対応

– Apache の場合は、ErrorDocument を設定

– IISの場合は、次のように変更

※ デフォルト値は

「クライアントに詳細

な ASP のエラー

メッセージを送る」

なので注意！

• SQL文の組み立てには必ずエスケープ処理

を実装する

• エラーメッセージをそのままブラウザに表示

しない

詳細、その他のポイントは下記参照

■まとめ：SQLインジェクション

ケーススタディ４

クロスサイト・スクリプティングによる

フィッシング詐欺

「認証画面」にスクリプト混入？

クロスサイト・スクリプティング

4.1 事例：クロスサイト・スクリプティング

4.2 スクリプトを埋め込まれやすい

ウェブアプリケーションについて

4.3 改善前の

クロスサイト・スクリプティング対策

4.4 改善後の

クロスサイト・スクリプティング対策

ケーススタディ ４

4.1 事例：クロスサイト・スクリプティング

【ショッピングサイト H販売】

• 中規模ショッピングサイト

• セキュリティ対策は万全

– サーバの堅牢化、アクセス制御

– 通信はHTTPSで暗号化

– ウェブアプリケーションの脆弱性対策もばっちり

■フィッシング詐欺疑惑

• サイト利用者よりH販売に問い合わせ

– 心当たりの無いクレジットカードの請求がきた

– 請求元はH販売だが、購入した記憶なし

– サイトの登録情報が変更されていた

– フィッシング詐欺には注意していたつもりだが・・・

• H販売

■フィッシング詐欺とは

偽のウェブサイト

本物のウェブサイト

偽のウェブサイトを本物のウェブサ

イトと思い込み、認証情報やクレジ

ットカード番号を入力してしまう

利用者から入力

された重要情報

を入手する

↓

問題なし

■H販売（を装った）メール

送信者 : H販売<[email protected]>

32 inch 液晶TV : ¥100,000

https://h.example.com/login.cgi?id=24

C8AD774FA45222&sid=%E3%82%B

B%E3%82%AD%E3%83%A5%E3%8

3%AA%E3%83%86%E3%82%A3java

script:...%E3%82%BB%E3%82%AD

%E3%83%A5%E3%83%AA%E3%83

%86%E3%82%A3

利用者の行動

• メールアドレスのチェック

• 商品URLのドメインチェック

■メールからサイトへアクセス

• アクセス後のページ

利用者の心理

・ URLのドメイン、サーバ証明書は H販売のもの

ログイン

ユーザID

パスワード

https://h.example.com/login.cgi?id=24C8AD7

・ URLチェック

・ サーバ証明書

チェック

■ログイン画面に埋め込まれたスクリプト

• アクセス後のページ

ログイン

ユーザID

パスワード

<html>

...

<form>

<input type="text"...

<input type="password"...

...

javascript:...

...

• 実はスクリプトが埋め込まれていた

利用者

ウェブサイト

ウェブ

アプリケーション

悪意ある

ウェブサイト

■クロスサイト・スクリプティングの概要

スクリプトを混入可能な脆弱性

があるウェブアプリケーション

４．利用者のブ

ラウザ上でスク

リプトが実行

スクリプト

実行

クリック！

利用者にスクリプトを含

む文字列をリクエストさ

せるためのウェブページ

２．スクリプトを

含 む 文 字 列 を

ウェブアプリケ

ーションに送信

３．スクリプトを含む

ウェブページを出力

１．悪意あるサイトの

ウェブページを閲覧

ｘｘｘｘｘｘｘｘｘｘｘｘ xxxxxxxxxx

登録

4.2 スクリプトを埋め込まれやすい

ウェブアプリケーションについて

• 入力値を遷移後の画面で利用

• その際、エスケープ処理を行っていない

• 想定の入力値であれば・・・

• 入力値に細工した文字列を指定

• 指定されたスクリプトがブラウザ上で実行される

• スクリプトの内容は攻撃者次第

■スクリプトを埋め込まれやすい

ウェブアプリケーションについて（続き）

登録

><script>alert(“test”);</script>

4.3 改善前のクロスサイト・スクリプティング対策

• 危険な文字の削除

– script など、危険と判断した文字にマッチング

したら削除

• 入力値チェック

– ブラウザ側での入力制限

– 念のため、ウェブアプリケーション側でも実施

例： 「script」 を削除

■「危険な文字の削除」には漏れが・・

入力値：<script>alert("test");</script>

削除後：

入力値：<

script

>alert("test");</

script

>

削除後：< >alert("test");</ >

<>alert("test");</>

入力値：<sscriptcript>alert("test");</sscriptcript>

削除後：<s cript>alert("test");</s cript>

<

script

>alert("test");</

script

>

script script

• 削除処理の結果、スクリプト生成

■どうすればよかったのか？

& → &amp;

" → &quot;

< → &lt;

> → &gt;

•「削除」ではなく「置換」

•「記号文字」を置換

（HTMLを許可しない場合）

•例：

• 「削除」ではなく「置換」

• 「記号文字」を置換できない場合でも同様

例：

■どうすればよかったのか？（続き）

「script」 を「

x

script」に置換

入力値：<script>alert("test");</script>

置換後：<

x

script>alert("test");</

x

script>

入力値：<s

script

cript>alert("test");</s

script

cript>

置換後：<s

x

script

cript>alert("test");</s

x

script

cript>

ただし、ブラックリスト方式は漏れが起こりやすい

ブラウザ側で

入力制限

ウェブアプリケーション側で

入力値チェック

ウェブアプリケーション

入力値

チェック

入力値

処理

出力

処理

登録

ブラウザ

■入力値チェックで安全は確保できるか?

処理済み

入力値

氏名：情報太郎

処理済み

入力値

氏名:script

入力値

処理

氏＋名

入力値

処理

氏:情報

名:太郎

入力値

氏:scr

名:ipt

• チェック通過後の処理によって危険な文字が生成

• チェックに漏れが生じている可能性も

入力値

チェック

出力

処理

「script」 は

許可しない！

チェック

通過

入力値

スクリプト

実行

■入力値チェックが機能しない例

チェック

通過

• チェックのタイミングを意識する

– 出力時の値に注目

入力値

チェック

入力値

処理

出力

処理

入力値

入力値

処理済み

入力値

出力対象

に注目！

■どうすればよかったのか？

① 「排除」 ではなく 「置換（エスケープ）」

② 置換処理は 「出力」 対象の値に実施

参考：

「安全なウェブサイトの作り方」 1.5 クロスサイト・スクリプティング

http://www.ipa.go.jp/security/vuln/websecurity.html

4.4 改善後のクロスサイト・スクリプティング対策

付録

ウェブアプリケーションの

■脆弱性はこうして生まれる

• 誤った認識（セキュリティ ＝ パッチでOK）

• 初心者プログラマによるコーディング

• 無料 CGI を安易に設置

• 見落とし、コーディングミス

• 新しい脆弱性、攻撃手法の発見

ウェブアプリケーションの安全性は

開発者、運営者が 「積極的に」 確保すべき

■安全性向上のためのポイント

• 「削除」 と 「置換」

• 「入力値チェック」 と 「出力値チェック」

•

「危険な実装」

•

「ホワイトリスト」 と 「ブラックリスト」

•

「本質的解決」 と 「保険的対策」

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

件名

コメント

送信

<form action="mailform.cgi" method="post">

<input type="hidden" name="to" value="foo@

example.com">

<input type="text" name="title">

<textarea name="comment"></textarea>

<input type="submit" value="送信">

</form>

■危険な実装とは

・・・攻撃が成立する可能性が高い実装

例：メールフォーム

■hidden の使い方に注意

• 値の改ざんは極めて容易

– [email protected] → [email protected]

• 攻撃者の行動

– 宛先を改ざんし、迷惑メールを送信

– さらに他のメールヘッダも改ざん（※）

■危険な実装の例

例：hidden にSQL文を指定

• 値の改ざん ＝ 任意のSQL文を指定可能

– "SELECT...FROM list WHERE id=1"

↓

– "DROP TABLE list"

<input type="

hidden

" name="sql" value=

"

SELECT...FROM list WHERE id=1

">

■危険な実装は避けましょう

• hidden を利用した重要項目の送信

– 論外

– 攻撃の糸口をわざわざ用意しているのと同じ

– 修正には設計、仕様からの見直しが必要

重要な情報はウェブアプリケーション側で

■「ブラックリスト」 と 「ホワイトリスト」

パターンマッチングによるフィルタ方式の違い

• ブラックリスト

– 原則 「許可」

– リストにマッチした場合はブロック

• ホワイトリスト

– 原則 「不許可」

– リストにマッチした場合は通過

■フィルタの具体例

例：$filename に入力された値をフィルタ

file_1.txt

script

scr

ipt

<

許可

不許可

不許可

不許可

不許可

許可

不許可

許可

許可

不許可

入力値

ホワイトリスト

file_*.txt

ブラックリスト

script

<

■「ホワイトリスト」 のメリット・デメリット

• メリット

– ブラックリスト方式よりも安全性が高い

– 未知の攻撃にも対応可能

• デメリット

– 厳格で柔軟性がない

– 対象によっては洗い出しが困難

– 複雑なコーディングが要求される場合も

■「ブラックリスト」 のメリット・デメリット

• メリット

– 対象の洗い出し、コーディングが容易

• デメリット

– 漏れやすり抜けが発生しやすい

– 未知の攻撃には対応不可

ホワイトリストの実装が理想だが、困難な場合もある。

■「根本的解決」 と 「保険的対策」

• 根本的解決：

– 脆弱性の原因を作らない実装

– 攻撃手法を問わず有効

• 保険的対策：

– 攻撃による影響を低減する対策

– 脆弱性そのものは無くならない

– 多重防御の観点

詳細は 「安全なウェブサイトの作り方」 参照

http://www.ipa.go.jp/security/vuln/websecurity.html

■具体例：SQLインジェクション

• エスケープ処理の実施

– バインドメカニズム

– 関数、置換演算子の利用

• エラーメッセージの非表示

根本的解決

保険的解決

■具体例：クロスサイト・スクリプティング

• 出力値のエスケープ処理

– 記号文字を置換

• ホワイトリスト方式によるフィルタ

• ブラックリスト方式によるフィルタ

– 入力値のチェック

根本的解決

保険的解決

■まとめ：ウェブアプリケーションの

安全性向上のためのポイント

• 実施する対策の効果や性質を正しく理解する

• 安全なプログラミング知識を身に付ける

参考サイト：

安全なウェブサイトの作り方

http://www.ipa.go.jp/security/vuln/websecurity.html

セキュア・プログラミング講座

http://www.ipa.go.jp/security/awareness/vendor/programming/

■情報システムの脆弱性対策への取り組み

∼情報セキュリティ早期警戒パートナーシップ∼

製

品

開

発

者

脆弱性関連

情報届出

シ

ス

テ

ム

導

入

支

援

者

対応状況

等公表

【

【

受付機関

受付機関

】

】

発見者

IPA

JPCERT

/CC

【

【

調整機関

調整機関

】

】

脆弱性関連

情報通知

ユーザ

政府

企業

個人

ソ

フ

ト

ウ

エ

ア

製

品

の

脆

弱

性

ウ

ェ

ブ

サ

イ

ト

の

脆

弱

性

脆弱性関連

情報届出

ウェブサイト

運営者

脆弱性関連情報通知

個人情報漏え

い時は事実関

係を公表

①製品開発者及びウェブサイト運営者による脆弱性対策を促進

②不用意な脆弱性関連情報の公表や脆弱性の放置を抑制

【期待効果】

IPA, JPCERT/CC

■ＩＰＡ 新着情報メール配信

情報処理推進機構ホームページの新着情報を

電子メールでご案内しています。

■ ソフトウェア開発、調査等に関する公募情報

■

セキュリティ対策情報

■ 入札情報

■ イベント・セミナー情報

■ 情報処理技術者試験情報

ウイルス対策

不正アクセス対策

NEWS

緊急対策情報

対策実践情報

暗号技術

セキュリティ評価・認証

脆弱性情報

・ウイルス対策

・不正アクセス対策

・脆弱性対策

【読者層別】

・情報シス責任者向け

情報セキュリティ読本

・システム管理者向け

・エンドユーザー向け

・ホームユーザ向け

・SOHO向け

・ネットワーク

サービス事業者向け

URL http://www.ipa.go.jp/security/

IPAセキュリティセンターのホームページ

独立行政法人 情報処理推進機構

セキュリティセンター（IPA/ISEC）

〒113-6591

東京都文京区本駒込２−２８−８

文京グリーンコート センターオフィス１６階

ＴＥＬ ０３（５９７８）７５０８

ＦＡＸ ０３（５９７８）７５１８

電子メール [email protected]