情報処理安全確保支援士 2015年 春期 午後1 問01
Webサイトの脆弱性と対策に関する次の記述を読んで、設問1～3に答えよ。
S社は、情報システムの構築、運用、コンサルティングなどのサービスを顧客に提供する従業員数5,000名の企業である。S社にはセキュリティプロフェッショナルグループ（以下、SPGという）という組織があり、Webアプリケーションソフトウェア（以下、Webアプリという）の脆弱性を検査するサービス（以下、脆弱性検査という）を提供している。
SPGでは、脆弱性検査に従事できる者を認定するために、技能試験を実施している。技能試験は、Webアプリに脆弱性が作り込まれた、技能試験用のWebサイト（以下、試験用サイトという）を用いて実施される。試験用サイトは、個人間で取引するオークションシステムを想定しており、“http://...”及び“https://...”の画面がある。図1に試験用サイトの画面構成と画面の遷移を、図2に画面Cの概要をそれぞれ示す。また、試験用サイトの機能のうち、セッション管理機能の仕組みを図3に、検索文字列の引継機能の仕組みを図4に示す。
〔技能試験〕
SPGに新たに配属された従業員は研修検査員と呼ばれ、2か月間の研修を終えると、技能試験を受ける。技能試験に合格した者だけが脆弱性検査を実施できる規則になっている。技能試験では、脆弱性検査専用のWebブラウザを使用する。検査専用のWebブラウザには、一般的なWebブラウザの機能に加えて、送信するHTTPリクエストやパラメタの値を意図的に変更する機能がある。
技能試験では、試験官とのディスカッション、検査手順や報告書の作成を通して、力量が判断され、合否が決定される。このたび、研修検査員のT君が、技能試験を受けることになった。試験官はU主任である。最初に、U主任は、技能試験の前提として図1及び図2の内容をT君に伝えた。
なお、図3及び図4の内容はT君には伏せられている。
〔検査シナリオとHTTPヘッダ〕
技能試験の開始に当たって、U主任は、図5に示す検査シナリオの順番で画面にアクセスするようT君に指示した。T君が検査シナリオを実行した際のHTTPリクエストヘッダ及びHTTPレスポンスヘッダを、図6に示す。
〔脆弱性に関するディスカッション〕
次は、図6に関するU主任とT君のディスカッションである。
U主任：図6中のレスポンスXについて、セキュリティ上、気になる点があれば指摘してください。
T君 ：Set-Cookieヘッダに、①secure属性が設定されていません。secure属性を設定しないと、セッションIDを第三者に盗聴されるリスクがあり、セッションハイジャックなどにつながると思います。
U主任：他に、図6全体を通して、気になる点はありますか。
T君 ：HTTPヘッダインジェクションの脆弱性が存在する可能性があります。図7の検査コードをリクエストのクエリ文字列のパラメタの値にセットし、スクリプトの実行ができるかどうか、確認してみます。
T君が、図7の検査コードを用いて確認したところ、予想どおり、警告ダイアログが表示された。T君は、HTTPヘッダインジェクションの脆弱性が存在することを指摘した。
T君 ：サーバ側でのHTTPレスポンスヘッダの出力処理に問題があり、HTTPヘッダインジェクションの脆弱性が存在すると思います。具体的には、入力された検索文字列を適切に処理せずにSet-Cookieヘッダの値にセットしているものと思われます。この脆弱性を突いた攻撃では、b 攻撃と同様に、攻撃者が指定した任意のスクリプトをクライアント側で実行できます。
U主任：仮に問題があるとした場合、Set-Cookieヘッダの値をセットするサーバ側の処理において、どのような対策が考えられますか。
T君 ：幾つかの対策があります。例えば、HTTPレスポンスヘッダを適切に出力するために、Webアプリの実行環境やプログラム言語が用意している、ヘッダ出力用の関数やAPIを使用する方法が考えられます。それが使用できない場合は、c するといった処理を開発者が自身で実装する方法も考えられます。
U主任：その他に気になる点はありますか。
T君 ：はい。図6の一連のHTTPヘッダのうち、例えば、行番号 d と行番号 e を見比べると、サーバ側のセッション管理に問題があり、セッションフィクセーションの脆弱性が存在する可能性があります。攻撃者がCookie Monster Bugを突く攻撃や、前述したHTTPヘッダインジェクション攻撃を組み合わせることによって、セッションフィクセーションを成功させる可能性があります。図9に攻撃手順の一例を示します。
U主任：セッションフィクセーションの脆弱性について、どのような対策が考えられますか。
T君 ：例えば、サーバ側の処理を変更する方法があります。検査シナリオの画面遷移でいえば、ログイン後の、画面Eから画面Cに遷移する際の、サーバ側の処理において、gといった対策を行うことによって、この脆弱性を確実に防ぐことができます。
U主任は、その後もT君に対してディスカッションや報告書の審査などを行い、技能試験は終了した。
T君は見事、技能試験に合格し、SPGの検査員として業務を始めた。
（1）secure属性が設定されていないと、どの画面に遷移するときにセッションIDを盗聴されるリスクがあるか。遷移直後の画面を、画面A〜Eの中から一つ選び、答えよ。
模範解答
画面B
解説
解答の論理構成
- 図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
Q: secure属性を付けてもネットワーク盗聴は完全に防げますか？
A: はい、secure属性付きCookieはTLS通信でのみ送信されるため、HTTP経由の盗聴は防げます。ただしTLSそのものが無効化されていないかなど、他の設定も確認が必要です。
A: はい、secure属性付きCookieはTLS通信でのみ送信されるため、HTTP経由の盗聴は防げます。ただしTLSそのものが無効化されていないかなど、他の設定も確認が必要です。
Q: HttpOnly属性も付ければさらに安全になりますか？
A: はい。HttpOnlyはブラウザのスクリプトからCookieへのアクセスを禁止するため、XSSなどによる窃取を防ぎます。用途が異なるため、secureと併用するのが一般的です。
A: はい。HttpOnlyはブラウザのスクリプトからCookieへのアクセスを禁止するため、XSSなどによる窃取を防ぎます。用途が異なるため、secureと併用するのが一般的です。
Q: 画面BをHTTPS化する以外に対策はありますか？
A: 画面Bへの遷移時にセッションIDを破棄・再発行する方法もありますが、実装コストが高く、全画面をHTTPS化するほうが根本的で確実です。
A: 画面Bへの遷移時にセッションIDを破棄・再発行する方法もありますが、実装コストが高く、全画面をHTTPS化するほうが根本的で確実です。
関連キーワード: secure属性, セッションID, セッションハイジャック, Cookie, HTTPヘッダ
（2）secure属性が設定されていないと、セッションIDを盗聴されるリスクがある理由を40字以内で述べよ。
模範解答
暗号化されないHTTP通信において、セッションIDが送信されるから
解説
解答の論理構成
- 図6レスポンスXの行番号「09 Set-Cookie: SESSIONID=…」には“secure”が付いていません。
- 問題文には「“http://...”及び“https://...”の画面がある」とあり、実際に図1で“画面B URL： http://www.example.co.jp/manual”が示されています。
- Secure属性が無いCookieはHTTP/HTTPSを区別せず送信されます。
- 従って利用者がHTTP画面（例：画面B）にアクセスすると、同じ「SESSIONID」が暗号化されないHTTP通信で送信されるため、パケット盗聴で取得される恐れがあります。
- よって「暗号化されないHTTP通信において、セッションIDが送信されるから」と説明できます。
誤りやすいポイント
- Secure属性は暗号化の可否を決めるだけで“HttpOnly”とは役割が異なる点を混同しやすい。
- 「HTTPSだけを使うサイトならSecureが不要」と思い込み、問題文にあるHTTP画面の存在を見落とす。
- Cookieの送信方向（リクエスト時）と受信方向（レスポンス時）を取り違え、Set-Cookie側にSecureが付かなくても大丈夫と誤解する。
FAQ
Q: Secure属性を付けても盗聴が完全に防げますか？
A: 利用者とサーバ間が常にHTTPSである限りCookieは暗号化されますが、SSL/TLSの設定ミスや中間者攻撃対策が不十分だと別の経路で漏えいする危険は残ります。
A: 利用者とサーバ間が常にHTTPSである限りCookieは暗号化されますが、SSL/TLSの設定ミスや中間者攻撃対策が不十分だと別の経路で漏えいする危険は残ります。
Q: HttpOnly属性も併用するべきでしょうか？
A: はい。HttpOnlyを付加するとJavaScriptからCookieが参照できなくなるため、XSS経由での窃取リスクを下げられます。
A: はい。HttpOnlyを付加するとJavaScriptからCookieが参照できなくなるため、XSS経由での窃取リスクを下げられます。
Q: Secure属性が無いと必ず盗聴されるのですか？
A: 盗聴可能なのはHTTP通信を経由した場合だけです。全画面がHTTPSでリダイレクト強制されていれば実質的なリスクは低減します。
A: 盗聴可能なのはHTTP通信を経由した場合だけです。全画面がHTTPSでリダイレクト強制されていれば実質的なリスクは低減します。
関連キーワード: Secure属性, Cookie, セッションID, HTTP通信, HTTPS
設問2：HTTPヘッダインジェクションの脆弱性について、(1)〜(3)に答えよ。
問題文を見る（1）図7中のaに入れる適切な文字列をURLエンコード済の形式で答えよ。
模範解答
a：%0d%0a%0d%0a
解説
解答の論理構成
-
HTTPヘッダインジェクションでは、レスポンスヘッダ中に攻撃者が用意した改行（CR＋LF）を挿入し、
本来のヘッダを強制終了させて任意ヘッダや本文を生成させます。
問題文のディスカッションでも
“入力された検索文字列を適切に処理せずにSet-Cookieヘッダの値にセットしている”
と説明されており、改行文字の混入が前提になっています。 -
図7の検査コードは“クエリ文字列のパラメタの値にセット”して送信する想定ですが、
URLでは制御文字を直接書けないためURLエンコードが必須です。 -
レスポンスヘッダを打ち切るには2回連続の改行（空行）を入れ、
その後に攻撃用ヘッダやHTML本文を置くのが典型的な手口です。
したがって必要なバイト列は
CR(0d)＋LF(0a)＋CR(0d)＋LF(0a)。 -
以上を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
Q: なぜCRとLFを2回繰り返す必要があるのですか？
A: 1回目のCRLFは現在のヘッダ行を閉じ、2回目のCRLFで「空行」を作り、ヘッダ部全体の終了を示します。空行の後はHTTP本文として扱われるので、任意のスクリプトを挿入できます。
A: 1回目のCRLFは現在のヘッダ行を閉じ、2回目のCRLFで「空行」を作り、ヘッダ部全体の終了を示します。空行の後はHTTP本文として扱われるので、任意のスクリプトを挿入できます。
Q: “%0d%0a” をフィルタすれば防げますか？
A: 直接フィルタすることも可能ですが、入力値をそのままヘッダに入れない、ヘッダ専用APIを使うなどのホワイトリスト方式が推奨されます。
A: 直接フィルタすることも可能ですが、入力値をそのままヘッダに入れない、ヘッダ専用APIを使うなどのホワイトリスト方式が推奨されます。
Q: 文字コード0dと0aは環境依存しませんか？
A: どのOS・ブラウザでもASCII制御文字として固定値です。HTTP仕様自体がCR(0d)＋LF(0a) を改行として規定しているため、環境差は生じません。
A: どのOS・ブラウザでもASCII制御文字として固定値です。HTTP仕様自体がCR(0d)＋LF(0a) を改行として規定しているため、環境差は生じません。
関連キーワード: HTTPヘッダインジェクション、CRLF、URLエンコード、Set-Cookie、セッションID
設問2：HTTPヘッダインジェクションの脆弱性について、(1)〜(3)に答えよ。
問題文を見る（2）本文中のbに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア：SQLインジェクション
イ：TCP SYN Flood
ウ：クロスサイトスクリプティング
エ：ディレクトリトラバーサル
模範解答
b：ウ
解説
解答の論理構成
- 問題文には次の記述があります。
“この脆弱性を突いた攻撃では、b 攻撃と同様に、攻撃者が指定した任意のスクリプトをクライアント側で実行できます。” - 「攻撃者が指定した任意のスクリプトをクライアント側で実行」できる代表的な攻撃は、クライアント（Webブラウザ）でJavaScriptなどを実行させる「クロスサイトスクリプティング」です。
- 解答群を見ると、スクリプト実行型の攻撃に該当するのは “ウ：クロスサイトスクリプティング” だけです。
- したがって、b に入る適切な字句は “ウ” となります。
誤りやすいポイント
- SQLインジェクションを選ぶミス
→ 任意のSQLを“サーバ側”で実行させる攻撃であり、「クライアント側でスクリプトを実行」とは性質が異なります。 - ディレクトリトラバーサルを選ぶミス
→ ファイルパスを改ざんして不正なファイルを取得する攻撃で、スクリプト実行とは無関係です。 - HTTPヘッダインジェクション≒クロスサイトスクリプティングと混同
→ 本問は「同様に」と比較対象を求めているため、直接の脆弱性名ではなく“代表的な既知攻撃”を答える必要があります。
FAQ
Q: HTTPヘッダインジェクションとクロスサイトスクリプティングは何が違いますか？
A: 前者は改行文字などを注入してレスポンスヘッダを分断・生成させる手法、後者は生成されたページ上で任意のスクリプトを実行させる手法です。本問は「結果としてスクリプトが実行される」点で両者が類似すると説明しています。
A: 前者は改行文字などを注入してレスポンスヘッダを分断・生成させる手法、後者は生成されたページ上で任意のスクリプトを実行させる手法です。本問は「結果としてスクリプトが実行される」点で両者が類似すると説明しています。
Q: なぜTCP SYN Floodは除外できますか？
A: TCP SYN Floodは通信セッションを大量に張ってサービス不能にするDoS攻撃であり、スクリプト実行とは無関係だからです。
A: TCP SYN Floodは通信セッションを大量に張ってサービス不能にするDoS攻撃であり、スクリプト実行とは無関係だからです。
Q: 今回のように「ヘッダにスクリプトを乗せて実行させる」場合でもXSSと呼ぶのですか？
A: はい。最終的にブラウザが攻撃者制御のスクリプトを実行するなら、発生経路にかかわらずXSSの範疇で議論されます。
A: はい。最終的にブラウザが攻撃者制御のスクリプトを実行するなら、発生経路にかかわらずXSSの範疇で議論されます。
関連キーワード: クロスサイトスクリプティング、HTTPヘッダインジェクション、セッションハイジャック、Cookie属性、セッションフィクセーション
設問2：HTTPヘッダインジェクションの脆弱性について、(1)〜(3)に答えよ。
問題文を見る（3）本文中のcに入れる適切な処理を、30字以内で具体的に述べよ。
模範解答
c：・出力文字列に改行コードがあるとエラー画面を出力
・出力文字列の改行コード以降の文字列を削除
解説
解答の論理構成
- 図７の検査コードは“%0d%0a”を含み、これは図８のASCII表で「文字コード0d＝CR」「文字コード0a＝LF」に対応します。
- CR＋LFはHTTPヘッダ行の終端を表すため、値に混入するとヘッダを強制終了し、続く文字列を新たなヘッダ行として解釈させることができます。T君の指摘どおり「HTTPヘッダインジェクションの脆弱性」が成立する理由はここにあります。
- U主任は「Set-Cookieヘッダの値をセットするサーバ側の処理」に対する対策案を求めています。安全なヘッダ生成APIを使えない前提であるため、アプリケーション側で値を検査・無害化する実装が必要です。
- 攻撃に必須の文字はCR／LFなので、
・ヘッダ出力前にCRまたはLFが含まれていればエラーとして処理を中断する
・もしくはCR／LF以降を切り捨ててヘッダに出さない
という方針が最も直接的な防御策になります。 - 以上より、c には「出力文字列に改行コードがあるとエラー画面を出力」「出力文字列の改行コード以降の文字列を削除」という具体策が妥当であり、模範解答と一致します。
誤りやすいポイント
- 入力値のHTMLエスケープだけで十分と考えてしまう。HTTPヘッダにセットされる値はHTMLではなく、CR／LFの除去が本質です。
- URLエンコードすれば安全だと誤解する。攻撃者は“%0d%0a”のようにエンコード済みで送信し、サーバがデコードしてからヘッダに入れるケースを突きます。
- 対策を「単に文字列を置換する」とだけ書き、どの文字を対象にするか示さない。CRとLFを明示しなければ部分点止まりになる可能性があります。
FAQ
Q: CR／LFを拒否せずにエンコードして出力する方法でも良いですか？
A: ヘッダ値はRFCで改行が禁止されているため、エンコード後の再デコード経路を完全に排除できない限り推奨されません。除去またはエラーにする方が確実です。
A: ヘッダ値はRFCで改行が禁止されているため、エンコード後の再デコード経路を完全に排除できない限り推奨されません。除去またはエラーにする方が確実です。
Q: “\r\n”以外の制御文字もチェックすべきでしょうか？
A: まず最優先はCR／LFですが、将来の拡張やパーサ実装差異を考慮し、他の制御文字も拒否するほうが望ましいです。
A: まず最優先はCR／LFですが、将来の拡張やパーサ実装差異を考慮し、他の制御文字も拒否するほうが望ましいです。
Q: 既存フレームワークのヘッダ生成APIを使えば改行除去は不要ですか？
A: 多くのAPIは内部で検査を行いますが、使用していない部分や独自追加ヘッダでは自前チェックが必要になる場合があります。
A: 多くのAPIは内部で検査を行いますが、使用していない部分や独自追加ヘッダでは自前チェックが必要になる場合があります。
関連キーワード: HTTPヘッダインジェクション、CRLFインジェクション、Set-Cookie、セッションID、入力値検証
設問3：セッション管理の脆弱性について、(1)〜(4)に答えよ。
問題文を見る（1）本文中のd、eに入れる適切な行番号を答えよ。（dとeは順不同）
模範解答
d：09又は17
e：27
解説
解答の論理構成
- セッションフィクセーションでは「ログイン前に発行されたセッションIDがログイン後もそのまま利用される」ことが問題になります。
- 図6のヘッダを確認すると、最初のアクセス（画面A）のレスポンスで行番号 09 に
「Set-Cookie: SESSIONID=134D96E470da240421svr5B019; Expires=Wed, 11-Jun-2014 05:30:31 GMT; domain=example.co.jp;」
が送出され、ブラウザはこのIDを保持します。 - その後、画面Bへの遷移時のリクエストで行番号 17 に
「Cookie: SESSIONID=134D96E470da240421svr5B019」
が送信され、同一IDがサーバへ戻されています。 - ログインを経た後、商品取引用のリクエスト（画面D遷移時）では行番号 27 に
「Cookie: SESSIONID=134D96E470da240421svr5B019」
が依然として送信されています。 - 以上より、ログイン後もセッションIDが更新されていないことが確認できます。従って、比較対象には「発行時のSet-Cookie（09もしくは発行直後に送信された17）」と「ログイン後のCookie（27）」を選べばよいことになります。
結論：
d：09又は17
e：27
d：09又は17
e：27
誤りやすいポイント
- 「KENSaku」Cookie（行28）と混同してしまい、セッションIDとは無関係な行を選んでしまう。
- レスポンスヘッダ（09）とリクエストヘッダ（17）のどちらを選ぶべきか迷い、片方しか正解だと思い込む。問題文は「行番号 d と行番号 e を見比べる」としており、09･17いずれでも可。
- セッションIDはログイン処理の直前に再発行されるものと決め付け、「Set-Cookie」がないレスポンスZ側を探してしまう。
FAQ
Q: 09と17の両方を解答したら減点になりますか？
A: 指示は「(d, eは順不同)」なので、dに09、eに27でもdに17、eに27でも正解です。両方書くと指定外回答となる恐れがあります。
A: 指示は「(d, eは順不同)」なので、dに09、eに27でもdに17、eに27でも正解です。両方書くと指定外回答となる恐れがあります。
Q: なぜ27が必須なのですか？
A: 27は「ログイン後」のリクエストに含まれるCookie行です。セッションフィクセーションの確認にはログイン後に同じIDが使われていることを示す必要があります。
A: 27は「ログイン後」のリクエストに含まれるCookie行です。セッションフィクセーションの確認にはログイン後に同じIDが使われていることを示す必要があります。
Q: secure属性の欠如とセッションフィクセーションは別問題ですか？
A: はい。secure属性は通信経路の盗聴対策、セッションフィクセーションはID再発行の有無による固定化対策であり、脅威モデルが異なります。
A: はい。secure属性は通信経路の盗聴対策、セッションフィクセーションはID再発行の有無による固定化対策であり、脅威モデルが異なります。
関連キーワード: セッションフィクセーション、Set-Cookie、Cookie、HTTPレスポンスヘッダ、セッションID
設問3：セッション管理の脆弱性について、(1)〜(4)に答えよ。
問題文を見る（2）図9中のfに入れる適切な字句を答えよ。
模範解答
f：01234
解説
解答の論理構成
-
図9の手順1には、
「攻撃者Jが、試験用サイトの画面Aにアクセスし、セッションIDを取得する。このときの、セッションIDを“01234”とする。」
と明記されています。ここで攻撃者は自分が知っている SESSIONID=“01234” を手に入れます。 -
セッションフィクセーション攻撃では、攻撃者が取得したセッションIDを利用者に押し付けることが成功条件です。したがって、利用者Kのブラウザに対してSet-Cookieヘッダで設定する値は、攻撃者があらかじめ把握している値と一致していなければなりません。
-
図9の手順3には、攻撃用クエリ文字列の一部として
「%0d%0aSet%2dCookie%3a%20SESSIONID%3df%3b …」
が示されています。ここで f に入る値こそ、手順1で攻撃者が取得した “01234” である必要があります。 -
以上より、f には攻撃者が保有するセッションID 01234 を入れるのが論理的帰結です。
解答：
f：01234
f：01234
誤りやすいポイント
- 被害者が取得した “56789” を入れてしまう。これは「攻撃者が知っているIDを被害者に固定する」という攻撃の本質を取り違えています。
- 数字の前後に空白や引用符を含めてしまう。Set-Cookieヘッダの値に余分な文字が入ると、クッキーが正しく解釈されず攻撃が失敗します。
- 大文字小文字を混同して “sessionid=01234” と記述する。HTTPヘッダではCookie名の大小は区別される実装もあるため、問題文どおり SESSIONID と一致させる必要があります。
FAQ
Q: なぜ利用者Kがすでに持っている “56789” を上書きできるのですか？
A: 攻撃用クエリ文字列によりレスポンスヘッダへ「Set-Cookie: SESSIONID=01234 …」が挿入され、ブラウザはサーバからの正式な指示と誤認してクッキーを更新するためです。
A: 攻撃用クエリ文字列によりレスポンスヘッダへ「Set-Cookie: SESSIONID=01234 …」が挿入され、ブラウザはサーバからの正式な指示と誤認してクッキーを更新するためです。
Q: secure属性やHttpOnly属性を付けていれば防げましたか？
A: 今回の脆弱性はHTTPヘッダインジェクションによる Set-Cookie 強制であり、secureやHttpOnlyの有無とは直接関係しません。根本対策はヘッダ分離処理とログイン時のセッションID再生成です。
A: 今回の脆弱性はHTTPヘッダインジェクションによる Set-Cookie 強制であり、secureやHttpOnlyの有無とは直接関係しません。根本対策はヘッダ分離処理とログイン時のセッションID再生成です。
Q: 攻撃者が推測で適当な数字を入れても成立しますか？
A: 推測だけではセッションIDの一致確率が極めて低く現実的ではありません。攻撃者は手順1で確実に自分が発行された “01234” を使い、被害者のセッションをそのIDに固定します。
A: 推測だけではセッションIDの一致確率が極めて低く現実的ではありません。攻撃者は手順1で確実に自分が発行された “01234” を使い、被害者のセッションをそのIDに固定します。
関連キーワード: セッションフィクセーション、HTTPヘッダインジェクション、Set-Cookie、セッションID再生成、クッキー上書き
設問3：セッション管理の脆弱性について、(1)〜(4)に答えよ。
問題文を見る（3）図9中の手順4及び5について、利用者Kがログインした後、攻撃者Jが利用者Kになりすますことができるのはなぜか。“セッションID”という字句を含めて40字以内で述べよ。
模範解答
攻撃者Jが取得したセッションIDで利用者Kにログインさせているから
解説
解答の論理構成
- 図9では先に「攻撃者Jが、試験用サイトの画面Aにアクセスし、セッションIDを取得」し（手順1）、その値を悪用します。
- 次いで「攻撃用のクエリ文字列」を利用者Kに踏ませることで、レスポンス中にSet-Cookie: SESSIONID=… を挿入し（手順3）、利用者Kのブラウザに攻撃者Jと同一のセッションIDを固定します。
- T君も指摘しているように「サーバ側のセッション管理に問題があり、セッションフィクセーションの脆弱性が存在する可能性があります」。
- その状態で「利用者Kがログイン」すると（手順4）、サーバは当該セッションIDに認証済みフラグを付与します。
- 攻撃者Jは、同じセッションIDを保持しているため「利用者Kになりすまし、本来はアクセス権限がない画面にアクセス」できます（手順5）。
- したがって解答は「攻撃者Jが取得したセッションIDで利用者Kにログインさせているから」となります。
誤りやすいポイント
- セッションIDを盗むのではなく「固定する」攻撃であることを見落とす。
- 被害者がログインする瞬間に権限が付与される点を説明から漏らす。
- セッションIDの再生成（ログイン後のID切替）を行えば防げる事実に気付かず、原因をCookieのSecure属性欠如と混同する。
FAQ
Q: 盗聴とセッションフィクセーションは同じですか？
A: 盗聴は通信経路でセッションIDを奪いますが、セッションフィクセーションは攻撃者が決めたセッションIDを利用者に使わせる点が異なります。
A: 盗聴は通信経路でセッションIDを奪いますが、セッションフィクセーションは攻撃者が決めたセッションIDを利用者に使わせる点が異なります。
Q: Secure属性を付与すれば今回の攻撃は防げますか？
A: 攻撃がHTTPS上で行われているならSecure属性だけでは防げません。ログイン時にセッションIDを再生成する対策が必要です。
A: 攻撃がHTTPS上で行われているならSecure属性だけでは防げません。ログイン時にセッションIDを再生成する対策が必要です。
Q: なりすましを検知する方法はありますか？
A: セッションIDに加えてIPアドレスやUser-Agentを照合し、異常があればセッションを破棄すると検知率が向上します。
A: セッションIDに加えてIPアドレスやUser-Agentを照合し、異常があればセッションを破棄すると検知率が向上します。
関連キーワード: セッションフィクセーション、Set-Cookie、HTTPヘッダインジェクション、なりすまし、認証
設問3：セッション管理の脆弱性について、(1)〜(4)に答えよ。
問題文を見る（4）本文中のgに入れる適切な対策を、30字以内で述べよ。
模範解答
g：新しいセッションIDによるセッションを開始する
解説
解答の論理構成
- 最初に脆弱性を確認
本文には「セッションフィクセーションの脆弱性が存在する可能性」とあり、攻撃例として図9が示されています。 - 脆弱性の要因を特定
・画面A表示時のレスポンスXでサーバは「09 Set-Cookie: SESSIONID=134D96E470da240421svr5B019…」を送信。
・ログイン後に画面Cへ戻った後のリクエストZでも「27 Cookie: SESSIONID=134D96E470da240421svr5B019」がそのまま送られており、認証前後でセッションIDが変わっていません。
・このままでは攻撃者が事前に決めたIDを被害者へ固定させることができます。 - 必要な対策を導出
攻撃を防ぐにはログイン完了時に旧セッションを破棄し、新しいセッションIDを払い出すのが最も確実です。これは、攻撃者が固定したIDを排除し、利用者本人だけが知る新しいIDで再度セッションを構築するためです。 - 本文のg部分に対策をあてはめる
本文には「画面Eから画面Cに遷移する際の、サーバ側の処理において、gといった対策を行うことによって、この脆弱性を確実に防ぐことができます。」とあります。
以上からgには「新しいセッションIDによるセッションを開始する」と記述するのが最適解となります。
誤りやすいポイント
- secure属性やhttponly属性の付与と混同し、Cookie盗聴対策を答えてしまう
- 「セッションIDを更新する」のみとし、旧セッションの破棄を明示しない
- 画面遷移前（ログイン画面表示時）にIDを再発行すると誤解する
- サーバではなくクライアント側のCookie削除だけで十分だと考える
FAQ
Q: ログイン後にIDを再発行しないと必ずセッションフィクセーションになりますか？
A: 攻撃者が事前にIDを固定できる経路がある場合は高い確率で成立します。再発行は安全側に倒すための標準対策です。
A: 攻撃者が事前にIDを固定できる経路がある場合は高い確率で成立します。再発行は安全側に倒すための標準対策です。
Q: 再発行時に古いセッション情報を引き継ぐ必要があります。どう実装しますか？
A: IDを再生成した直後にサーバ側で新セッションへ属性をコピーし、旧セッションを無効化します。開発フレームワークの「session regenerate」相当のAPIが推奨されます。
A: IDを再生成した直後にサーバ側で新セッションへ属性をコピーし、旧セッションを無効化します。開発フレームワークの「session regenerate」相当のAPIが推奨されます。
Q: セッションIDを暗号化すれば再発行しなくても安全ですか？
A: いいえ。暗号化は盗聴耐性を高めますが、固定されたID自体を無効化できません。再発行と組み合わせる必要があります。
A: いいえ。暗号化は盗聴耐性を高めますが、固定されたID自体を無効化できません。再発行と組み合わせる必要があります。
関連キーワード: セッションフィクセーション、セッションID再生成、Cookie、認証、脆弱性対策
