情報処理安全確保支援士 2015年 春期 午後1 問01

解答の論理構成

• 図6のレスポンスX 09行目に
  “Set-Cookie: SESSIONID=134D96E470da240421svr5B019; … domain=example.co.jp;”
  とあり、[ secure ] 属性が付与されていません。
• secure属性が無い Cookie は HTTP と HTTPS の両方で送信されます。
• 図1で唯一 “http://” となっている画面は
  “画面B：URL： http://www.example.co.jp/manual” です。
• 実際に図6のリクエストY 12〜17行目を見ると、HTTP リクエストであるにもかかわらず 17行目
  “Cookie: SESSIONID=134D96E470da240421svr5B019”
  によりセッションIDが平文で送られています。
• したがって、HTTPS の画面Aから HTTP の画面Bへ遷移した直後にセッションIDが平文送信され、盗聴されるリスクが生じます。
• よって、遷移直後の画面は 画面B です。

誤りやすいポイント

• HTTPS 画面間の遷移ばかりに注目し、HTTP 画面が 1 か所だけ混在していることを見落とす。
• Cookie がブラウザ内に保存された後、同一ドメインなら自動で送信される仕様を忘れ、フォーム送信時だけを気にする。
• secure 属性と HttpOnly 属性を混同し、「JavaScript からのアクセス防止＝盗聴防止」と誤解する。

FAQ

解答の論理構成

1. 図6レスポンスXの行番号「09 Set-Cookie: SESSIONID=…」には“secure”が付いていません。
2. 問題文には「“http://...”及び“https://...”の画面がある」とあり、実際に図1で“画面B URL： http://www.example.co.jp/manual”が示されています。
3. Secure属性が無いCookieは HTTP/HTTPS を区別せず送信されます。
4. 従って利用者が HTTP 画面（例：画面B）にアクセスすると、同じ「SESSIONID」が暗号化されない HTTP 通信で送信されるため、パケット盗聴で取得される恐れがあります。
5. よって「暗号化されないHTTP通信において、セッションIDが送信されるから」と説明できます。

誤りやすいポイント

• Secure属性は暗号化の可否を決めるだけで“HttpOnly”とは役割が異なる点を混同しやすい。
• 「HTTPSだけを使うサイトならSecureが不要」と思い込み、問題文にある HTTP 画面の存在を見落とす。
• Cookieの送信方向（リクエスト時）と受信方向（レスポンス時）を取り違え、Set-Cookie側にSecureが付かなくても大丈夫と誤解する。

FAQ

解答の論理構成

1. HTTPヘッダインジェクションでは、レスポンスヘッダ中に攻撃者が用意した改行（CR＋LF）を挿入し、
   本来のヘッダを強制終了させて任意ヘッダや本文を生成させます。
   問題文のディスカッションでも
   “入力された検索文字列を適切に処理せずに Set-Cookie ヘッダの値にセットしている”
   と説明されており、改行文字の混入が前提になっています。
2. 図7の検査コードは“クエリ文字列のパラメタの値にセット”して送信する想定ですが、
   URL では制御文字を直接書けないため URL エンコードが必須です。
3. 改行に相当する ASCII 制御文字は図8で
   “CR │ 0d” と “LF │ 0a”
   と明示されており、HTTP 1 行の終端は「CR(0d)＋LF(0a)」であることは RFC 規定のとおりです。
4. レスポンスヘッダを打ち切るには 2 回連続の改行（空行）を入れ、
   その後に攻撃用ヘッダや HTML 本文を置くのが典型的な手口です。
   したがって必要なバイト列は
   CR(0d)＋LF(0a)＋CR(0d)＋LF(0a)。
5. 以上を URL エンコードすると
   “%0d%0a%0d%0a”
   となり、模範解答 “a：%0d%0a%0d%0a” と一致します。

誤りやすいポイント

• 改行を LF のみ “%0a%0a” としてしまう
  （HTTP は CR＋LF で 1 行終了なので不完全）。
• １組の CRLF “%0d%0a” だけでヘッダが終わると誤解する
  （空行＝２組必要）。
• URL デコード後に空白などを入れたままにし、
  ヘッダ解釈がずれて検証が失敗する。
• “%0d%0a%20” のように余計な文字を含めて
  ブラウザが改行と認識せず、攻撃が成立しない。

FAQ

解答の論理構成

1. 問題文には次の記述があります。
   “この脆弱性を突いた攻撃では、b 攻撃と同様に、攻撃者が指定した任意のスクリプトをクライアント側で実行できます。”
2. 「攻撃者が指定した任意のスクリプトをクライアント側で実行」できる代表的な攻撃は、クライアント（Webブラウザ）で JavaScript などを実行させる「クロスサイトスクリプティング」です。
3. 解答群を見ると、スクリプト実行型の攻撃に該当するのは “ウ：クロスサイトスクリプティング” だけです。
4. したがって、b に入る適切な字句は “ウ” となります。

誤りやすいポイント

• SQLインジェクションを選ぶミス
  → 任意の SQL を“サーバ側”で実行させる攻撃であり、「クライアント側でスクリプトを実行」とは性質が異なります。
• ディレクトリトラバーサルを選ぶミス
  → ファイルパスを改ざんして不正なファイルを取得する攻撃で、スクリプト実行とは無関係です。
• HTTP ヘッダインジェクション≒クロスサイトスクリプティングと混同
  → 本問は「同様に」と比較対象を求めているため、直接の脆弱性名ではなく“代表的な既知攻撃”を答える必要があります。

FAQ

解答の論理構成

1. 図７の検査コードは“%0d%0a”を含み、これは図８の ASCII 表で「文字コード0d＝CR」「文字コード0a＝LF」に対応します。
2. CR＋LF は HTTP ヘッダ行の終端を表すため、値に混入するとヘッダを強制終了し、続く文字列を新たなヘッダ行として解釈させることができます。T 君の指摘どおり「HTTPヘッダインジェクションの脆弱性」が成立する理由はここにあります。
3. U 主任は「Set-Cookie ヘッダの値をセットするサーバ側の処理」に対する対策案を求めています。安全なヘッダ生成 API を使えない前提であるため、アプリケーション側で値を検査・無害化する実装が必要です。
4. 攻撃に必須の文字は CR／LF なので、
   ・ヘッダ出力前に CR または LF が含まれていればエラーとして処理を中断する
   ・もしくは CR／LF 以降を切り捨ててヘッダに出さない
   という方針が最も直接的な防御策になります。
5. 以上より、c には「出力文字列に改行コードがあるとエラー画面を出力」「出力文字列の改行コード以降の文字列を削除」という具体策が妥当であり、模範解答と一致します。

誤りやすいポイント

• 入力値の HTML エスケープだけで十分と考えてしまう。HTTP ヘッダにセットされる値は HTML ではなく、CR／LF の除去が本質です。
• URL エンコードすれば安全だと誤解する。攻撃者は“%0d%0a”のようにエンコード済みで送信し、サーバがデコードしてからヘッダに入れるケースを突きます。
• 対策を「単に文字列を置換する」とだけ書き、どの文字を対象にするか示さない。CR と LF を明示しなければ部分点止まりになる可能性があります。

FAQ

解答の論理構成

1. セッションフィクセーションでは「ログイン前に発行されたセッションIDがログイン後もそのまま利用される」ことが問題になります。
2. 図6のヘッダを確認すると、最初のアクセス（画面A）のレスポンスで行番号 09 に
   「Set-Cookie: SESSIONID=134D96E470da240421svr5B019; Expires=Wed, 11-Jun-2014 05:30:31 GMT; domain=example.co.jp;」
   が送出され、ブラウザはこのIDを保持します。
3. その後、画面Bへの遷移時のリクエストで行番号 17 に
   「Cookie: SESSIONID=134D96E470da240421svr5B019」
   が送信され、同一IDがサーバへ戻されています。
4. ログインを経た後、商品取引用のリクエスト（画面D遷移時）では行番号 27 に
   「Cookie: SESSIONID=134D96E470da240421svr5B019」
   が依然として送信されています。
5. 以上より、ログイン後もセッションIDが更新されていないことが確認できます。従って、比較対象には「発行時のSet-Cookie（09 もしくは発行直後に送信された 17）」と「ログイン後のCookie（27）」を選べばよいことになります。

誤りやすいポイント

• 「KENSaku」Cookie（行28）と混同してしまい、セッションIDとは無関係な行を選んでしまう。
• レスポンスヘッダ（09）とリクエストヘッダ（17）のどちらを選ぶべきか迷い、片方しか正解だと思い込む。問題文は「行番号 d と行番号 e を見比べる」としており、09･17 いずれでも可。
• セッションIDはログイン処理の直前に再発行されるものと決め付け、「Set-Cookie」がないレスポンスZ側を探してしまう。

FAQ

解答の論理構成

1. 図9の手順1には、
   「攻撃者Jが，試験用サイトの画面Aにアクセスし，セッションIDを取得する。このときの，セッションIDを“01234”とする。」
   と明記されています。ここで攻撃者は自分が知っている SESSIONID=“01234” を手に入れます。
2. セッションフィクセーション攻撃では、攻撃者が取得したセッションIDを利用者に押し付けることが成功条件です。したがって、利用者Kのブラウザに対して Set-Cookie ヘッダで設定する値は、攻撃者があらかじめ把握している値と一致していなければなりません。
3. 図9の手順3には、攻撃用クエリ文字列の一部として
   「%0d%0aSet%2dCookie%3a%20SESSIONID%3df%3b …」
   が示されています。ここで f に入る値こそ、手順1で攻撃者が取得した “01234” である必要があります。
4. 以上より、f には攻撃者が保有するセッションID 01234 を入れるのが論理的帰結です。

誤りやすいポイント

• 被害者が取得した “56789” を入れてしまう。これは「攻撃者が知っているIDを被害者に固定する」という攻撃の本質を取り違えています。
• 数字の前後に空白や引用符を含めてしまう。Set-Cookie ヘッダの値に余分な文字が入ると、クッキーが正しく解釈されず攻撃が失敗します。
• 大文字小文字を混同して “sessionid=01234” と記述する。HTTPヘッダでは Cookie 名の大小は区別される実装もあるため、問題文どおり SESSIONID と一致させる必要があります。

FAQ

解答の論理構成

1. 図9では先に「攻撃者Jが，試験用サイトの画面Aにアクセスし，セッションIDを取得」し（手順1），その値を悪用します。
2. 次いで「攻撃用のクエリ文字列」を利用者Kに踏ませることで，レスポンス中に Set-Cookie: SESSIONID=… を挿入し（手順3），利用者Kのブラウザに攻撃者Jと同一のセッションIDを固定します。
3. T君も指摘しているように「サーバ側のセッション管理に問題があり，セッションフィクセーションの脆弱性が存在する可能性があります」。
4. その状態で「利用者Kがログイン」すると（手順4），サーバは当該セッションIDに認証済みフラグを付与します。
5. 攻撃者Jは，同じセッションIDを保持しているため「利用者Kになりすまし，本来はアクセス権限がない画面にアクセス」できます（手順5）。
6. したがって解答は「攻撃者Jが取得したセッションIDで利用者Kにログインさせているから」となります。

誤りやすいポイント

• セッションIDを盗むのではなく「固定する」攻撃であることを見落とす。
• 被害者がログインする瞬間に権限が付与される点を説明から漏らす。
• セッションIDの再生成（ログイン後のID切替）を行えば防げる事実に気付かず，原因をCookieのSecure属性欠如と混同する。

FAQ

解答の論理構成

1. 最初に脆弱性を確認
   本文には「セッションフィクセーションの脆弱性が存在する可能性」とあり、攻撃例として図9が示されています。
2. 脆弱性の要因を特定
   ・画面A表示時のレスポンスXでサーバは「09 Set-Cookie: SESSIONID=134D96E470da240421svr5B019…」を送信。
   ・ログイン後に画面Cへ戻った後のリクエストZでも「27 Cookie: SESSIONID=134D96E470da240421svr5B019」がそのまま送られており、認証前後でセッションIDが変わっていません。
   ・このままでは攻撃者が事前に決めたIDを被害者へ固定させることができます。
3. 必要な対策を導出
   攻撃を防ぐにはログイン完了時に旧セッションを破棄し、新しいセッションIDを払い出すのが最も確実です。これは、攻撃者が固定したIDを排除し、利用者本人だけが知る新しいIDで再度セッションを構築するためです。
4. 本文の[ g ]部分に対策をあてはめる
   本文には「画面Eから画面Cに遷移する際の、サーバ側の処理において、[ g ]といった対策を行うことによって、この脆弱性を確実に防ぐことができます。」とあります。
   以上から[ g ]には「新しいセッションIDによるセッションを開始する」と記述するのが最適解となります。

誤りやすいポイント

• secure属性やhttponly属性の付与と混同し、Cookie盗聴対策を答えてしまう
• 「セッションIDを更新する」のみとし、旧セッションの破棄を明示しない
• 画面遷移前（ログイン画面表示時）にIDを再発行すると誤解する
• サーバではなくクライアント側のCookie削除だけで十分だと考える

FAQ