ウェブアプリの脆弱性を狙うXSSとCSRF その仕組みの違いと対策
本記事はキヤノンマーケティングジャパンが提供する「マルウェア情報局」に掲載された「クロスサイト・スクリプティング（XSS）とクロスサイト・リクエスト・フォージェリ（CSRF）の違い」を再編集したものです。
インターネットの普及により、私たちはWebサイト上でさまざまなサービスを受けることが可能になった。その一方で、こうしたWebアプリケーションの脆弱性を狙った攻撃は年々増加している。本記事では、その中でも古典的ながら今なお代表的な脆弱性で、混同されがちなクロスサイト・スクリプティング（XSS）と、クロスサイト・リクエスト・フォージェリ（CSRF）について、改めて仕組みの違いや過去の被害事例、対策を整理し紹介する。
クロスサイト･スクリプティング（XSS）とは
2019年10月24日に独立行政法人情報処理推進機構（IPA）が発表した報告資料によると、2019年第3四半期におけるWebサイト脆弱性に関する届け出件数は278件。そのうち、約58％をクロスサイト・スクリプティング（以下、XSS）が占めている。脆弱性はセキュリティホールとも呼ばれ、アプリケーションのプログラムの不具合や設計ミスによって発生するセキュリティ上の欠陥だ。XSSはその中でも代表的な脆弱性の一つである。
XSSはユーザーの情報入力によって動的にページを生成するWebサイトやサービスにおける脆弱性、またはその脆弱性を狙った攻撃そのものを指す。動的にページを生成するWebサイトとは、インターネット掲示板などが代表例として挙げられる。
通常、インターネット掲示板にユーザーが情報を書き込む際には、入力フォームに必要事項を記入し送信ボタンをクリックする。そして、その情報がWebブラウザーからサーバーに送信される。サーバーはリクエストを受け取り、その情報を元に生成したページをブラウザーに返す。この際、掲示板が設置されたWebサイトにXSSの脆弱性があると、攻撃者はその入力フォームを利用し悪意のあるスクリプトをURLなどの形で埋め込むことが可能になる。
ユーザーが掲示板に埋め込まれたURLをうっかりクリック、あるいはページによっては開いてしまっただけでも、不正なスクリプトがブラウザー上で実行され、ページの改ざんや情報漏えいなどさまざまな事象を引き起こす。攻撃者が狙う典型的なものはユーザーのCookie情報だ。ログイン情報などを管理しているCookie情報を盗み出すことで、攻撃者は不正ログインやなりすましが可能となり、さらなる個人情報漏えいを招きかねない。
クロスサイト･リクエスト･フォージェリ（CSRF）とは
クロスサイト・リクエスト・フォージェリ（以下、CSRF）も、代表的な脆弱性として知られる。XSSは動的なWebサイトにおける入力フォームの脆弱性だが、CSRFはWebアプリケーションのセッション管理に関する脆弱性のことである。
セッションとはWebアプリケーションとWebブラウザー間で、ページの状態を管理するための共通チケットのようなものだと考えるといいだろう。Webアプリケーションにこの脆弱性があり、かつユーザーがそのWebサイトにログインしている場合に攻撃を受けてしまう。
まず、ユーザーがいつも通りWebサイトにアクセスしログインをすると、WebサイトからセッションID（Cookie）が発行される。次に、攻撃者は何らかの方法で正規のWebサイトに偽装した偽サイトへユーザーを誘導する。ユーザーが知らずに正規Webサイトへの攻撃用リクエストを含んだURLをクリックすると、ブラウザーから正規WebサイトのセッションIDが付与された状態で攻撃リクエストが送信されてしまう。
Webアプリケーション側にCSRFの脆弱性がある場合、この攻撃リクエストを正しいリクエストだと誤認してしまい、本来はログインしなければできないような処理、例えばアカウント情報の変更や入出金などの操作が不正に行われる。この攻撃の厄介な点は、ユーザーの知らないところでなりすましによる操作が実行されてしまうことだ。ユーザーはCSRFによって犯罪に巻き込まれたことを後になってから知ることになる。
XSSとCSRFによる被害事例
XSSとCSRFは混同されがちだが、脆弱性のタイプや挙動に違いがあることもあり、被害事例や対策も異なる。まずは実際に起きたXSS脆弱性による被害事例を紹介する。
・2009年5月に起きたオンラインゲームサイトおける不正ログイン
オンラインゲームを提供する企業のWebサイトにおいて、XSSの脆弱性に起因する不正ログインが発覚した。公式サイトの一部にXSS脆弱性があり、正規の操作を介さずにサービスへのログインを行える状況だったという。本件において大規模な個人情報漏えいはなかったとされている。
・2010年7月に起きた動画投稿サイトにおける不正ポップアップ表示
大手動画投稿サービスのコメント投稿システムにXSS脆弱性があり、それを悪用した不正なポップアップ等が表示された。運営元のGoogleにより2時間ほどで対処されたが、Cookie情報の取得や悪質なスクリプトを埋め込むことが可能な状況だったという。
・2010年9月に起きたSNSサービスにおけるタイムライン汚染
XSSの脆弱性によりJavaScriptをそのまま投稿でき、ユーザーのブラウザー上で実行可能な状態にあった。これによりユーザーのアカウントがハイジャックされ、意味不明なリツイートを大量投稿するなどの被害が発生した。影響範囲は極めて広く、50万ユーザーに達するとされる。
・2014年1月に起きた出版社オフィシャルサイトの改ざん
XSSの脆弱性による不正アクセスによって大手出版社の公式サイトが改ざんされるという事件が起きた。改ざんされたWebサイトにはトロイの木馬が仕込まれ、閲覧者が感染するとCookie情報などの個人情報が漏えいする危険性があった。
次に、CSRFの脆弱性が原因で起きた被害事例を紹介する。
・2005年4月に国内SNSサービスで起きた不正リクエスト
国内大手SNSサービスにおいて、特定のURLをクリックすると「ぼくはまちちゃん！」というタイトルの日記が勝手に投稿されてしまうという被害が発生した。CSRFの脆弱性が原因で本来であれば正しくログインしなければ行えない日記投稿という処理がユーザーの意図しない形で実行可能な状況にあった。
・2009年12月に起きたブログサービスの不正リクエスト
ブログサービスに対し、CSRFの脆弱性による攻撃が行われた。ユーザーが特定のURLをクリックすると、自動的に「hamachiya2（はまちや2）」というユーザーをフォローし、意図しない投稿が行われるようになっていた。
・2012年に起きたパソコン遠隔操作事件
神奈川県某市のWebサイトにある意見投稿コーナーに、同市の小学校に対する無差別殺人予告が投稿された。本件において犯人はCSRFの脆弱性を突き、無関係な第三者のパソコンを介して書き込みを実行していた。この投稿によりパソコンを有していた大学生が実際に逮捕・起訴されたが、のちに神奈川県警が誤認逮捕を認め謝罪している。この事件は複数の被害が発生しており、大がかりな捜査が行われ、のちに真犯人は逮捕された。
これらの被害事例からもわかるように、XSSやCSRFの脅威はどこにでも潜んでおり、またその悪質性は極めて高い。大手企業が提供する、有名なWebサービスといえど例外ではない。開発する側の意識向上はもちろんのこと、利用者側も巻き込まれた場合の被害の大きさを認識し、適切な対応を常に心がけるべきだろう。
XSSとCSRFの対策
･XSSへの対策
XSSの脆弱性は、入力フォームに混入されたHTMLやJavaScriptが実行されてしまうことに起因する。これを回避するにはWebアプリケーションやWebサイト開発時に、フォーム入力値の制限やサニタイジング（エスケープ）といった処理を行うことが基本的な対策となる。また、ファイアーウォールや不正侵入検知（IPS/IDS）に加え、Webアプリケーションファイアーウォール（WAF）の導入も効果的な対策だ。
･CSRFへの対策
CSRFはWebアプリケーションのユーザー識別が、ブラウザーから自動送信されるもののみである場合に起こり得る。この脆弱性を回避するためには、正しいリクエスト元であることを判断する仕組みが必要だ。代表的な対策としてはワンタイムトークンの発行がある。
まず、フォーム入力前のWebページでトークンを発行しておく。リクエスト時に送信されたトークンと入力前のトークンを比較し、正しいリクエスト元であるかどうかを判別するというものだ。攻撃者が用意した偽のWebサイトからのリクエストには正規のトークンが含まれていないため、Webアプリケーションは偽のリクエストであると識別することができる。もうひとつの対策として、ログイン情報の変更や入出金など重要な操作が要求された場合に、パスワードなどの再認証を要求するという手段もある。
利用者側として注意すべきことは、怪しいリンクは安易にクリックしないことだ。正規のWebサイトにJavaScriptを埋め込み、ポップアップを表示させるような悪質なものもあるので注意してほしい。セキュリティソフトの導入など基本的なセキュリティ対策はもちろん実施しておきたい。被害に遭遇する可能性も低くなる。また、CSRFはWebサービスへのログイン状態を維持している場合に起こり得る。必要な操作を終えた後は必ずログアウトすることを習慣化しておくことが被害予防となる。
| XSSとCSRFの違い | ||
|---|---|---|
| XSS | CSRF | |
| 悪用される脆弱性 | WebサイトやWebサービスのコード | Webアプリケーションのセッション管理 |
| 実行される場所 | Webブラウザー（クライアント側） | Webサービス（サーバー側） |
| 前提条件 | ― | 脆弱性のあるWebサイトへのログイン |
| 悪用された場合のリスクの代表例 | 不正なスクリプトの実行、Cookie情報の窃取 | 不正サイトへの誘導、不正操作 |
| 主な対策（サイト運営者） | ・フォーム入力値の制限やサニタイジング（エスケープ） ・WAFの導入 |
・ワンタイムトークンの発行 ・WAFの導入 |
| 主な対策（サイト利用者） | ・怪しいリンクは安易にクリックしない ・セキュリティソフトの導入など基本的なセキュリティ対策 |
・怪しいリンクは安易にクリックしない ・セキュリティソフトの導入など基本的なセキュリティ対策 ・必要な操作を終えた後は必ずログアウトする |
さまざまな対策を施し､安全なWebサービスの運用を
最近では、XSSやCSRFを踏まえたセキュアコーディングが各所で進んだこともあり、これらの被害自体はあまり聞かれなくなっている。しかし、攻撃自体は今なお続いており、脅威がなくなったわけではないことに注意したい。これら対策のためにはセキュリティ人材が求められる｡しかし、大企業をはじめ、セキュリティ対策の充実を進める企業も増えセキュリティ人材のニーズが高まり、人材確保は難しくなってきている。そこで、対策としてセキュリティツールやサービスを利用する企業が増えている。
例えば、「SiteGuard」はWebアプリケーションを狙う攻撃に特化したWAF。専門家が認めた高い防御性能、チューニング済みの攻撃パターンファイルの標準搭載、純国産で日本語に完全対応しているためスムーズに導入できる。他にも、Webアプリケーション脆弱性診断サービスを併用することで､より強固なセキュリティを実現可能である。
通信環境の充実やモバイル端末の普及によって、ユーザーの消費行動が大きく変化し、新しいWebサービスが次々と生まれている。企業の競争は激化し、中には短期間でサービスをローンチせざるを得ないという社内事情が付きまとうこともあるかもしれない。タイトなスケジュールを優先し、安全性を軽視したことで起きた事故は枚挙にいとまがない。
残念ながら、多くの事故が発生しながらも、今なおXSSやCSRFの脆弱性が残されているWebサイト、サービスは少なくない。攻撃者は常に脆弱性を探し回り、Webサイトの改ざんなどの機会を狙っている。サービス提供側として、これら脆弱性の放置がユーザーの被害に直結し、自社の信用を大きく損なうことになることを強く意識してほしい。デジタルが日常生活の一部になりつつある現在、安全で利便性の高いサービスの提供が求められている。