（学習たれ流し）セッション管理の不備
概要
WEBアプリの利用者を識別するための情報として「セッションID」を発行して管理することがある。
このセッション管理の不備を悪用し、ログイン中の利用者のセッション IDを不正に取得し利用者になりすましてアクセスする攻撃手法を「セッション・ハイジャック」という。
セッションIDの不正取得方法・悪用方法例
セッションIDの推測：攻撃者自身がログインし、発行されたセッションIDを確認し生成規則を予測することで、他ユーザのセッションIDを推測する方法。
セッションIDの盗用：ネットワークを盗聴（※1）したり罠（※2）を仕掛けることでセッションIDを盗む方法。
セッションIDの固定化（Session Fixation）：攻撃者の用意したセッションIDを利用者に強制利用（強制利用の方法の詳細に突いては後述）させる方法。ログイン前後でセッションIDが変更されないサイトがこの方法での攻撃の前提である。
※1：クライアントとサーバ間で通信が暗号化されていない時、パケットキャプチャやパケットアナライザといった機器やソフトウェアを使用することで通信を盗聴することが可能。（そういえば昔何かの研修で盗聴の体験したことがある…！！！）
※2 ：クロスサイトスクリプティングの脆弱性があるサイトで他ユーザのセッションIDを抜き取り、リダイレクトや<iframe>タグを扱い攻撃者のサーバにアクセスさせることで、アクセスログなどからセッションIDを入手することが可能。
取得したセッションIDを強制利用方法
セッションIDの不正取得方法・悪用方法例3. の強制利用させる方法として以下がある。
URLにセッションIDを埋め込む方法
以下のように強制利用させたいセッションIDを埋め込んだURLをSNSやメールなどで利用者に送信し、クリックさせる方法。ドメイン自体は正規サイトのものになるため気付きにくい。
http://example.com/login?sessionid=ABCまた、正規サイトでURL Rewriting機能（Cookieが使用できない場合にURLのパラメータとしてGETメソッドでセッションIDを引き渡す機能。）が有効になっている場合、セッションIDをCookieで管理していてもURLクエリパラメータを利用して受理させることが可能となってしまう。
スクリプトを使用し、セッションIDを強制する方法(クロスサイトスクリプティング脆弱性)
以下のようなスクリプトが利用者のブラウザ上で実行された後で、利用者が正規サイトにログインすると攻撃者に不正アクセスされる。
<script>document.cookie="sessionid=ABC"; </script>このスクリプトにより、攻撃者が指定したセッションIDが利用者のブラウザに設定されてしまうが、正規サイトの方は既にセッションIDを持っているものと認識してしまう。
レスポンスヘッダを追加してCookieを強制する方法
HTTPヘッダインジェクション脆弱性があるサイトで、攻撃者がSet-Cockieを挿入することで利用者にCookieを強制させ、任意のセッションIDを強制させる方法。
発生しうる脅威
攻撃者が利用者になりすまし、利用者に許可されている操作を不正に行なってしまう。具体的には以下。
ログイン後の利用者のみが利用可能なサービスの悪用：不正送金、商品購入、退会処理など
ログイン後の利用者のみが編集可能な情報の改ざん：パスワード変更、掲示板の不適切な書き込みなど
ログイン後の利用者のみが閲覧可能な情報の閲覧：個人情報の閲覧、コミュニティ会員限定の掲示板の閲覧など
特に注意が必要なウェブサイトの特徴
金銭処理が発生するサイト：ネットバンキング、ショッピング
非公開情報を扱うサイト：転職サイト、コミュニティサイト
ログイン機能を持つサイト：会員専用サイト、日記サイト
根本的解決
セッションIDを推測困難なものにする
セッションID生成に、暗号論的擬似乱数生成器（Cryptographically Secure Pseudo Random Number Generator：CSPRNG）を使用するなど、攻撃者が予測困難な者で生成する。
セッション管理の仕組みが提供されているウェブサーバ製品であれば、それを使うなどなるべく自前で仕組みを構築せず製品を利用する方が良い。
セッションIDをURLパラメータに格納しない
セッションIDはCookieに格納するか、POSTメソッドのhiddenパラメータに格納して受け渡すようにする。
※Referer送信機能（直前でアクセスしていたページのURLを教えてくれる機能）によって、リンク先のサイトへ送信される。その際、RefererのURLが攻撃者に入手されるとセッション・ハイジャックされてしまうため。
HTTPS通信で利用するCookieにはsecure属性を加える
HTTPS通信でCookieにsecure属性が設定されていれば、経路が暗号化されるため盗聴されない。そのためHTTPS通信で利用するCookieには必ずsecure属性を加えること。逆に、HTTP通信は盗聴されてしまう危険性があるため、HTTP通信でCookieを利用する場合はHTTPSと別物を発行すること。
ログイン成功後に新しくセッションを開始する
ログイン成功前にセッションIDを発行するのではなく、ログイン成功時点で新たなセッションを開始（別セッションIDを発行）する。また、新たなセッションを開始したタイミングで既存のセッションIDを無効化する。これによりセッション固定化の脆弱性を防げる。
ログイン成功後に既存セッションIDとは別に秘密情報を発行し、ページ遷移ごとに検証する
セッションIDだけでなく別の秘密情報とセットでチェックする方法。ただし、ログイン成功後に新しくセッションを開始する方法を採用している場合は不要である。
保険的対策
セッションIDを固定値にしない
固定値にせず、利用者のログインごとに新しく発行する。
セッションIDをCookieに設定する場合、有効期限の設定に注意する
有効期限が切れるまでCookieの内容を盗むことが可能になるため、有効期限が必要以上に長い期間で設定されていないかを確認＆最低限の期間に設定することを検討する。
なお、有効期限の設定を省略すればブラウザ終了時点でデータ破棄されるが、利用者がブラウザを終了させずに使い続けた場合には Cookie は破棄されないため有効ではない可能性がある。