XSS脆弱性の分析【情報処理安全確保支援士試験 平成30年度 春期 午後2 問1 設問1】
情報処理安全確保支援士試験 平成30年度 春期 午後2 問1 設問1
問1 セキュリティ対策の評価に関する次の記述を読んで、設問1〜4に答えよ。
R団体はある科学技術分野のノウハウを有する、職員数300名の一般社団法人である。特殊な用途に用いる精密機器のプロトタイプ製作、民間企業や教育機関への技術情報の提供、安全基準の助言などを行っている。R団体とステークホルダとの関係を図1に、ステークホルダの概要を表1に示す。
R団体の各部署の業務内容を表2に示す。
プロトタイプ製作業務において扱う情報は全て機密性が高く、その中でも図面は特に機密性が高い。
R団体では、一般業務用のPCが職員に1台ずつ貸与されており、Web閲覧、メール送受信、図面作成などに利用されている。各PCには固定IPアドレスが割り当てられている。PCにログインする際には各職員の利用者IDを入力する。R団体のネットワーク構成を図2に示す。
Rポータルは、利用者の認証機能、利用者ごとに権限を定義できるアクセス制御機能、ファイルをアップロード及びダウンロードできる文書共有機能、問合せ内容や回答の履歴を記録する掲示板機能を備えている。Rポータルの利用者IDは、職員、会員組織、及び製作パートナに発行される。
また、Rポータルは、フロントエンドのWebAPサーバと、会員組織情報、要求仕様書や図面が保存されるバックエンドのDBサーバで構成され、WebAPサーバとDBサーバはODBC（Open Database Connectivity）を用いて特定のポート間で通信している。R団体のセキュリティ対策基準にのっとり、DBサーバには、システム運用課員によるログインと、WebAPサーバからの接続だけが許可されている。利用者セグメントからDBサーバへのアクセスは、FWによって運用管理PCのIPアドレスからのアクセスだけが許可されている。
人事サーバ管理での人事データの更新には二つの方法がある。通常の更新は、人事サーバのWebインタフェースを使用してPC上で行う。期初などの大量の人事異動が発生するタイミングでは、PCからリモートデスクトップ機能を使い、一度、踏み台サーバの利用者ID（以下、管理IDという）を用いて踏み台サーバにログイン後、さらに、踏み台サーバからリモートデスクトップ機能を使い、共通の利用者IDとパスワード（以下、共通管理者アカウントという）で人事サーバにログインして、一括で更新している。管理IDは職員ごとに異なっている。R団体では、踏み台サーバを除き、サーバセグメントとDMZに置くサーバでは、運用負荷軽減の観点から、共通管理者アカウントが設定されている。
サーバセグメント内のサーバでは、表3のアクセスだけを許可している。
踏み台サーバには操作記録機能があり、ログインした利用者のデスクトップ画面が数秒間隔で画像データとして記録され、実行したコマンドやキーボード入力がテキストで記録される。全てのサーバがアクセスログを取得しており、どの利用者IDによっていつログイン、ログアウトしたかの記録が残る。踏み台サーバの利用者管理はシステム運用課が担当している。
FWのフィルタリングルールを表4に示す。
【セキュリティ対策の評価】
今年に入り、関連業界を狙ったサイバー攻撃が急増しているという話を聞き、R団体の理事がセキュリティコンサルタント（以下、コンサルタントという）に相談したところ、セキュリティ対策の評価を勧められた。そこで、図面及び会員組織情報と、それらが保存されているDBサーバについて、セキュリティ対策が適切か、コンサルタントによる評価を受けることにした。
さらに、R団体の理事は、かねてから付き合いのあるベンダに相談し、情報処理安全確保支援士（登録セキスペ）のM氏に、R団体のシステム企画課に主任として出向してきてもらい、同じシステム企画課のNさんとともに、コンサルタントの評価結果への対応を検討してもらうことにした。評価では、検査ツールを用いたRポータルの脆弱性検査や、職員へのインタビューを通しての秘密情報の取扱状況確認と、セキュリティ対策基準の妥当性確認などが行われた。
2か月後、コンサルタントは、評価結果を理事に報告した後、図3に示す評価結果の詳細を、M主任とNさんに説明した。
理事から対応計画を策定するように指示があり、M主任とNさんは、それぞれの検出事項について、一つ一つ対応方針を検討することにした。
【検出事項1の対応方針の検討】
次は、XSS脆弱性についてのNさんとM主任の会話である。
Nさん：脆弱性1は、検索ページの一部のGETパラメタで起こるようです。今回の脆弱性検査では、脆弱性1の検知には、攻撃コードとして、スクリプトに相当する文字列を含めたリクエストをサーバに送信したときに、その文字列がレスポンス中にスクリプトとして出力されるかどうかで判断する方法（以下、検知方法1という）を用います。一般的にはWAFを導入すれば、攻撃者が脆弱性1の有無を分析しようと攻撃試行すると、検知できます。
M主任：そのとおりだね。R団体では、WAFは導入していないが、もし導入して、かつ、攻撃試行があったとしたら、攻撃試行を検知できていたかもしれないな。
Nさん：では、脆弱性2は、検知方法1やWAFで検知できますか。
Nさんの質問に対して、M主任は次の二つを説明した。
・①検知方法1では脆弱性2を検知できない。
・WAFでも脆弱性2を検知できない。②Rポータルへのアクセスを繰り返すことなく、脆弱性2の有無を分析する方法がある。
①について、サーバからのレスポンスの内容を見て脆弱性を判断するツールを用いた場合、脆弱性2を検知できないのはなぜか。その理由を35字以内で具体的に述べよ。：脆弱性の有無によってサーバからのレスポンスに違いがないから
検知方法1は「攻撃コードとして、スクリプトに相当する文字列を含めたリクエストをサーバに送信したときに、その文字列がレスポンス中にスクリプトとして出力されるかどうかで判断する方法」とあります。
その検知方法1で、脆弱性1は検知でき、脆弱性2は検知できないのはなぜか考えます。
脆弱性1、2は、検出事項1にあるように、クロスサイトスクリプティング（XSS）脆弱性の一つです。
クロスサイトスクリプティング（XSS：Cross Site Scripting）は、リクエストやHTTPヘッダに含まれる情報をWebページに出力する処理に問題がある場合、そのWebページに攻撃者が用意したスクリプトが不正に埋め込まれてしまう脆弱性や攻撃のことです。
XSSの脆弱性は以下の3種類に分類されます。
- 反射型XSS（Reflected XSS）：リクエストに含まれる「スクリプトに相当する文字列」を、Webアプリケーションがレスポンス（Webページ）内に「スクリプト」として出力してしまうタイプ。
- 格納型XSS（Stored XSS）：リクエストに含まれる「スクリプトに相当する文字列」を、Webアプリケーション内部に永続的に保存し、当該Webページへのレスポンス（Webページ）内に保存した文字列を「スクリプト」として出力してしまうタイプ
- DOM-based XSS：Webページに含まれる正規のスクリプトにより、動的にWebページを操作した結果、意図しないスクリプトをWebページに出力してしまうタイプ。DOM（Document Object Model）は、アプリケーションがHTMLを操作するためのAPIです。
反射型XSS、格納型XSSでは、WebアプリケーションのWebページ出力処理に問題があることに起因する脆弱性です。
一方、DOM-based XSSでは、Webブラウザ上で実行される正規のスクリプトによるWebページ出力（DOM操作）に問題があることに起因する脆弱性です。
したがって、DOM-based XSSである脆弱性2では、検知方法1のレスポンスによる検知はできないことになります。
②について、脆弱性の原理を踏まえ、攻撃者が分析する方法を40字以内で述べよ。：スクリプトを分析し、フラグメント識別子の値の変化による挙動を確認する。
フラグメント識別子とは、HTMLでWebページのある特定の部分を識別して指定するための名前のことをいいます。例えば、「http://www.example.jp/index.html#id=xxx」の#以降の部分です。
Webブラウザは、#以降の文字列はWebサーバに送信せず、クライアント側で処理します。
攻撃者は、この#以降のフラグメント識別子の値の変化によってスクリプトの挙動を分析することで、DOM-based XSSの脆弱性があるかを確認することができます。
次は、XSS脆弱性への対処についてのNさんとM主任の会話である。
Nさん：脆弱性1及び脆弱性2について、早急に開発業者に脆弱性の修正を依頼します。
M主任：Rポータルはセッション管理をCookieで実現しているので、XSS攻撃によってCookieを窃取されないようにする必要がある。③Rポータルの動作に影響が出ないことを確認した上で、Cookieの発行時にHttpOnly属性を付与するように修正した方がいい。
【出典：情報処理安全確保支援士試験 平成30年度 春期 午後2問1（一部、加工あり）】
③について、Rポータルがどのような実装方法を用いている場合に動作に影響があるか。45字以内で述べよ。：Rポータルが利用しているスクリプトがCookieの値を利用している場合
HttpOnly属性とは、Cookieに設定できる属性の一つで、HttpOnly属性が設定されたCookieはHTTPでしか送信されず、HTMLテキスト内のスクリプトからのアクセスが禁止される状態となります。これにより、XSS脆弱性をもつWebサイトであっても、それによるCookieの窃取を防ぐことができます。
ただし、Webアプリケーションで利用しているスクリプトがCookieを利用している場合には、動作に影響が出るため、事前に確認が必要です。
