WEBマーケティング研究会

第12回・Webサイトの脆弱性

情報処理推進機構（IPA）およびJPCERTコーディネーションセンターが公表した2009年第1四半期のWebサイトの脆弱性に関する届出状況によると、届出のあった合計821件のうち、DNSの設定不備（DNSキャッシュポイズニング）が343件、クロスサイトスクリプティングが334件、SQLインジェクションが100件と上位3種類の脆弱性で全体の95%を占めていることがわかりました。（本連載では、第1回にSQLインジェクション、第2回にクロスサイトスクリプティング、第3回にDNSキャッシュポイズニングを取り上げ、最近の傾向と基本的な対策を紹介しました。）

これら3種類の脆弱性に共通する点は、攻撃用のツールがネットで出回ったことで、脆弱性が存在しそうなWebサーバを無作為に攻撃できるようになったため、ある日突然被害を受ける可能性があることです。特定の企業を狙った標的型攻撃では、人間の心理・行動の隙を突くことで情報を不正に取得するソーシャルエンジニアリングの手法を取り入れたものが登場するなど、攻撃方法も多様化してきています。その一方で、Webサイトの実際のトラブルは外部からの攻撃を受けなくても、サーバの基本設定を間違えるなど人的なミスが重なって発生しているケースも多いという現状があります。Webサイトのセキュリティは、システムに対するリスクを増大させるあらゆる要素に対処する必要があります。

【トラブル事例】

2006年1月9日、楽天は前年12月より実施していたポイントキャンペーンにおいて、複数の楽天アカウントを開設して大量にポイントを取得していた例が数多く発見されたとして、会員に付与したポイントを一旦取り消したことを発表しました。スポンサーのプロバイダやポータルサイトの利用者に「楽天スーパーポイント」を付与する趣旨でしたが、キャンペーンサイトのURLをクリックするだけでポイントが自動的に付与されるアプリケーションの欠陥が正月休み中に匿名掲示板で伝わると、複数の楽天アカウントを開設してポイントを大量に取得する人が続出しました。正当な利用者のポイントも一旦取り消されたため、発表直後は会員の間で混乱が拡大しました。

上記のトラブル事例では、キャンペーンに採用されたWebアプリケーションの不具合を事前にチェックできなかったことが直接の原因ですが、トラブルが発生した当時は会員規約に複数アカウントの開設を禁止する条項がなく、実際に同じ人がアカウントを短時間でいくつも開設できたなど、システムや制度に不備があったことも否めません。事件が発覚した後もキャンペーン中止の決定や公式発表が遅れるなど、対応も決して迅速とはいえませんでした。システムの不具合や対応の悪さなど様々な要因が重なって騒ぎが大きくなったトラブルであることがわかります。

Webサイトの脆弱性の検査、検出方法

Webアプリケーションの脆弱性検査	プログラムの内容を知らせずに実施するブラックボックステストや、プログラムのソースを伝えた上で実施するホワイトボックステストなどがある。
ポートスキャニング	サーバの接続窓口であるポートに順番にアクセスして、外部からの侵入を許してしまいようなポートが存在しないかどうかを定期的にチェックする。
攻撃痕跡検出ツールの導入	情報処理推進機構（IPA）は、アクセスログからWebアプリケーション脆弱性を狙った攻撃と思われる痕跡を検出するツール「iLogScanner」を無料で提供している。
侵入検知システム（IDS）による監視	システムにアクセスしてくるトラフィックを常時監視して、脆弱性攻撃の際に出現するパターンが検出されるとシステム管理者にアラートを発する。

Webサイトを安全に運営するには、定期的に脆弱性検査を行い、外部から攻撃される隙をできるだけ見せないことが重要です。Webアプリケーションの脆弱性検査としては、プログラムの内容を知らせずに外部から動作させて行うブラックボックステストや、プログラムのソースを伝えた上で意図した通りに動作するかを確認するホワイトボックステストなどがあります。脆弱性に対する攻撃を素早く検知する仕組みとしては、攻撃の際に出現する特定パターンのトラフィックをリアルタイムで監視する侵入検知システム（IDS）の導入が有効です。また、Webサイトのセキュリティに関するガイドラインを策定して、担当者の意識を日頃から高めておくことがトラブル防止に効果的といえるでしょう。

※「トラブル事例に学ぶWebサイトのセキュリティ」は今回が最終回となります。次回からは新しい企画がスタートいたします。お楽しみに。

-----------------------------------------------------------------
　◎初出：2009年6月29日
-----------------------------------------------------------------

第11回・ECサイトの価格誤表記

ECサイトにおける価格の誤表記とは、商品を新しく登録する際やキャンペーンで販売価格を変更する際などに、0を一つ付け忘れるなど本来表示すべき価格とは異なる数字を掲載してしまうことです。有名な例では、2003年10月に丸紅の関連会社が運営するECサイトで、本来198000円のパソコンの価格を19800円と誤表記したため、短時間で1500台の注文が殺到したという例があります。対応に苦慮した末、実際に19800円で販売して多額の損失が発生し、その後サイトは閉鎖されました。このようにECサイトの価格誤表記は、対応を誤ると事業からの撤退に直結しかねない大きなリスクになる可能性があります。

価格の誤表記が発生するのは、パソコンや周辺機器、家電製品など、価格変動の比較的大きい商品が中心です。これらの商品はアイテム数が多い上、価格競争激化に伴い期間限定セールを実施することが多く価格が頻繁に変更されるという特徴があります。また、価格比較サイトへの上位掲載を狙って1日に何度も販売価格を修正することもあり、人間によるチェックが十分に行き届かないという事情もあります。価格の誤表記と思われる例がネット上の掲示板に投稿されると、社員が誤表記に気づくまでのわずかの時間に注文が殺到してしまうという事例が数多く報告されています。

【トラブル事例】

2007年6月6日の夕方、ソフマップ・ドットコムにおいてセール期間終了に伴い大型液晶モニターの価格を172800円から通常価格の198000円に戻す際、19800円と一桁少なく表記してしまいました。6日夜にネット上の掲示板で話題になり注文が殺到、翌朝に社員が気づいて即刻掲載を中止しました。ソフマップは即日、利用規約に基づいて注文者に対してキャンセルすることを通知しました。利用規約に価格誤表記についての取り扱いが明記されていたことや、事実の公表など注文者への対応が迅速だったため大きな騒ぎには到りませんでした。

価格の誤表記を未然に防止できなかった点は失敗ともいえますが、上記のソフマップの事例は誤表記が発生した時の対応の仕方として参考になります。価格誤表記のきっかけは、セール期間終了に伴う価格の変更でした。そこで、ソフマップはキャンセルされた注文者に対して、希望者にはセール期間中の特別価格で提供すると提案しました。この対応も騒ぎを抑える効果があったと思われます。2005年7月のベスト電器での誤表記事件のように、注文者全員にお詫びとして1000円の郵便為替を郵送した例もありますが、最近ではソフマップが行ったような対応が一般的になりつつあります。

ECサイトの価格誤表記への対策

価格の妥当性をチェックする仕組み	価格を入力する時点で、原価や実勢価格に比べて著しく低い数字になっていないかを自動的にチェックして、誤表記と思われるものは登録を受け付けないようにする。
短時間の異常な量の注文の遮断	短時間に同じアイテムに一定以上の注文が検知された場合に、注文の受付を一時中断して担当者にアラートメールを送るようなプログラムを追加する。
利用規約や自動返信メールの見直し	注文直後の自動返信メールには「注文を受け付けました」等の表記は避けて、利用規約にも明らかに誤表記の場合は注文を取り消すことができる、などの項目を設ける。Amazon.co.jpの利用規約などが参考になる。
問題発生時の対応マニュアル整備	万が一、価格誤表記が発生した場合に備えて、注文者へのメール対応やWebサイトでの公表など、どのような対応を行うか具体的な手順を定めたマニュアルを整備しておく。

価格誤表記を防ぐ方法としては、価格を入力する段階で妥当性をチェックする仕組みを構築することがあげられます。たとえば、商品データベースに原価を設定しておき、原価よりも著しく低い価格を登録しようとするとエラーが出るような仕組みです。また、短時間で異常な量の注文が入った場合は自動的に注文受付を一時中断するプログラムを追加したり、利用規約や注文受付の自動返信メールに記載される文章の見直しを行ったり、誤表記が発生した際にスムーズに注文をキャンセル扱いできるよう対応手順をまとめたマニュアルを整備しておくことも重要です。

-----------------------------------------------------------------
　◎初出：2009年6月22日
-----------------------------------------------------------------

第10回・ドメインの乗っ取り

ドメインの乗っ取りとは、本来の所有者ではない者がドメインを管理する権限を不正に手に入れて、表示されるWebサイトやメールアドレスの配送先を全く別のものに差し替えてしまうことを指します。ドメインは、ドメインの一意性を管理する組織（レジストリ）の認定を受けた指定業者（レジストラ）を経由して登録を行いますが、ドメインが参照するDNSサーバの情報などを変更できるドメイン管理アカウントが提供されるのが一般的です。このドメイン管理アカウントのパスワードが漏れてしまうと、結果としてWebサーバやメールアドレスを乗っ取られることになります。

「.com」などのドメインを管理するICANNは、フィッシング詐欺の手法を使ってドメイン管理アカウントのパスワードを盗み出し管理権を乗っ取る事例が報告されたとして、注意を喚起するアドバイザリーを2008年5月に公開しています。レジストラに対して偽のドメイン所有権の移転申請を出して、ドメイン登録者の名義そのものを勝手に変えようと試みるケースも後を絶ちませんが、レジストラが現在の登録者に確認を行った後に手続きが進められますので、詐欺的な方法により所有権を移転することはできません。しかし、ドメインを登録する際に架空の法人名を登録していた場合や、レジストラが確認作業を怠った場合など、登録者の意思に反して所有権が一時的に移転されてしまったケースもあります。

【トラブル事例】

2005年1月15日、アメリカの老舗プロバイダPanix.comがドメイン乗っ取りの被害を受け、Webサイトへアクセスすると全く関係のないサイトが表示される状態になりました。調べてみると、panix.comの所有権が勝手にオーストラリアの企業に移転されていることが判明。同社では急遽、代替のドメイン「panix.net」を利用できる状態にして、利用者に代替ドメインを使うよう呼びかけました。16日午後に所有権が元通りに修正され、17日には混乱も収束しました。オーストラリアのレジストラが不正な移転申請を誤って受理してしまったことが原因とされています。

その他のドメイン関連のトラブルとしては、「ドメインの有効期限切れ」があります。登録が抹消されても30日間の「請戻猶予期間」が設けられていて、この間、他の人に権利を横取りされない仕組みになっていますが、抹消されている間はWebサーバやメールが使えなくなります。ドメインの更新手続きを忘れてしまうというのは単純なミスなのですが、日本でもたまに発生しています。最近では、2008年12月にブログパーツサービスのドメインが有効期限切れで一時的に使えなくなり、サービスを利用していた多数のユーザに迷惑がかかってしまったという例があります。

ドメインが乗っ取られる原因

ドメイン管理アカウントのパスワードが流出	ドメイン管理アカウントのパスワードを関係者から不正に聞き出したり、レジストラからのメールを装ったフィッシング詐欺の手法で盗んだりする例が報告されている。
ドメイン更新手続きを忘れる	登録が抹消されるとWebサイトが表示されなくなるのですぐに気づくが、普段使っていないバックアップ用のドメインだと有効期限切れに気づかずに、請戻猶予期間後に他の人が合法的に権利を得てしまう場合がある。
不正なドメイン移転要請をレジストラが受理	世界中にレジストラ業務を行っている企業が数多くあり、ドメイン移転申請も増えていることからトラブル事例のようなミスが今後も発生する可能性がある。

ドメインの所有権が勝手に移転されるというケースは稀にしても、仮に現在ビジネスで使っているドメインが一時的に利用できない状態に陥ると、大きな損害が発生するというリスクは認識しておくべきです。レジストラに登録されている情報が間違っていないか、ドメインの更新手続きなど社内で誰がドメインの管理を行っているかなどを再度確認しておきましょう。トラブル事例のように、万が一、現在のドメインが利用できなくなった場合のバックアップ用ドメインを用意しておくことも有効です。

-----------------------------------------------------------------
　◎初出：2009年6月15日
-----------------------------------------------------------------

第9回・コミュニティの炎上

コミュニティにおける「炎上」とは、SNSやブログでの投稿や運営会社の告知内容に対する批判的な意見が殺到して、コメント受付やユーザー対応などコミュニティの一部機能が停止に追い込まれる状態を指します。最近の特徴としては、コミュニティが炎上すると匿名掲示板での書き込みを経て情報が短時間でネットに広がり、マスコミにニュースとして取り上げられることが多くなっています。その反響の大きさから、最悪の場合サービスの停止に追い込まれることもあり、コミュニティの炎上は運営会社にとって大きなリスクになりつつあります。

ブログが本格的にビジネス活用され始めた2005年以降、企業がキャンペーンのために開設したブログが炎上する例がいくつも発生しています。その中で多かったのは、関係者が消費者になりすましてポジティブな記事だけを書くというクチコミ操作でした。これらは「偽りのブログ（Fake Blog）」という意味からFlogと呼ばれています。アメリカでの事例としては、2006年に大手スーパーWal-Martが開設したFlogが有名です。日本でも2005年に、ソニーの新製品モニターに選ばれた消費者がブログを運営するというキャンペーンで、関係者が書いているのではないかと批判を受けブログが閉鎖された例があります。

【トラブル事例】

2008年3月3日、ミクシィはmixiの利用規約を改定するとして、4月から適用される改定条文を公表しました。ところが、条文に「ユーザーは著作者人格権を行使しないものとする」などの文章が加えられていたため、mixiに投稿した日記などを勝手に書籍化されるのではないか、という不安が会員の間で広がり、規約改定に反対する意見が殺到しました。ミクシィは、日記の著作権がユーザーに帰属することを明記した新しい条文案を3月19日に発表するとともに、規約改正の目的を詳しく説明しました。それにより、利用規約に関連した炎上事件は沈静化しました。

コミュニティが炎上する原因は、運営会社の不用意な言動や管理者の不手際などの人為的なミスが大半を占めます。前述のトラブル事例では、利用規約改定の目的や改定条文の意味をわかりやすく説明するのを怠ったことが大きな原因としてあげられます。また過去の事例では、サイトのウイルス感染や個人情報漏えいなど、運営会社側が犯したミスを隠蔽しようすると、必ずと言っていいほど匿名掲示板などで隠蔽行為が指摘されて状況が一気に悪化しています。運営するコミュニティやWebサイトに何らかのトラブルが発生した場合、隠さずに速やかに情報開示することが炎上を最小限に食い止める最善の方法といえるでしょう。

コミュニティが炎上する主な理由

なりすましによる提灯記事	Flogだけでなく、匿名掲示板で関係者の自作自演の書き込みがばれた場合も炎上の原因になる。
運営者側の不用意な発言	最近では、楽天市場が加盟店向けメールマガジンでマスクの仕入れを呼びかけたことが批判の対象になった。
一方的なルールや規約改正	参加ルールを変更する場合は、理由の説明をして新ルールへの移行期間を十分に取るようにする。
クレームへの不誠実な対応	不誠実なメールの回答や電話のやりとりの音声ファイルがネットで公開されて炎上の原因になったこともある。
利用者の反社会的な投稿の放置	不適切な内容の投稿は炎上の原因になりやすく、素早く対処しないと運営会社への非難も高まる。

コミュニティの炎上は、同じような理由で同じような事例が繰り返される傾向にあります。2009年2月に、アメリカのFacebookでユーザーのコンテンツの権利に関する利用規約が改定された際、2008年3月にmixiで起きたこととほぼ同じ内容の炎上事件が発生しました。日本でも、2004年にQ&Aサイトの利用規約改定で説明不足から同様の騒動が起きていて、炎上を未然に防止することに注意を払っていれば、これらの事例から学ぶべきことは多かったと思われます。

-----------------------------------------------------------------
　◎初出：2009年6月8日
-----------------------------------------------------------------

第8回・ウイルスによるWebページ改ざん

今年の3月以降、Webページが改ざんされて、不正なJavaScriptの実行によりページを閲覧しただけでウイルスに感染してしまう事例が急増しています。現在、世界中で猛威を振るっているのが「JSRedir-R」もしくは「Gumblar」と呼ばれるウイルスで、日本では初期に感染したサイトの名前から「GENOウイルス」とも呼ばれています。GENOウイルスの最大の特徴は、ウイルスに感染したPCのFTPアカウントを乗っ取って、不正なコードを挿入したHTMLファイルを勝手にWebサーバにアップロードしてしまうことです。WebサーバにFTPでログインできるスタッフのPCが感染してしまうと、管理者の知らないうちにWebページが改ざんされてしまう可能性のある非常に危険なウイルスです。

Webページの改ざんとしては、データベースから自動生成されるWebページに不正なJavaScriptへのリンクを埋め込むSQLインジェクション攻撃などがありますが、改ざんされるのは攻撃されたWebサーバのみです。しかしGENOウイルスの場合は、改ざんされたWebページを閲覧して感染するPCが増えるに伴い、新たに改ざんされるWebページが加速度的に増えてしまいます。なお、GENOウイルスに感染してしまうと、FTPアカウントが乗っ取られるほか、ブラウザに表示されるサーチエンジンの検索結果を改ざんして悪意のあるサイトに誘導したり、PCを外部から遠隔操作できる不正プログラムを設置されたりすることが判明しています。

【トラブル事例】

2009年4月4日、PC販売サイト「GENO」のWebページが改ざんされているという情報が匿名掲示板に書き込まれました。その後、改ざんされたページにアクセスするとウイルス感染の危険性があることが確認されましたが、土曜日だったこともありサイト運営会社による対策が何も行われないまま、ウイルス感染者が増えるという状態が週明けの4月6日まで継続しました。6日になって一時サイトを閉鎖した後、週末閲覧した人はウイルス感染の可能性があるという事実を公表しないまま再開しました。一連の対応が遅かったため利用者からの非難が集中し、以後「GENOウイルス」と呼ばれる原因になりました。

GENOウイルスによるWebページの改ざんを防ぐには、Webサイト管理に関わっているスタッフ全員のPCがGENOウイルスに感染しないことです。GENOウイルスは、Flash PlayerとAdobe Readerの古いバージョンに存在する脆弱性を悪用していますので、まずはこの2つを最新版に更新することが基本的な対策となります。Windows Updateを実行するほか、ウイルス対策ソフトのパターンファイルを最新にすることも必須といえます。また、ブラウザでJavaScriptをオフの設定にすれば、GENOウイルス感染の確率を低くすることができます。GENOウイルスに限らず、登場した直後はウイルス対策ソフトで検出できるようになるまでタイムラグがあります。ウイルス対策ソフトを過信せず、日頃からリンク先が不明なURLは不用意に開かないという心がけも重要です。

PCを「GENOウイルス」に感染させないための対策

Flash PlayerとAdobe Readerを最新版に更新する	GENOウイルスではFlash PlayerとAdobe Readerの古いバージョンの脆弱性が悪用されている。
Windows Updateを実行する	OSのみならず、ブラウザなどアプリケーションすべてを最新版に更新することが好ましい。
ウイルス対策ソフトのパターンファイルを最新にする	パターンファイルがウイルスに対応できるようになるとウイルス対策ソフトは有効。
ブラウザでJavaScriptをオフの設定にする	JavaScriptがオフになっていれば、改ざんされたページを閲覧しても不正サイトには誘導されない。
リンク先が不明なURLは不用意に開かない	ウイルス対策ソフトを過信せずに、怪しいURLはクリックしないように日頃から注意する。

今回のGENOウイルス事件で改めて浮かび上がったのが、Webページの更新に普段よく使われているFTPというプロトコルの潜在的な脆弱性です。パスワードを含めて暗号化をせずにデータを送信するという仕組みがGENOウイルスに悪用されました。安全にデータを送信できるSFTPというプロトコルもありますが、すべてのWebサーバがSFTPに対応しているとは限りません。今回の事件をきっかけに、SFTPへの移行が進むことも予想されます。

-----------------------------------------------------------------
　◎初出：2009年6月1日
-----------------------------------------------------------------

第7回・なりすましによる不正ログイン

なりすましによる不正ログインとは、不正な手段で入手した他人のIDとパスワードを使って、本人になりすましてインターネット上で提供されているサービスのアカウントにログインすることを指します。パスワードが漏れてしまう原因としては、フィッシング詐欺やSQLインジェクションによる情報漏えいもありますが、他のサービスのアカウントと同じパスワードを使っていたり、IDやブログの記事から容易に類推される簡単なパスワードを使っていたりなど、利用者のパスワード管理の甘さによるものも少なくありません。また、ネットワーク管理者の会話を盗み聞きしたり、利用者になりすまして管理者に電話でパスワード変更を依頼するなどの「ソーシャルエンジニアリング攻撃」と呼ばれる手法を使ったパスワードの不正入手も増えています。

一般的なパスワード認証では、正しいIDとパスワードが入力されれば、本人と認証されてしまいます。情報漏えい以外による原因でパスワードが他人に知られてしまった場合は、利用者本人の責任という考え方もありますが、その原因を特定することは困難です。不正ログインで乗っ取られたネットオークションのアカウントが詐欺に悪用されたり、金融機関の口座から資金が不正に引き出されたりする事件が多発して、サイト運営会社が利用者の損失を補填するケースが増えています。そのため、不正ログインへの対策強化はサイト運営会社にとっても大きな課題になっています。

【トラブル事例】

2008年11月12日、イーバンク銀行の8つの口座が不正ログインされ、合計140万円が不正に引き出されるという事件が発生しました。直接外部の口座に送金すると身元がすぐに判明してしまうため、犯人はまず口座の資金を電子マネーに換金し、オンラインゲーム上で電子マネーを使ってアイテムを購入、さらにそのアイテムを換金するという手口で最終的に現金を手にしていたことがわかりました。イーバンク銀行は、不正ログインの事実が判明した12日の午後9時に不正ログインに使われたIPアドレス帯域にログイン制限をかけ、翌日午前中に制限を解除しました。

まず実施すべき対策としては、利用者にパスワード管理について注意を呼びかけることがあげられます。今年5月から、ヤフージャパンはログインアラート機能の提供を開始しました。ログインがあるごとに通知メールが配信され、誰かが不正ログインを試みていると気づけばログイン制限をかけることもできます。不正ログインの被害にあったイーバング銀行では、指定したIPアドレス以外からのログインを制限する「IP制限サービス」を提供していて、その利用を推奨しています。ログインを監視・管理できるツールを提供することで、利用者に不正ログイン防止に協力してもらおうという考え方です。

不正ログイン対策として採用されている手法例

パスワード管理の注意呼びかけ	IDなどから簡単に類推されそうなパスワードや、他のサイトと同じIDやパスワードを使わないよう利用者に注意を呼びかける。
不正ログイン監視の強化	利用者のログイン履歴やIPアドレスの位置情報などから、不審なログインを監視して、必要に応じてログイン制限の措置を取る。
ログインアラート機能の提供	ログインするごとに、利用者に通知メール（アラート）を配信。利用者がログイン制限をかけられる機能などを提供する。
ワンタイムパスワードの採用	アカウント保有者にワンタイムパスワード生成装置（トークン）を配布して、1回限り有効のパスワードで本人認証を行う。

ネットバンキングやオンライン証券など、不正ログインによる被害が大きくなる金融サービスでは、ワンタイムパスワードを導入する例が増えています。ジャパンネット銀行は、2006年9月からハードウェアトークン型のワンタイムパスワードによる認証に統一しました。口座開設者全員にワンタイムパスワードを生成する小型装置（トークン）を配布して、そのトークンに表示されるパスワードで本人認証を行う仕組みです。不正ログインの監視強化に加え、今後は不正ログインが発生しにくい認証方法の採用が進むと予想されます。

-----------------------------------------------------------------
　◎初出：2009年5月25日
-----------------------------------------------------------------

第6回・設定ミスによる個人情報漏えい

Webサイトから個人情報が漏えいする原因としては、不正アクセスやウイルス感染、セキュリティホールなどがあげられますが、システムの設定ミスによる個人情報漏えい事件も毎年数多くの事例が報告されています。設定ミスによる個人情報漏えいとは、本来、外部からアクセスできないはずの個人情報データが、サーバの設定ミスで誰でもブラウザから閲覧可能の状態に放置されていたような例を指します。データファイルにアクセスできるURLが匿名掲示板等に書き込まれてしまうと、短時間のうちに多くの人がダウンロードして情報が一気に拡散するという危険性があります。

日本ネットワークセキュリティ協会（JNSA）が公表した調査報告書によると、2007年に国内で公表された個人情報漏えい事件は864件で、うちWebサイト経由が15.4%、電子メール経由が9.8%となっています。漏えいの原因としては、「設定ミス」は全体の3.9%と低い数字に見えますが、バグ・セキュリティホールの1.2%、不正アクセスの0.8%に比べると高いことがわかります。SQLインジェクションなどの不正アクセスの脅威が注目されていますが、Webサイトからの個人情報漏えい事件の件数に限って言えば、不正アクセスよりも設定ミスによる漏えいの方が多いということになります。

【トラブル事例】

2008年12月5日、日本航空系のJALホテルズは、氏名やメールアドレスなど顧客の個人情報14万5052人分のデータが、10月10日から12月4日までの約2ヶ月間、Webサイトで外部から閲覧できる状態になっていたことを公表しました。顧客の1人から指摘があって12月4日にデータをWebサイトから削除しましたが、その間、Googleなどのサーチエンジンで個人情報が表示されていたことも判明しました。同社では、専用のフリーダイヤルを設けて、顧客からの問い合わせに応じるなど対応に追われました。

JALホテルズの例では、委託先企業がメール配信の作業をした際、本来は非公開に設定しておくべき顧客リストを、誤って公開と設定してしまったことが原因だと発表されています。Webサーバに個人情報を保存する場合は、ホームページよりも上層のディレクトリを作成して、そこに保存するのが基本です。これならURLでは表記できませんので、ブラウザからアクセスされることはありません。何らかの制約があってホームページよりも下層の位置にしか保存できない場合は、ブラウザからはアクセスできないようにパーミッション（アクセス権限）を設定します。

設定ミスによる個人情報漏えいを防ぐために確認すべきこと

データを保存するディレクトリの指定	データファイルは、URLで表記できないようにホームページよりも上層のディレクトリを作成して、そこに保存するようにする。
パーミッション（アクセス権限）の設定	ホームページよりも下層のディレクトリにしか保存できない場合は、ブラウザからURLを指定してもデータファイルにアクセスできないようにパーミッションを設定する。
汎用CGIのデフォルト設定をチェック	広く使われているCGIの中には、データを保存するディレクトリやパーミッションの設定がデフォルトのままでは危険な可能性もあるので、設定を確認する。
外部委託先へのガイドライン徹底	過去の事例を見ると、「外部の委託先による作業ミス」が原因であることも多い。外部委託先にはガイドラインを示して、その内容を徹底させる。

広く使われている汎用CGIや有料のASPでも、デフォルトのまま使用するとデータファイルが外部から閲覧できる場所に保存される設定になっている可能性があります。実際に、同じCGIを使っている複数のサイトからほぼ同時に個人情報が漏えいした事件も起きています。多くのサイトで使われているから安全のはずと過信せずに、データ保存場所の設定を再確認しましょう。設定ミスによる個人情報漏えいは、正しい設定ができていれば発生することはありません。しかし、これだけ事件が多発しているのも事実ですので、初歩的なこととはいえ念入りに確認することが重要です。

-----------------------------------------------------------------
　◎初出：2009年5月18日
-----------------------------------------------------------------

第5回・バッファオーバーフロー攻撃

バッファオーバーフローとは、データ書き込み用に確保したメモリ領域（バッファ）の量を超える大量のデータを入力することで、その以外のメモリ領域が上書きされて書き換えられ、プログラムが誤動作を起こしてしまう脆弱性のことです。「バッファオーバーラン」とも表現されます。多くのCGIやWebアプリケーションで使われているC言語やC++言語には、メモリに書き込んだデータがバッファに収まっているかどうかを自動的に確認できないという特性があります。プログラムを書く際に受け取るデータの長さ（バイト数）を制限していないと、バッファオーバーフローが発生する可能性が生じます。

バッファオーバーフロー攻撃は、サーバの機能を一時停止に追い込むDoS攻撃（サービス妨害攻撃）の一形態として行われることもありますが、主に不正プログラムを含んだコードを上書きして実行させることで、外部からシェルと呼ばれるOSに指示を与えるプログラムを起動するなどしてサーバに不正侵入する目的で行われます。最悪の場合は、管理者権限を不正に奪われ、システム全体が乗っ取られてしまうこともあります。バッファオーバーフロー攻撃は、ボットと呼ばれるウイルスに感染した第三者のPCを経由して行われることが多く、攻撃対象になったサーバには短時間で大量の攻撃が集中するのが特徴です。

【トラブル事例】

バッファオーバーフロー攻撃は、古くから存在する手法です。バッファオーバーフロー攻撃の脅威が広く認識された事件としては、2000年1月24日から2月にかけて続発した中央省庁のWebサイト改ざん事件が有名です。科学技術庁のWebサイトの内容が改ざんされたのを皮切りに、総務庁、総務庁統計局、運輸省のサイトが改ざんの被害に遭いました。その後の調査により、Webサイト改ざんの15件のうち6件が、バッファオーバーフロー攻撃によるものであることが公表されました。

バッファオーバーフロー攻撃への対策としては、入力されたデータをバッファに書き込む前に、データのバイト数や使われている文字の種類など妥当性を厳格にチェックすることが基本になります。書き込み上限バイト数を指定できないライブラリ関数は使用しないことも重要です。最近では、バッファオーバーフロー対策のために作られたライブラリやツールが公開されていますので、これらを活用することも有力な対策です。ただし、ツールですべてのバッファオーバーフロー攻撃が防げるわけではありませんので、ツールを過信するのは危険です。

バッファオーバーフロー攻撃の有効な対策

受け取るデータの妥当性チェック	バッファのサイズを超えて書き込めないようにデータのバイト数をチェックする、不適切な文字列を受け付けない、などの機能を実装する。
問題のあるライブラリ関数の不使用	書き込み上限バイト数や境界をチェックしない危険なライブラリ関数は使用しないようにする。
バッファオーバーフロー対策のライブラリやツールの導入	状況に応じてLibsafe、StackGuard、Openwallなどのライブラリやツールを導入する。
比較的安全なプログラム言語への変更	攻撃の対象となるWebアプリケーションを、バッファオーバーフローに対して比較的安全とされるJavaなどで書かれたプログラムに置き換える。

Webアプリケーションの脆弱性としては、最近ではSQLインジェクションやクロスサイトスクリプティングに注目が集まりがちですが、JPCERTコーディネーションセンターでは、バッファオーバーフローによる被害も相変わらず多く発生していると注意を呼びかけています。バッファオーバーフローの脆弱性は、潜在的に大量に存在していて攻撃手法も高度化していることから、完全に防御できる技術はまだ開発されていません。攻撃が成功する確率は低くても、攻撃を許してしまった場合の被害は大きくなるため、日頃からの対策と準備が必要です。

-----------------------------------------------------------------
　◎初出：2009年5月11日
-----------------------------------------------------------------

第4回・SYNフラッド攻撃

SYN（シン）フラッド攻撃とは、公開されているWebサーバなどに対して短時間で大量のリクエストを行うことで、サーバの機能を一時停止に追い込むDoS攻撃（サービス妨害攻撃）の手法の一つです。インターネットでデータのやりとりを行うTCPと呼ばれているプロトコルでは、接続を確立するに(1)クライアントがサーバに「SYNパケット」を送信、(2)サーバがクライアントに「ACKパケット」を返信、(3)さらにクライアントがACKパケットをサーバに送り返す、という3つの手順を踏む仕組みになっています。サーバはクライアントから最後のACKパケットが届くまでは、応答待ちの状態を保ち続け、その間メモリ領域などのリソースを開放できません。大量のSYNパケットを洪水のように送りつけて、サーバにACKパケットをわざと送り返さないことで、サーバが新たに接続を受け付けられなくするのが、SYNフラッド攻撃の基本的なパターンです。

SYNフラッド攻撃は、標的のサーバを一時的にダウンさせることが目的であり、個人情報を盗んだり、不正プログラムを仕込んだりすることはできません。また、SYNフラッド攻撃によってサーバのハードディスクなどの設備が物理的に破壊されることは稀で、攻撃が終了すると少しの時間を置いてサーバの動作も正常に戻ります。

【トラブル事例】

2006年9月12日、中国の大手サーチエンジン「百度」が大規模なSYNフラッド攻撃を受け、北京市など中国各地で百度の検索機能が利用できなくなる事態が発生しました。約30分後には復旧しましたが、同社では「過去最大規模のハッカー攻撃」だったことを後に発表しました。事件の背景や犯人の目的は不明ですが、膨大なリソースを確保しているサーチエンジンといえど、SYNフラッド攻撃の標的になるとサービス停止に追い込まれることを示した事件でした。

SYNフラッド攻撃は、現在のTCP接続の仕組みが変わらない限り、完全に防ぐことは難しいといわれています。しかしながら、最近ではOSにもSYNフラッドの検知等の予防策が講じられるようになっていて、被害を最小限に抑える対策が整いつつあります。たとえば、偽の送信元IPアドレスを持ったパケットを送りつけてくる「IPスプーフィング」を排除する設定ができるようになっています。また、侵入検知システムの利用によって、SYNフラッド攻撃に対してはTCP RESETパケットを送出することも有効な対策となります。

SYNフラッド攻撃の有効な対策

OSやファイアウォールの設定	IPスプーフィング排除する設定を行うことで、IPスプーフィングと組み合わせたSYNフラッド攻撃を防ぐことができる。
ネットワーク型侵入検知システムの利用	SYNフラッド攻撃と検知した場合は、ACKパケットに代わってTCP RESETパケットを送出するなどの対策を行う。
パケット・フィルタの設置	外部のネットワークとつながっているルータにパケット・フィルタを設置して、ネットワークの外に不正なパケットが出て行かないようにする。

今年2月に警察庁が公表した「2008年におけるサイバー犯罪の検挙状況」によると、警察庁が全国に設置した調査ポイントに対するSYNフラッド攻撃は、前年比4倍を超える約38万件に達したことがわかりました。攻撃元の約3分の2が中国だったこともわかりました。今後ともSYNフラッド攻撃の事例は増えていくことが予想されます。いつ攻撃の対象になっても、一通りの対策をすぐに発動できる準備をしておくことが重要といえます。

-----------------------------------------------------------------
　◎初出：2009年4月27日
-----------------------------------------------------------------

第3回・DNSキャッシュポイズニング攻撃

DNSキャッシュポイズニング攻撃とは、インターネットでドメイン名を参照するDNSサーバの情報を不正に書き換えて、特定のドメインにアクセスできないようにしたり、特定のドメインへのアクセスを全く別のサイトに誘導したりする攻撃のことです。DNS情報の書き換えによってドメインを乗っ取ることができるため、1990年代には「ドメインジャック」などとも呼ばれていました。偽の情報をキャッシュに書き込むことを「毒を仕込む」と形容して、DNSキャッシュポイズニングと呼ばれるようになりました。

DNSキャッシュポイズニング攻撃は、SQLインジェクションなどで偽のURLをクリックさせる行為と異なり、ユーザが正しいURLをブラウザに入力しても不正なサイトに誘導させるため、この脆弱性が存在することはインターネットの仕組みの根幹を揺るがす深刻なものといえます。過去、DNSサーバのソフトウェアに脆弱性が見つかるたびに、DNSキャッシュポイズニング攻撃の被害が報告されてきました。今後も、新しい脆弱性が見つかるたびに、DNSキャッシュポイズニング攻撃の脅威が繰り返し注目されるものと思われます。

【トラブル事例】

2008年7月29日、アメリカAT&TのISPが運営するDNSキャッシュサーバの一部キャッシュが書き換えられ、このISPを使っている会社のネットワークからiGoogleにアクセスすると、インフレームで広告をロードさせるWebページに置き換えられるという事件が発生しました。表示されるWebページには不正プログラムは仕掛けられておらず、広告を繰り返し表示することで広告料収入増加を狙ったものと推測されています。この会社のDNSサーバはちゃんとパッチを適用していましたが、上位のISPのDNSサーバの情報が書き換えられてしまうと、そのISPを使っている会社や個人にも広く影響が及んでしまうことがわかります。

2008年7月には深刻なDNSの脆弱性が発見され、本来関係者だけが閲覧できる詳細資料が誤って一般公開されるという事件が発生しました。攻撃用のサンプルコードも記載されていて、この資料を見た愉快犯が、誰でも簡単にDNSキャッシュポイズニング攻撃ができるツールを作ってインターネットで配布したことから、全世界でDNSキャッシュポイズニング攻撃の被害届出が急増しました。情報処理推進機構（IPA）が公表した2008年第3四半期の脆弱性関連情報の届出状況によると、日本でもDNSキャッシュポイズニングに関する届出がこの期間に急増しています。

DNSキャッシュポイズニングの有効な対策

パッチの適用や対策済ソフトへの更新	各DNSソフトベンダーからリリースされるパッチをいち早く適用する。
DNSサーバへのアクセス制限	「recursive query（再帰検索）」を受け付けるIPアドレスを制限する。
ポートのランダム化	ランダム化でトランザクションIDを推定される確率は、6万5000回に1回から1億6300万～21億回に1回へ減少。
フィルタリング	組織内のIPアドレスを送信元アドレスとする偽造パケットを拒否する設定に変更する。

DNSキャッシュポイズニングは、対策を施したDNSソフトウェアに更新したり、ベンダーがリリースしたパッチを適用することで、ほぼ確実に防げます。しかしながら、脆弱性が発見された直後ではパッチが間に合わないことがあり、DNSサーバへのアクセス制限やポートのランダム化、フィルタリングなどの自衛手段を講じる必要があります。IPAは、DNSキャッシュポイズニング対策の検査ツールの使用方法や、DNSの適切な設定方法が詳しく説明した資料を今年1月に公開しています。このような資料を参考にして、自社のDNSサーバに脆弱性が残っていないかどうかを再度確認したほうがいいでしょう。

-----------------------------------------------------------------
　◎初出：2009年4月20日
-----------------------------------------------------------------