みなさんこんにちは。
FUJITSU その2 Advent Calendar 2018 17日目の記事担当は私 ゆきはらです。
前回14日目はkeiya-nobutaさんのSphinxの導入とLinux Kernelドキュメントのビルドで、
18日目はhasunumaさんの富士通サイバーセキュリティーワークショップ(FCSW)2018参戦記となっています。
#はじめに
##なぜこのテーマにしたか
Webアプリケーションに対する代表的な攻撃手法としてXSS（クロスサイトスクリプティング）とCSRF（クロスサイトリクエストフォージェリ）というものがあります。
しかしこの二つ、名前だけでなく攻撃手法も似ていて違いがとてもわかりづらいです。かつて私がセキュリティを勉強していたときもよく混同していました。
そこで、この記事ではXSSとCSRFの仕組みとそれらの違いについてまとめることにしました。
対象とする読者は以下の通りです。
・若手SE
・若手Webエンジニア
・基本/応用技術者試験、登録セキスペ勉強中の方
##著者は何者か
FUJITSUで業務Webアプリケーションの設計・開発に従事しているSEです。
セキュリティの専門家ではありません。情報セキュリティスペシャリストは保持しています。
##注意事項
- 当記事ではXSSおよびCSRFの攻撃手法、事象、対策の一部分を示すのみであり、それらすべてについて言及していません。
- XSSおよびCSRFの攻撃パターンは様々ありますが、今回は攻撃者が不正なURLをTwitterに投稿したものとします。
- 記事の内容はすべて個人の見解であり、会社・組織を代表するものではありません。
#XSSとは何か
それでは本題に入ります。
まず、そもそもXSSとは一体何なんでしょう。ということで、トレンドマイクロさんに聞いてみました。
一言でいうと、**「ユーザーがWebページにアクセスすることで不正なスクリプトが実行されてしまう脆弱性または攻撃手法」**のことです。
クロスサイトスクリプティングとは、ユーザのアクセス時に表示内容が生成される「動的Webページ」の脆弱性、もしくはその脆弱性を利用した攻撃方法のことです。動的Webページの表示内容生成処理の際、Webページに任意のスクリプトが紛れ込み、Webサイトを閲覧したユーザ環境で紛れ込んだスクリプトが実行されてしまいます。
出所：クロスサイトスクリプティング（XSS） (TREND MICRO)
##XSSの全体像
文章より図の方がわかりやすいだろうと思い、XSS攻撃の一連の流れを図にしてみました。
今回は、攻撃者がTwitterに投稿した怪しげなURLをとあるTwitter利用者がクリックしてしまったケースを想定しています。
【前提】
・WebアプリケーションにXSS脆弱性が存在する
##XSSによる被害例
-
攻撃者による不正ログイン（なりすまし）
利用者のCookieが攻撃者の手に渡ることで、Cookie内にある利用者のセッション情報がそのまま使用されてしまい、利用者の名をかたってサービスを使用されてしまう危険性があります。
##XSSへの代表的な対策
-
Webページに出力するデータのエスケープ処理
Webページの出力に際して特別な意味を持つ文字列（例えば「<」、「&」など）は単なる文字列として出力するようにしましょう。また、エスケープの対象としては、利用者が画面から入力した値はもちろん、外部システムからのデータなどWebページの出力対象となるものは必ずエスケープすることが重要です。
#CSRFとは何か
またトレンドマイクロさんに聞いてみました。
一言でまとめると、**「Webアプリケーション利用者自身が意図しない処理が実行されてしまう脆弱性または攻撃手法」**のことです。
クロスサイトリクエストフォージェリ（CSRF）とは、Webアプリケーションに存在する脆弱性、もしくはその脆弱性を利用した攻撃方法のことです。掲示板や問い合わせフォームなどを処理するWebアプリケーションが、本来拒否すべき他サイトからのリクエストを受信し処理してしまいます。
出所：クロスサイトリクエストフォージェリ（CSRF） (TREND MICRO)
##CSRFの全体像
XSSと同じく、CSRF攻撃の一連の流れを図にしてみました。
【前提】
・WebアプリケーションにCSRF脆弱性が存在する
・利用者はWebアプリケーションにログイン済みの状態であり、セッションを保持している
##CSRFによる被害例
-
利用者の意図しないWebアプリケーション上の処理実行
図でも表したように、本来はログインした利用者のみが許される記事の投稿処理などがあげられます。
##CSRFへの代表的な対策
-
Formページ返却時のトークン付与
今回の例でいうと、はじめに掲示板への書き込み画面を表示する際にサーバがクライアントに対して特定の文字列（トークン）を設定します。実際に書き込みのリクエストがあった際にサーバーが**「この人に送ったトークンと同じトークンがリクエストに入ってる？」**と確認することで、攻撃者からの不正なリクエストを防ぐことができます。これは、攻撃者は利用者に送信したトークンの値を知らないためです。
#XSSとCSRFの違い
Webアプリケーションの脆弱性を利用した攻撃という点は一致していますが、XSSとCSRFは何が同じで何が違うのでしょう。
ということで、XSSとCSRFの共通点と違いを表で整理してみました。
なお、以下の表で「実行」との記載がある場合は、「不正な処理の実行」という意味で解釈してください。
| 観点 | XSS | CSRF |
|---|---|---|
| 脆弱性の存在箇所 | Webアプリ | |
| 実行契機 | 不正なURLへのアクセス | |
| 実行される場所 | Webブラウザ (Client) |
Webアプリサーバ (Server) |
| 実行可能な処理 | 基本的に自由*1 | Webアプリで 定義された処理 |
| 実行の前提 | 特になし | Webアプリに ログイン済み*2 |
弊社のアドベントカレンダーは二つありますのでお時間あるときにぜひお読みください！
FUJITSU その2 Advent Calendar 2018
FUJITSU Advent Calendar 2018
#参考資料
- 安全なWebサイトの作り方 （情報処理推進機構）