情報処理安全確保支援士過去問題 平成29年秋期 午後Ⅰ 問2
⇄問題PDFと解説を画面2分割で開く⇱問題PDF設問1
- ア：9
- イ：11
- 必要な全てのコード：カ，ア，イ，ウ
- 21，22，23
- ウ
解説
〔Wシステムの実装に関する脆弱性〕では、本番システムのサーブレットSearchServletに関して、SQLインジェクションおよびクロスサイトスクリプティング(XSS)の脆弱性があるとされています。設問1はこれらの攻撃につながる脆弱性と対策方法の知識が問われています。
- 〔アイについて〕
SQLインジェクション脆弱性が存在するコードの範囲を特定することが求められています。
SQLインジェクションは、利用者の入力情報をそのままSQL文に組み込んでいることが原因で発生します。図1のJavaコードを確認すると、9行目で実行するSQL文を作成し、その際に利用者からの入力情報である cname がSQL文に直接連結されています。その後、10行目でSQLステートメントを作成され、11行目でSQL文を実行しています。この一連の処理では、プレースホルダを使用せずにSQL文を実行しているため、SQLインジェクション攻撃を受けるリスクがあります。このため、プレースホルダを使用するように、9～11行目を修正する必要があります。
なお、5行目はHTMLコードから入力情報 cname を受け取るだけの処理なので対象外。6～7行目および12～29行目は、SQL文を実行後に得られた分析結果をHTMLとして出力処理する部分なので対象外となります。
∴ア＝9、イ＝11
〔書き換えるコードについて〕
SQLインジェクション脆弱性への対策としては、SQL文を組み立てる際にプレースホルダを用いることが根本的な解決法となります。プレースホルダとは、SQL文内で値や情報を埋め込む位置を示す記号（「?」など）のことで、これを使うことで、ユーザーからの入力情報が直接SQL文内に埋め込まれることを防ぎます。具体的には、プレースホルダを使ったSQL文のひな型を作成し、SQL文の実行前（または実行時）にエスケープ化された入力情報をパラメータとして割り当てることで、安全にSQL文を実行することができます。
プレースホルダを利用したSQLの実行手順は次のとおりです。- プレースホルダを用いてSQL文のひな型を作成する
- 1.のひな型を基に実行用のオブジェクトを作成する
- オブジェクトにパラメータとして入力情報を割り当てる
- SQL文を実行し、結果を得る
- SQL文のひな形の中に、バインド変数『?』を置く（オ）
- PreparedStatementメソッドを使用して、プリペアドステートメントを作成する（ア）
- setString()やsetInt()メソッドを使用して、プリペアドステートメントに変数値をバインドする（イ）
- executeQueryメソッドでSQL文を実行する（ウ）
∴カ，ア，イ，ウ - XSSは、利用者からの入力情報をWebページに表示する際に、攻撃者が仕込んだ悪意のあるスクリプトが実行されてしまう脆弱性です。
N氏の指摘によると、「XSS脆弱性を招く可能性を否定できない箇所については，HTML形式での出力時に処置するよう改修する」とのことです。図1のプログラムを見ると、データベースから取得した値をHTML形式で出力している箇所はrs.getStringメソッドが含まれる21～23行目であり、ここが改修すべき部分です。
∴21，22，23 - XSS脆弱性に対する根本的な対策として、Webページの本文やHTMLタグの属性値など、すべての出力要素にエスケープ処理を施すことが必要です。XSS対策としてのエスケープ処理（サニタイジング）では、HTML文書の出力時に、少なくとも & < > ' " の5種類の文字を実体参照（& < > ' "）に置き換える必要があります。したがって解答は「ウ」となります。
- CSRFトークンは、トークン（秘密情報）を利用してリクエストが正規のものであることを検証し、CSRF攻撃を防ぐための対策です。
- Refererヘッダーの確認は、CSRF対策のひとつです。あくまでも補助的な対策であり、CSRFトークンなどの他の対策と合わせて使用されます。
- 正しい。エスケープ処理は、XSS脆弱性の根本的な対策方法です。
- 同一生成元ポリシー（Same-Origin Policy）は、異なるオリジンに対するリソースのリクエストを制限するブラウザのセキュリティ機能です。XSS/CSRF/クリックジャッキングなどの対策です。
- バインド機能は、プレースホルダを用いたときにプレースホルダの部分に実際の値（バインド値）を割り当てる機能で、SQLインジェクション対策のひとつです。
設問2
- a：エ
- b：イ
- 認証後のリダイレクト先のURLを，WシステムのFQDNのものに限定する。
解説
- 〔abについて〕
Cookieにどのような属性を設定すればよいかという問題です。Cookieの属性とその機能は以下のようになっています。- Expires
- Cookieの有効期限を設定する
- HttpOnly
- JavaScriptからCookieのアクセスを禁止する
- Max-Age
- Cookieの有効期限を設定する
- Secure
- リクエストURLがHTTPSである場合のみ、サーバにCookieを送信する
- SameSite
- 外部ドメインから自ドメインに遷移する際のCookie送信を制御する
∴a＝エ：Secure、b＝イ：HttpOnly - N氏の指摘によれば、Wシステムでは認証後のリダイレクタ機能には、オープンリダイレクタの問題があるとされています。オープンリダイレクタとは、パラメータで指定されたURLにリダイレクトする機能が、悪用される可能性がある脆弱性です。Wシステムのように、リダイレクト先のURLをパラメータとして指定できるシステムにおいて、"リダイレクト先URLとして使用されるパラメータの値"に制限がない場合、パラメータに罠サイトのURLを指定されることにより、攻撃者が用意したサイトに誘導されるなどの被害が生じる可能性があります。
例えば、A社のWシステムの利用者に対して、次のURLを含むメールが送られたとします。https://w-system.a-sha.jp/LoginServlet?redirect_url=https://attacker.com/利用者は、ログイン後に罠サイトである https://attaker.com/ にリダイレクトされるため、そこでcookieや個人情報が盗まれる可能性があります。
Wシステムの特性を考えてみると、総ページ数は8と限られており、ログイン後にWシステム以外のページに遷移させる必要はありません。リダイレクト機能で問題となるのは、Wシステムとは関係ないサイトに誘導できてしまう点なので、リダイレクト先のURLとして任意のURLを許可せず、自サイトのドメインのみを許可するようにすることが有効です。リダイレクト先のURLのドメインを制限するのは、オープンリダイレクタの脆弱性への一般的な対策です。
この制限のために使用されるのがホワイトリストです。したがって、ホワイトリストに必要な仕様は、認証後にリダイレクトする先のURLとして、WシステムのFQDN（ドメインではA社の別のシステムにリダイレクト可能なのでNG）のみを許可することです。Wシステムは8ページで構成されるので、すべてのページのURLをホワイトリストに登録する運用も可能です。
∴認証後のリダイレクト先のURLをWシステムのFQDNのものに限定する
設問3
- セキュリティ検査を本番システムに対し行うこと
- ブラウザによってはXSS攻撃を遮断する機能をもつから
- Wシステムで当該脆弱性に対処する前に始まる攻撃によって，セキュリティ侵害されてしまうリスク
解説
- A社では、Wシステムのセキュリティ検査を、あらかじめ定められた手順に従ってK氏が手動で実施しています。しかし、「N氏が脆弱性検査ツールを使って本番システムを検査したところ…脆弱性があることが判明した」とあり、本番システムにセキュリティ検査を行っていれば早期に脆弱性を発見できた可能性があります。
開発環境と本番環境は異なるため、開発環境で発見された脆弱性が本番環境でも修正されているとは限りません。今回の状況では、K氏が開発環境で脆弱性を修正しましたが、F氏がその修正版を本番環境にデプロイすることを忘れてしまい、結果として本番環境には脆弱性が残存していました。本番環境へのデプロイ忘れを防ぐことや、実際の運用環境において脆弱性が存在しないことを確実にするためにも、セキュリティ検査は本番システムに対して行うことが必要です。
∴セキュリティ検査を本番システムに対し行うこと - 下線④の一文を確認すると「一部のブラウザではXSS攻撃の試みを完遂できないことがある」と記述されています。
ブラウザによっては、以下のようなXSS攻撃を検知して遮断する独自機能を内蔵していることがあります。- X-XSS-Protection
- CSP（Content Security Policy）
- XSSフィルター
「手動の検査では検査の見落としが発生する可能性があるから」といった内容では不十分です。
∴ブラウザによってはXSS攻撃を遮断する機能をもつから - 下線⑤を含む一文を確認すると「Sサービスを利用していれば，WAFを使用せずにWシステムを改修するケースと比較して，Webアプリケーションサーバへのリスクを軽減できる」と記述されています。
Wシステムの脆弱性はK氏が検査によって発見し、修正プログラムも先月作成済みでしたが、本番システムにはデプロイされていませんでした。そのため、Wシステムは先月から今まで脆弱性があるまま運用されていたと読み取れます。この間、セキュリティ侵害されてしまうリスクが存在したまま放置されていたことになります。
クラウド型WAFサービスは、Firewall as a Service（FWaaS）とも呼ばれ、インターネット上で動作するWAFサービスを提供するものです。「Sサービスでは、Webシステムに脆弱性が発見された場合、短時間で適切なシグネチャがWAFに追加される」とあるように、クラウド型WAFサービスではネットワークに流れるトラフィックをリアルタイムに監視し、迅速にWAFルールの更新を行います。
脆弱性をなくすにはその原因となっている部分を修正することが根本的な対策です。しかし、通常この修正には時間がかかります。クラウド型WAFサービスでは脆弱性がされると短時間で自動的にWAFルールが追加されるので、脆弱性が修正されるまでの間の保険的な対策となり、その脆弱性を突いた攻撃を受けるリスクを低減することができます。したがって、WAFを利用しない場合と比較して低減できるリスクとは、「Wシステムの脆弱性が発見されてから修正が適用されるまでの間に、その脆弱性を利用した攻撃を受けるリスク」などの回答が適切となります。
∴Wシステムで当該脆弱性に対処する前に始まる攻撃によって，セキュリティ侵害されてしまうリスク