「安全なウェブサイトの作り方」 1.4セッション管理のまとめと補足。
セッションIDにまつわるセキュリティ問題の概観や復習にどうぞ。

前提

セッションとは

ステートレスなHTTP通信を基礎とするウェブアプリケーションにおいて、ユーザーとアプリケーションとのやり取りを補完するための仕組み。

ユーザーがログインを行うと、サーバーはセッションIDを発行し、ユーザーとセッションIDを紐付けて記憶する。
また、ログインに対するレスポンスとしてセッションIDを返し、通常はユーザーのブラウザのCookieに保管される。

次にそのユーザーがサーバーに対して別のリクエストを行った際、セッションIDが一緒にサーバーに送信される。
そうすることで、サーバーはセッションIDからどのユーザーなのかを識別することができる。

つまり、セッションIDを用いることで毎度ログインせずにサーバーとのやり取りを行うことができるようになる。

サーバーは「セッションIDがabcdeの人は、ユーザーID12345の人だ」という紐付けをしているので、
セッションIDが第三者に盗まれるとなりすましができることになる。

セッションIDが盗まれることをセッションハイジャックと呼ぶ。
これを防ぎましょうというのが本題。

防ぐためには相手の手口を知ることから。

セッションIDが連番や一定の規則をもとに作成されるようになっている場合は容易に推測が可能。

例えば、自分で2つアカウントを作成し、1つ目のセッションIDが12345、２つ目が12346であれば、12344の人も12347の人もいるはずだ、という推測が立つ。

暗号化されていない通信（HTTPS化されていないサイトや、暗号化されていない公衆無線LANでの通信）が傍受されたり、
またXSSなどによってセッションIDが盗まれる危険性がある。

安全なウェブサイトの作り方では「セッションIDの固定化」というタイトルで紹介されているが、個人的には「ウェブアプリケーション側がセッションIDを固定化していることを逆手に取った手口」という言い方の方が理解しやすいと思っているので上記のように言い換えている。

具体的な手口としては下記のようになる。

3のログインした時点で新しいセッションIDを発行していればこの攻撃は成立しないが、固定してしまっているために発生する。

URLにセッションIDを埋め込んだリンクを踏ませる
- セッションIDがURLのパラメータとして管理されている場合、http://example.com/login?sessionid=ABCといったリンクを踏ませることで可能。
XSS
- セッションIDがCookieで管理されている場合、<script>document.cookie="sessionid=ABC"; </script>といったスクリプトを埋め込んでそれを第三者のブラウザで実行させることで可能。
HTTPヘッダインジェクション
- 同じくセッションIDがCookieで管理されている場合、Set-Cookieヘッダを挿入することで利用者にCookieを強制することが可能。

※ セッション固定化攻撃については下記のサイトを参考にさせていただいてます。

規則的に生成するのではなく、ランダムに生成されるよう予測できないようにしましょう。
また、フレームワークやライブラリがセッション管理の機能を提供しているのであればそれに則るようにしましょう。

ブラウザのReferer送信機能によってセッションIDがついたURLが送信されてしまうことがある。

セッションIDはCookieかhiddenパラメータに保存しよう。
(hiddenパラメータは書き換え可能なので個人的にはCookieがベターと思う)

なお、phpのsession.use_trans_sid = 1のようにCookieが無効化されている場合自動的にURLパラメータにセッションIDを含める機能もあるが非推奨である。

secure属性を加えるとHTTPS通信でしかCookieを利用できなくなる。
HTTP通信だと盗聴の可能性があるので、必ずsecure属性を加えましょう。

また、Ruby on Railsのconfig.force_ssl = trueなどのようにSSL通信を強制させ、暗号化されていない無線LANでのアクセスなどを禁止し盗聴対策することができるでのこちらもやっておきましょう。

固定化攻撃を防ぐため、ユーザーごとに固定のセッションIDを持つのはやめ、
ログインの度にセッションIDを新規発行し、既存のセッションIDは無効になるようにしましょう。

有効期限が長いほど盗まれる可能性は上がります。適切な期間を設定しましょう。

ユーザーからの入力値をサニタイジングするなど、基本的なXSS対策を行いましょう。