Cookieおよびセッション管理と関連する攻撃

1.セッション管理の方法
- (1)セッション管理とは
- (2)セッションIDの管理方法
2.Cookie（クッキー）
3.セッションハイジャック
4.セッションフィクセーション
- (1)攻撃の概要
- (2)対策

1.セッション管理の方法

(1)セッション管理とは

セッションってそもそも何でしたっけ？　
TCPのコネクションとの違いも教えて下さい

TCPのコネクションは3wayハンドシェークが行われる一連の通信。一方のセッションという言葉は、あいまいな言葉である。かなり乱暴ではあるが、買い物サイトにログインした情報と考えてほしい。
一つのセッションに複数のTCPコネクションが作成されることになるだろう。
また、TCPコネクションはTCPとあるとおり、レイヤ4での処理です。
一方、セッションは、上位層（5層～7層）の処理です。（※5層がセッション層なので、5層という考え方もあるでしょう。）

なぜセッション管理が必要なんですか？

Webサイトでショッピングをする際に、ログインすることが多い。ログインした情報を持っておけば、買い物がスムーズに行える。たとえば、購入履歴のページでは、ログインIDをもとに表示できる。発送の段階ではログインIDをもとに住所を表示できる。
このように、Webページをまたがって一連の処理をするときに、セッション管理が求められる。
参考であるが、IPAの文献には以下の記載がある。

IPAの文献
電子商取引サイトのようにWebサーバーにユーザがログインしてからログアウトするまで、ログイン情報を保持したままページを移管するには、このままでは問題がある。そこで、クライアントとサーバー間でその情報を保持し、アクセス制御を一つの集合体として管理する仕組みが必要となる。この仕組みをセッション管理と呼んでいる。（旧リンク）http://www.ipa.go.jp/security/awareness/administrator/secure-web/chap6/6_session-1.html

IPAの文献

電子商取引サイトのようにWebサーバーにユーザがログインしてからログアウトするまで、ログイン情報を保持したままページを移管するには、このままでは問題がある。そこで、クライアントとサーバー間でその情報を保持し、アクセス制御を一つの集合体として管理する仕組みが必要となる。この仕組みをセッション管理と呼んでいる。
（旧リンク）http://www.ipa.go.jp/security/awareness/administrator/secure-web/chap6/6_session-1.html

(2)セッションIDの管理方法

大きく以下の3つがある。

❶クッキー（Cookie）
たとえば、Gmailにログインすると、クライアントのブラウザに、以下のようなCookieが作成される。

NAME GX  
VALUE xxxx（長いので省略）   
DOMAIN mail.google.com   
PATH /mail   
EXPIRES 2013/07/01 6:05:36

❷URLリライティング
クエリストリングで、SID(セッションID）をURLに埋め込むのだ。
URLに sid=xxx などと直接書くのだ。
http://～xxx.com/aa.aspx?sid=xxx
当然ながら、セッションIDが見えているわけだから、セッションハイジャックなどの攻撃にあいやすくなる。
情報セキュリティスペシャリスト試験を目指す女性SE

でも、他の管理方法だって、HTTPSで暗号化されていないのであれば、キャプチャすれば見えてしまうと思います。セキュリティレベルは同じでは？

URLに含まれているかどうかは、一つのポイントだと思う。
IPAのセキュアプログラミグ講座にも「URLリライティングの方式では、URLの一部にセッションIDが含まれているため、キャッシュ、ログ、Referer:ヘッダ等を通じて第三者にその値が漏えいするおそれがある」とあります。（旧リンク）https://www.ipa.go.jp/security/awareness/vendor/programmingv2/web.html

❸hiddenフィールド
　hidden（隠された）という言葉の通り、HTMLのソースの中に、表からは見えないように埋め込む。
formタグの場合、以下のように埋め込んで、次のページに渡すことができる。
<input type="hidden" name="sid" value="123">
とはいえ、ソースを開けば見えてしまうし、改ざんも可能。セキュリティ面で優れるとはいいにくい。
それに、プログラミングにて、常にhiddenのフィールドを書く必要があり、かなり手間だ。

今のところ、①のCookieによるsession管理が主流だ。
以下は、上記の3つを図にしてみた。
素材３_3_セッションの管理方法

IPAの「『セキュア・プログラミング講座（Webアプリケーション編）』ブートアップセミナー」（https://www.ipa.go.jp/archive/security/vuln/programming/t6hhco00000023q7-att/000030878.pdf）では、セッションIDを運ぶ手段が、以下の図のように1枚で整理されています。3つの内容は同じです。
Cookie

分類の仕方は考え方によるところがあるので、これは一例と思ってください。
上記のIPAの文献では、考え方は同じだが、2つに分類している。

IPAの文献
2) セッション管理セッション管理を実現するには、一般には以下のような方法が利用される。ア) Cookieを利用 Webサーバー側で発行されたセッションIDをクライアントのCookieに持たせることで、特定ユーザの識別を行う。イ) hiddenフィールドを利用入力フォームをWebサーバーに送信する際に利用するFORMタグのhiddenフィールドにセッションIDを持たせることで、セッション管理を実施する。Cookieを使用できない場合に、利用されることが多い。

IPAの文献

2) セッション管理
セッション管理を実現するには、一般には以下のような方法が利用される。
ア) Cookieを利用
Webサーバー側で発行されたセッションIDをクライアントのCookieに持たせることで、特定ユーザの識別を行う。
イ) hiddenフィールドを利用
入力フォームをWebサーバーに送信する際に利用するFORMタグのhiddenフィールドにセッションIDを持たせることで、セッション管理を実施する。Cookieを使用できない場合に、利用されることが多い。

③のhiddenフィールドも、GETメソッドを使えば②のようにURLに記載される。

2.Cookie（クッキー）

(1)Cookieによるセッション管理

Webサイトでは、クライアントとサーバー間で情報を保持するセッション管理を行っています。Webサイトから買い物をするときに、商品を選ぶページから決済をするページに画面が切り替わります。セッション管理を行っていれば、ページが変わっても、クライアントの情報を保持できるのです。
セッション管理には、Cookieを用いられることが一般的です。
cookieは、WebサーバがSet-Cookieという指示を出して、ブラウザにユーザ情報などを保存します。
以下を見てください。

セッション管理（Set-Cookie使用）
Set-Cookie：domain=example.com; session_id=uid20101017143045;secure;path=/874045/

Set-Cookieという指示で、session_idという情報をクライアントPCのブラウザに保持するように指示しています。クライアントはサーバに対してこのsession_idを提示することで、セッションを維持することができます。
cookie

もう少し詳しく解説します。
cookieは、Netscape社が開発しました。
過去問ではcookieに関して、「Webサーバに対するアクセスがどのPCからのものであるかを識別するために,Webサーバの指示によってブラウザにユーザ情報などを保存する仕組み（H19FE午前問36）」と述べられている。
Cookieには有効期限があり、有効期限がくるとブラウザから削除される。有効期限がないものは、無期限に使えるのではなく逆にブラウザを閉じると削除される。
Cookieに書き込む方法は、WebページにHTMLにて、Metaタグに記載する方法と、JavaScriptにてdocument.cookie=
で書く方法がある。
H22SC秋午後Ⅰ問3設問3(2)には、Set-Cookieヘッダの例が搭載されている

Set-Cookie：session_id=uid20101017143045;secure;path=/874045/

このsecureの意味は何か。
クッキーに関しては、たまに出題されます。
内容はそれほど難しくないため、理解しておくとよいでしょう。secureは、SSLの暗号化通信の場合にのみ、クッキー（Cookie）が送信されます。暗号化されていない場合は、盗み見られる可能性があるから、送信されない。

(2)Cookieの内容

それぞれの意味は以下である。　

項目	説明
NAME	Cookieの名前
expires	Cookieの有効期限。値を指定しない場合は、ブラウザを閉じた時点で有効期限が切れる。
domain	Cookieを送るドメイン名。クライアント端末が次回Webサーバに接続した際に、ここで指定したドメインと一致した場合にCookieを送る。（例）seeeko.com
path	ドメイン名に加えて、URLのパスを指定したい場合に指定する。（例）/cgi
secure	暗号化された通信（HTTPS）の場合にのみCookieを送る。domain、pathが一致しても、HTTP通信の場合はCookieは送らない。
HttpOnly	JavaScript からCookieを操作できないようにする設定です。Cookieを取得するJavaScriptを埋め込まれたXSSなどへの対処です。
SameSite属性	異なるドメインのページに遷移する際に、Cookieを送信するかの設定です。設定は、None、Lax（緩い）、Strict（厳格）の3つです。

LaxやStrictの場合、異なるドメインのページに遷移したときは、Cookieを送信しません。CSRFを防ぐなどを目的に利用されます。
参考ですが、Laxは少し複雑で、以下のページが詳しいです。
https://qiita.com/muk-ai/items/10aab285784e780ef631
たとえば、メソッドがPOSTの場合はそもそもCookieが付与されません。あまり深入りしなくてもいいでしょう。最近のブラウザは、デフォルトでLaxが指定されます。

情報処理安全確保支援士試験の過去問（H27SC秋午前2）をもう一問見てみましょう。

過去問（H27SC秋午前2）
問13 WebサーバがHTTPS通信の応答でCookieにSecure属性を設定したときのブラウザの処理はどれか。ア　ブラウザは，Cookieの“Secure＝"に続いて指定された時間を参照し，指定された時間を過ぎている場合にそのCookieを削除する。イ　ブラウザは,Cookieの“Secure="に続いて指定されたホスト名を参照し，指定されたホストにそのCookieを送信する。ウ　ブラウザは,Cookieの“Secure"を参照し,HTTPS 通信時だけそのCookieを送信する。エ　ブラウザは,Cookieの“Secure"を参照し，ブラウザの終了時にそのCookieを削除する。

過去問（H27SC秋午前2）

問13 WebサーバがHTTPS通信の応答でCookieにSecure属性を設定したときのブラウザの処理はどれか。
ア　ブラウザは，Cookieの“Secure＝"に続いて指定された時間を参照し，指定された時間を過ぎている場合にそのCookieを削除する。
イ　ブラウザは,Cookieの“Secure="に続いて指定されたホスト名を参照し，指定されたホストにそのCookieを送信する。
ウ　ブラウザは,Cookieの“Secure"を参照し,HTTPS 通信時だけそのCookieを送信する。
エ　ブラウザは,Cookieの“Secure"を参照し，ブラウザの終了時にそのCookieを削除する。

↓
↓
↓
↓
↓
正解はウです。

過去問（R1秋NW午前Ⅱ）
問17　CookieにSecure属性を設定しなかったときと比較した，設定したときの動作として，適切なものはどれか。ア　Cookieに設定された有効期間を過ぎると，Cookieが無効化される。イ　JavaScriptによるCookieの読出しが禁止される。ウ　URL内のスキームがhttpsのときだけ，WebブラウザからCookieが送出される。エ　WebブラウザがアクセスするURL内のパスとCookieに設定されたパスのプレフィッツクスが一致するときだけ, WebブラウザからCookieが送出される。

過去問（R1秋NW午前Ⅱ）

問17　CookieにSecure属性を設定しなかったときと比較した，設定したときの動作として，適切なものはどれか。
ア　Cookieに設定された有効期間を過ぎると，Cookieが無効化される。
イ　JavaScriptによるCookieの読出しが禁止される。
ウ　URL内のスキームがhttpsのときだけ，WebブラウザからCookieが送出される。
エ　WebブラウザがアクセスするURL内のパスとCookieに設定されたパスのプレフィッツクスが一致するときだけ, WebブラウザからCookieが送出される。

↓
↓
↓
↓
↓
正解は、ウ

(3)Cookieに関する理解の確認

復習を兼ねて、以下の質問にも答えてください。

Q1.Cookieを設定するのは誰か

↓
↓
↓
↓
↓
A1.Webサーバ

Q2.PCがCookieを発行できないのか

↓
↓
↓
↓
↓
A2.発行してもあまり意味がない。詳しくは次の質問

Q3.（上記の問いに関連して、）そもそも、Cookieを発行する理由は？

↓
↓
↓
↓
↓
A3.サーバがクライアントを識別するため。サーバには（ときに何万という）大量のクライアントが接続してくる。
そのクライアントを識別するために、Cookieを発行する。クライアントからすると、接続するサーバ
は1つなので、Cookieにより識別する必要はない。

Q4.CookieにSecure属性を付与するのは誰？

↓
↓
↓
↓
↓
A4.（もちろん）Webサーバ

Q5.上記の目的は、暗号化された通信（HTTPS）の場合にのみCookieを送るというものである。
どういうことを懸念しているのか。WebサーバがHTTPSのサイトを提供していれば、なんら問題はないのではないか。

↓
↓
↓
↓
↓
A5.たとえば、正規のサイト（www.example.com)であっても、機密情報を扱わないページはhttpのサイトがあったりする。そのときに、httpで通信をすると、Cookieが漏洩してしまう。
→サーバ側でHTTPSしか受け付けないようにするなどすれば、この機能は不要な気もする。だが、仕組みを突いた攻撃も可能のようで、この機能が有効なのではないか。（要調査）

(4)Cookieの配置場所と実際のCookie

Cookieは、有効期限が無い場合、ファイルには保存されません。通信の中だけでやりとりされます。有効期限がある場合、Cookieは、Windows8.1の場合、隠しフォルダとして、以下にあります。

C:\Users\ユーザ名\AppData\Local\Microsoft\Windows\INetCache
ブラウザの「インターネットオプション」「全般」タブ「設定」「ファイルの表示」からも開くことができます。

また、最近のIEでは「ツール」「インターネットオプション」「全般」「設定」「ファイルの表示」の中にある。他のテンポラリーファイルも混ざっているので見づらいが、よく探せばあるので、見ていただきたい。
cookie

実際のCookieのファイルは以下のようなものですが、利用者にはよくわからない情報です。

Website_cookie_data  
203.0.113.124.2301262640211636  
nw.seeeko.com/  
1024  
62517216  
・・・・

(5)Cookieによるセッション管理を試してみる。

セッション管理には3つがあると述べたが、一番多いのはCookieである。
実際に試してみよう。
session

PHPでプログラミングをする場合、以下を書くだけである。
　session_start();

プログラムとしては、以下のようになる。
■login.php　※ポイントのみの最低限に絞っている

<?php  
 session_start();  
?>  
ログイン画面<br>  
<FORM ACTION="result.php" METHOD="POST">
ID：<INPUT TYPE="text" NAME="id" VALUE=""><br>  
Password：<INPUT TYPE="password" NAME="password" VALUE=""><br>  
<INPUT TYPE="submit" VALUE="Login">  
</FORM>

sef4
これだけでCookieが設定されるとは便利ですね。
では、IEの「ツール」「インターネットオプション」「全般」「設定」「ファイルの表示」の中で、Cookieを探してみます。
あれ？無いですよ？

ファイルに保存されるのは、Cookieに有効期限を付けた場合のみだ。通常は、ブラウザを閉じるとCookieは削除されるので、わざわざファイルに保存する必要はない。
IEの開発ツールで見てみよう。F12を押して、三角のスタートボタンを押してキャプチャをする。Cookieタブを見ると、以下にようにPHPSESSIDとして確認できる。
cookie

※http:127.0.0.1になっているのは、Webサーバ上から直接アクセスしたため。
Google Chomeでも同様で、F12を押して「Application」タブから左の列の「Cookies」を確認する。UFJ銀行で見てみると、非常にたくさんのCookieが見える。恐らく、一番下に見えるJSESSIONIDが、セッション管理の軸となるCookieだと思う。

では、パケットキャプチャを詳しく見てみよう。
PC（192.168.1.103）からWebサーバ192.168.1.102にアクセスするとする。
http://192.168.1.102/login.php
WebサーバにはPHPのプログラムにて　session_start()　が記載されているので、ブラウザに対してSet-Cookieにてセッション情報を渡す。（上の図の②）
このとき、②のフレームが以下である。

Webサーバからブラウザに対し、Set-CookieにてセッションIDが渡されているのが分かる。
その後、ブラウザからWebサーバへの通信（上の図の③）へは、以下のようにCookieのセッションIDを伝えながら通信をする。これにより、セッションを維持しながらの通信が可能になる。
session2
情報セキュリティスペシャリスト試験を目指す女性SE

【ポイント！】
WebサーバはHTTPヘッダのSet-Cookie（HTTPレスポンス）、クライアントはCookie（HTTPリクエスト）にCookie情報を入れて通信

今回はPHPの場合を紹介したが、Java Servletの場合は以下。
　　HttpSession session = request.getSession(true);

以下にまとめられているので参照ください。
（旧リンク）https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/303.html

◆参考
情報処理安全確保支援士試験の過去問（H23SC春午後2問2）に、「利用者がパスワードを入力してログインすると, Set-CookieヘッダでセッションIDをブラウザに対して発行するようになっている。それ以降はセッション管理にこのセッションIDを利用するとともに, SSLによる通信の暗号化が図られている」とある。

3.セッションハイジャック

(1)概要

情報処理安全確保支援士試験の過去問（H23SC春午後2問2）を見てみよう。

過去問（H23SC春午後2問2）
Web検査の結果, Webアプリの脆弱性として,不適切なセッション管理が行われていることが判明した。Webアプリには, SSLで保護されたWebフォーム認証があり,利用者がパスワードを入力してログインすると, Set-CookieヘッダでセッションIDをブラウザに対して発行するようになっている。それ以降はセッション管理にこのセッションIDを利用するとともに, SSLによる通信の暗号化が図られている。しかし,公開Webサーバ内にはSSLを利用していないページも存在し, HTTP通信を盗聴することによってクッキーの情報を取得できることが判明した。この脆弱性を放置すると,[　g　]という攻撃手法によってなりすましによる不正アクセスが発生する可能性がある。

過去問（H23SC春午後2問2）

Web検査の結果, Webアプリの脆弱性として,不適切なセッション管理が行われていることが判明した。Webアプリには, SSLで保護されたWebフォーム認証があり,利用者がパスワードを入力してログインすると, Set-CookieヘッダでセッションIDをブラウザに対して発行するようになっている。それ以降はセッション管理にこのセッションIDを利用するとともに, SSLによる通信の暗号化が図られている。しかし,公開Webサーバ内にはSSLを利用していないページも存在し, HTTP通信を盗聴することによってクッキーの情報を取得できることが判明した。この脆弱性を放置すると,[　g　]という攻撃手法によってなりすましによる不正アクセスが発生する可能性がある。

↓
↓
↓
↓
↓
このgにあてはまるのがセッションハイジャックだ。
セッション情報さえわかれば、この人のセッションを持って買い物などができる。
情報セキュリティスペシャリスト試験_女性SE成子

でもログインIDやパスワードの情報が必要でしょ。

いや。ログインは不要だ。
ログインした後は、セッションIDでしか通信が管理されていない。
以下の図を見てください。セッションIDを盗聴することで、パスワード等を知らなくてもＡ氏として買い物ができてしまう。
セッションハイジャック_情報セキュリティスペシャリスト試験

①正規の利用者Aは、自分のIDパスワードを入力してログインします。
②Webサーバ（買い物サイト）から、セッションID（SID）として123が付与されます。
③それ以降の通信は、IDやパスワードが使われることなく、SIDを提示することでセッションが維持されます。
④第三者がSIDを盗聴します。
⑤盗聴したSIDである123を使えば、正規ユーザA氏に成り代わって通信をすることができます。

(2)セッションを盗む方法

大きく3つあります。
❶セッションIDを推測
たとえば、日付＋乱数の桁などの単純はセッションIDである場合、適当に付与すれば、誰かのセッションIDに該当する可能性があります。
❷セッションIDを盗む
XSSなどを使って盗みます。
❸セッションフィクセーション
→このあと記載します。

(3)対策

ではどう対処すべきか。対策は以下です。
①SSLで通信を暗号化する　
　SIDも暗号化される
②非SSLのSIDとは別のSIDを使う　
　SIDが暗号化されていても、それまでの非SSLのSIDと同じものを使っていたら、ばれてしまう。なので、SSL通信をする際には、SIDを新しく振りなおす必要があります。

以下は、H24NW午後1問3の問題である。
ログイン認証要求ではSID=xxxなのに、その応答のログイン完了表示では、SID=yyyと変わっている。
こうすることで、ログイン後のSIDが第三者に分からないようにしている。なおかつSSLで暗号化している。セッションハイジャックを防ぐために当然の処置である。
セッションハイジャック_SSLの図

参考ですが、IPAの「『セキュア・プログラミング講座（Webアプリケーション編）』ブートアップセミナー」（http://www.ipa.go.jp/files/000030878.pdfhttps://www.ipa.go.jp/archive/security/vuln/programming/t6hhco00000023q7-att/000030878.pdf）では、セッションハイジャック対策として、以下が述べられています。

セッションハイジャック対策  

　・「推測」への対抗  
　　・予測困難なランダム値を使う  
　　・ログイン（ユーザ認証）成功のたびに異なる値を使う  
　・「奪取」への対抗  
　　・TLS を使用する  
　　・Cookieにsecure属性をつける  
　　・Cookieの「寿命」を短めにする  
　　・ログイン成功時にセッションIDを発行し直す

情報セキュリティスペシャリスト試験を目指す女性SE

そもそもですが、セッション情報を盗聴することはできるんでしたっけ？
セッション情報の盗聴は難しいかもしれませんが、盗聴以外の方法を使えばいいでしょう。たとえば、XSSの脆弱性で、セッション情報を取得してしまえばいいのです（具体的なやり方までは確認していませんが、たぶん簡単にできるはず）

4.セッションフィクセーション

(1)攻撃の概要

セッションフィクセーションとは，「セッションIDの固定化」とも呼ばれる攻撃手法である。
情報セキュリティスペシャリスト試験を目指す女性SE

フィクセーション（fixation）のfixは「固定する」という意味ですよね
だから、ログイン前後（http→https）にて、同じセッションID使っている（＝セッションIDが固定化している）ときに受ける攻撃ですよね。

間違ってもいいないが、正確でもない。たしかに、セッションIDが同じだと、この攻撃を受けやすい。
ただ、セッションフィクセーションの攻撃は、攻撃者が事前にセッションIDを取得し，利用者に使用させることで，攻撃者が利用者のログイン権限になりすます攻撃を指す。過去問（H29春SC午前Ⅱ問5）では、「セッションIDの固定化（Session Fixation）攻撃の手口」に関して、「悪意のある者が正規のWebサイトから取得したセッションIDを、利用者のWebブラウザに送り込み、利用者がそのセッションIDでログインして、セッションがログイン状態に変わった後、利用者になりすます」とあります。

情報処理安全確保支援士試験の過去問（H27年SC春午後1問1）には以下の記述がある。

過去問（H27年SC春午後1問1）
T君：はい。図6の一連のHTTPヘッダのうち，例えば，行番号[　d　]と行番号[　e　]を見比べると，サーバ側のセッション管理に問題があり，セッションフィクセーションの脆弱性が存在する可能性があります。攻撃者がCookie Monster Bugを突く攻撃や，前述したHTTPヘッダインジェクション攻撃を組み合わせることによって，セッションフィクセーションを成功させる可能性があります。図9に攻撃手順の一例を示します。 -------　攻撃手順の一例　ここから　------- 1．攻撃者Jが，試験用サイトの画面Aにアクセスし，セッションIDを取得する。このときの，セッションIDを“01234”とする。 2．攻撃者Jが，攻撃対象の利用者KにHTMLメールを送信する。このHTMLメールにはURLリンクがあり，攻撃用のクエリ文字列を含む画面CのURLが記載されている。 3．利用者Kが，試験用サイトの画面Aにアクセスし，セッションIDを取得する。このときの，セッションIDを“56789”とする。その後，HTMLメールのURLリンクをクリックする。その際に送信されるHTTPリクエストには，攻撃者Jが用意した攻撃用クエリ文字列が含まれており，検索文字列の値は次のとおりである。 %0d%0aSet%2dCookie%3a%20SESSIONID%3d[　f　]%3b%20Expires%3d（省略） domain%3dexample%2eco%2ejp%3b（省略） 4．利用者Kがログインする。 5．攻撃者Jは，利用者Kになりすまし，本来はアクセス権限がない画面にアクセスできるようになる。 -------　攻撃手順の一例　ここまで　------- 　　　　　図9　攻撃手順の一例

過去問（H27年SC春午後1問1）

T君：はい。図6の一連のHTTPヘッダのうち，例えば，行番号[　d　]と行番号[　e　]を見比べると，サーバ側のセッション管理に問題があり，セッションフィクセーションの脆弱性が存在する可能性があります。攻撃者がCookie Monster Bugを突く攻撃や，前述したHTTPヘッダインジェクション攻撃を組み合わせることによって，セッションフィクセーションを成功させる可能性があります。図9に攻撃手順の一例を示します。
-------　攻撃手順の一例　ここから　-------
1．攻撃者Jが，試験用サイトの画面Aにアクセスし，セッションIDを取得する。このときの，セッションIDを“01234”とする。
2．攻撃者Jが，攻撃対象の利用者KにHTMLメールを送信する。このHTMLメールにはURLリンクがあり，攻撃用のクエリ文字列を含む画面CのURLが記載されている。
3．利用者Kが，試験用サイトの画面Aにアクセスし，セッションIDを取得する。このときの，セッションIDを“56789”とする。その後，HTMLメールのURLリンクをクリックする。その際に送信されるHTTPリクエストには，攻撃者Jが用意した攻撃用クエリ文字列が含まれており，検索文字列の値は次のとおりである。
%0d%0aSet%2dCookie%3a%20SESSIONID%3d[　f　]%3b%20Expires%3d（省略）
domain%3dexample%2eco%2ejp%3b（省略）
4．利用者Kがログインする。
5．攻撃者Jは，利用者Kになりすまし，本来はアクセス権限がない画面にアクセスできるようになる。
-------　攻撃手順の一例　ここまで　-------
　　　　　図9　攻撃手順の一例

↓
↓
↓
↓
↓
dとeは、ログイン前とログイン後で，SESSIONIDの値が変わっていない点が設問にて問われている。
また、fには「01234」が入る。
簡略化して図にすると、こんな感じである。
セッションフィクセーション_情報セキュリティスペシャリスト試験
▼セッションフィクセーションの攻撃概要　

(2)対策

問題
この問題には、セッションフィクセーションの脆弱性対策として、「ログイン後の，画面Eから画面Cに遷移する際の，サーバ側の処理において[　g　]といった対策を行うことによって，この脆弱性を確実に防ぐ」とある。

この空欄gが、セッションフィクセーションの攻撃を防ぐシンプルな対策である。
まず、なぜセッションフィクセーションの脆弱性につながったかのか。それは、ログイン前とログイン後で同じセッションIDを利用しているからである。仮に攻撃者がセッションIDを送り込んだとしても、画面Eから画面Cに遷移する際に、サーバが新しいセッションIDを割り当てればよい。そうすれば、攻撃者がセッションIDを知ることができないし、不正なアクセスをすることもできない。
↓
↓
↓
↓
↓
解答：新しいセッションIDによるセッションを開始する
情報セキュリティスペシャリスト試験を目指す女性SE

【ポイント】
セッションハイジャックは、セッションIDを盗む。
セッションフィクセーションは、自分が用意したセッションIDを使わせる。

情報処理安全確保支援士 - SE娘の剣 -

左門至峰による情報処理安全確保支援士試験に合格するためのサイトです。過去問を引用しながら、試験に出る基礎知識を体系的かつ詳細に整理します。