情報処理安全確保支援士 2017年 秋期 午後1 問02

解答の導き方

1. SQLインジェクション脆弱性の原因になっている行を特定する
   図1の9行目では、利用者が入力したcnameを、文字列連結でSQL文に埋め込んでいます。

   9:  String sql = "SELECT * FROM companylist WHERE cname = '" + cname + "'";
   

   cnameは図2のフォームの入力欄（name="cname"）から送られてくる値なので、例えば“' OR '1'='1”のような文字列を入力されると、SQL文の条件そのものが書き換わってしまいます。これがSQLインジェクション脆弱性の原因です。
2. 置き換える範囲を決める（アは9、イは11）
   本文には、SQLインジェクション脆弱性への対処として図1の一部を「適切なコードに置き換える」必要があるとあります。文字列連結をやめ、プリペアドステートメントで値をバインドする方式に改めるには、次の3行を書き換える必要があります。
   • 9行目：SQL文を、値を入れる位置をプレースホルダ（?）にした形に変える
   • 10行目：Statementの代わりにPreparedStatementを生成する
   • 11行目：SQL文を渡して実行するstmt.executeQuery(sql)を、PreparedStatementの実行に変える
   8行目のtry {と、その直後のconnを初期化する処理は、置き換え後も必要です。また、12行目以降は結果のrsを使うだけなので、置き換え後もrsという変数に結果が入っていれば変更は要りません。したがって、置き換える範囲は9行目から11行目までで、アは9、イは11です。
3. 置き換えに必要なコードを選ぶ
   解答群のうち、プリペアドステートメントを使うのに必要なのは次の四つです。
   • カ：プレースホルダ（?）を使ったSQL文を定義する
   • ア：conn.prepareStatement(sql)で、PreparedStatementを生成する
   • イ：pstmt.setString(1, cname)で、1番目のプレースホルダにcnameの値をバインドする
   • ウ：pstmt.executeQuery()で実行し、結果をrsに受け取る
   オは文字列連結のSQL文のままなので、脆弱性が残ります。エのexecuteQuery(sql)はSQL文の文字列を実行時に改めて渡す書き方で、PreparedStatementでは使いません（JDBCでは、PreparedStatementに対してこの形で呼び出すと例外になります）。
4. 並べる順序を決める（カ、ア、イ、ウ）
   順序は、各行が前の行で作ったものを使う関係から決まります。アのprepareStatement(sql)はsqlを使うので、sqlを定義するカが先です。イのsetStringはアで生成したpstmtを使うので、アの後です。値をバインドしてから実行するので、ウが最後です。以上から順序はカ、ア、イ、ウとなり、置き換え後の9行目から11行目は次のようになります。

   String sql = "SELECT * FROM companylist WHERE cname = ?";
   PreparedStatement pstmt = conn.prepareStatement(sql);
   pstmt.setString(1, cname);
   ResultSet rs = pstmt.executeQuery();
   

誤りやすいポイント

• 置き換える範囲を9行目だけ、または9行目と10行目だけにしてしまう。11行目もstmtを使ってSQL文を実行しているので、PreparedStatementに合わせて書き換える必要があります。
• 8行目のtry {やconnの初期化まで範囲に含めてしまう。これらは置き換え後も必要な処理です。
• 解答群のエを選んでしまう。PreparedStatementでは、executeQueryにSQL文を渡さず、引数なしで呼び出します。
• イのsetStringをアより前に置いてしまう。pstmtはアで生成されるので、生成前には値をバインドできません。

FAQ

解答の導き方

1. XSS脆弱性が生じる箇所の条件を確認する
   XSSは、利用者やデータベースなど外部から来た値を、エスケープせずにそのままHTMLとして出力したときに生じます。本文でN氏は、XSS脆弱性を招く可能性の否定できない箇所について「HTML形式での出力時に処理するよう改修することとする」と指摘しています。そこで、図1のうちHTMLを出力している行の中から、外部から来た値をそのまま出力している行を探します。
2. HTMLを出力している行を分類する
   図1でHTMLを出力しているのは、out.printlnを呼び出している13〜19行目、21〜24行目、26〜28行目です。このうち13〜19行目、24行目、26〜28行目は、プログラムに直接書かれた決まった文字列だけを出力しているので、XSSの原因にはなりません。20行目のwhileと25行目の}は、何も出力しません。
3. データベースの値をそのまま出力している行を特定する
   残る21〜23行目は、検索結果のrsから取り出した値を、文字列連結でそのままHTMLに埋め込んでいます。

   21:          out.println("<tr><td>" + rs.getString(1));
   22:          out.println("</td><td>" + rs.getString(2));
   23:          out.println("</td><td>" + rs.getString(3));
   

   データベースの値に、スクリプトを含む文字列が入っていないとは言い切れません。さらに、9行目にはSQLインジェクション脆弱性があるので、攻撃者はUNIONを使うなどして検索条件を細工し、任意の文字列を検索結果として返させることもできます。そうした文字列が21〜23行目でエスケープされずに出力されると、ブラウザ上でスクリプトとして実行されてしまいます。
4. 以上から、XSS脆弱性を招く可能性を否定できず、出力時に処理するよう改修すべきなのは21行目、22行目、23行目です。

誤りやすいポイント

• 19行目の見出し行や20行目のwhileを含めてしまう。見出し行は決まった文字列だけを出力しており、whileは何も出力しないので、改修の対象ではありません。
• 利用者の入力を受け取る5行目を答えてしまう。N氏の指摘は出力時に処理するというものです。また、図1では、利用者が入力したcnameはHTMLに出力されていません。
• 9行目を答えてしまう。9行目はSQLインジェクション脆弱性の原因で、設問1(1)で扱う箇所です。
• アクセスや売上げは数値だろうと考えて、21行目だけにしてしまう。図1からは各列に入っている値の種類が分からず、getStringで文字列として出力しているので、22行目と23行目も可能性を否定できません。

FAQ

解答の論理構成

1. 【問題文】には
   　・「XSS脆弱性への対処としては、…HTML形式での出力時に処理するよう改修することとする。」
   　と記載されています。
2. XSSはブラウザにスクリプトを注入させる攻撃なので、サーバ側で生成するHTMLに危険文字がそのまま混入しないよう「出力時」にエスケープ処理を行うことが王道対策です。
3. 解答群を確認すると、文字実体参照（<、>、&、"、' など）に置き換える対策を示しているのは
   　「ウ：出力時に<、>、&、”、'の各文字をエスケープする。」
   　だけです。
4. 以上より、N氏の指摘と合致するのは「ウ」であると論理的に導けます。

誤りやすいポイント

• 「オ：バインド機能を使う。」はSQLインジェクション対策の手法であり、XSSとは目的が異なります。
• 「ア：CSRF対策トークンを使う。」は利用者の意図しないリクエスト送信を防ぐ技術で、スクリプト埋め込みは防げません。
• HTML出力時のエスケープは、必ず“サーバ側で生成するすべての箇所”に適用する必要があります。テーブルの <td> だけでなく、<title> やJavaScript文字列リテラルなども見落としがちです。
• same-origin policy（解答群エ）やRefererチェック（解答群イ）は補助的な安全策に過ぎず、根本的にタグ混入を防ぐ仕組みではありません。

FAQ

解答の論理構成

1. 問題文の確認
   • 「指摘2：WシステムからのCookie発行の際、TLS通信時だけCookieをブラウザから送信するa属性を設定する必要がある。」
   • 「指摘3：JavaScriptからCookieを操作できないようにするb属性を設定する方がよい。」
2. TLS通信時だけ送信させる属性
   • Cookieに付与することで “HTTPSでの通信時のみブラウザが送信する” 挙動を実現するのはSecure属性です。
   • 解答群で該当するのは「エ：Secure」であり、これが a に入ります。
3. JavaScriptからのアクセスを禁止する属性
   • CookieがXSSなどで読み取られるのを防ぎ、クライアント側スクリプトから参照できなくするのはHttpOnly属性です。
   • 解答群で該当するのは「イ：HttpOnly」であり、これが b に入ります。
4. 以上より
   • a ＝ 「エ」
   • b ＝ 「イ」

誤りやすいポイント

• 「TLS通信時だけ」のキーワードでSecureを想起しにくく、似た表記の「オ：Secured」を選択してしまう。
• HttpOnlyは “HTTPだけで有効になる” と誤解し、サーバ接続プロトコル限定の属性だと思い込む。
• ExpiresやMax-AgeはCookieの有効期限を制御する属性であり、通信経路やJavaScriptからの参照可否とは無関係である点を取り違える。

FAQ

解答の論理構成

• 【問題文】には「指摘1：Wシステムの認証後のリダイレクタ機能は、オープンリダイレクタの問題を招く。修正する必要がある。」とあり、任意サイトへ転送されるリスクが指摘されています。
• 同じく【問題文】には「K氏は、指摘1に対しては、②ホワイトリスト方式によるリダイレクタ機能を採用することにした。」とあり、転送先を事前に許可したものに限定する方針が明示されています。
• オープンリダイレクトは、攻撃者が自ドメイン外のURLを設定できることが原因です。したがってホワイトリストには自システムが正規に用いるURLだけを登録するのが筋となります。
• Wシステムの正規URLは【問題文】に「WシステムのURLであるhttps://w-system.a-sha.jp/」とはっきり書かれており、このFQDN以外を転送先として許可する必要はありません。
• 以上より、「認証後のリダイレクト先のURLを、WシステムのFQDNのものに限定する」という仕様が、ホワイトリスト方式の具体策として適切であると結論付けられます。

誤りやすいポイント

• 複数サブパスを列挙するブラックリスト方式と混同し、危険URLを除外する方向で考えてしまう。
• httpとhttpsの区別を忘れ、同じFQDNでも暗号化されていない転送を許可してしまう。
• CDNsや外部APIなど別ドメイン利用時の転送と混同して、余計なFQDNまでホワイトリストに入れてしまう。

FAQ

解答の論理構成

• 【問題文】では、修正版は開発用PCにはあったものの「K氏からファイルを受け取ったF氏が、本番システムに修正版をデプロイし忘れたので、本番システムに脆弱性が残存したままとなっていた」と記載されています。
• つまり従来の検査対象は開発環境に限定されており、本番環境へ反映漏れがあっても気付けませんでした。
• その結果、N氏が「脆弱性検査手順を改善すべきである」と提案しています。
• 改善すべき点は、リリース後の“実際に顧客が利用する環境”を直接確認し、デプロイ漏れや設定ミスを即時検知できるようにすることです。
• よって、検査手順の改善は「セキュリティ検査を本番システムに対し行うこと」となります。

誤りやすいポイント

• 開発環境での検査強化と誤解し、検査ツールの追加導入や手動項目の充実と答えてしまう。
• 「ステージング環境での検査」と答え、実際の本番環境検査を外してしまう。
• 変更管理プロセス改善（別提案）と混同し、レビュー体制や承認フローの記述に寄せてしまう。

FAQ

解答の論理構成

1. 【問題文】では、K氏が「ブラウザを用いた手動のセキュリティ検査」を実施したとあります。
2. その検査で見落とした理由について、N氏は「④一部のブラウザではXSS攻撃の試みを完遂できないことがある」と指摘しています。
3. 近年、多くの主要ブラウザにはXSS FilterやXSS Auditorなどと呼ばれる機能が実装されており、疑わしいスクリプトを自動的に除去・無効化します。
4. この機能が働くと、攻撃用に入力した <script> タグなどが実際には実行されず、表面上は“問題が起きない”ように見えてしまいます。
5. したがって、「一部のブラウザではXSS攻撃自体をブラウザ側が遮断するため、攻撃を再現できず検証に失敗する」という説明が成り立ちます。

誤りやすいポイント

• 「検査用文字列が不適切だった」と勘違いし、ブラウザ固有機能の存在を見逃す。
• ブラウザの開発者ツールでエラーが見えない＝安全、と早合点する。
• WAFやサーバ側フィルタと混同し、クライアント側の防御機構を忘れる。

FAQ

解答の導き方

誤りやすいポイント

• WAF導入で脆弱性が完全になくなると誤解する：WAFは緩和策であり、根本対策はコード修正と適用です。
• 「リスク」を抽象的に書きすぎる：設問は「Webアプリケーションサーバへのリスクの低減」と明示しているため、侵害（サーバのコンプロマイズ）を具体的に記述する必要があります。
• シグネチャ更新の即時性を過信する：共有シグネチャで迅速対応できるが、未知の手法（回避）には無力な場合がある点を見落としやすいです。

FAQ