第4章 セッション対策
セッション乗っ取り：#1 セッションIDとセッションID侵害手口
セッションを維持する仕組み
WebブラウザとWebサーバの間の通信に用いられる HTTP（Hypertext Transfer Protocol）には、セッション、すなわち複数のWebページからなる操作の流れを維持するための仕組みが十分には備わっていない。
そこで、WebアプリケーションエンジンあるいはWebアプリケーションそのものがセッションを維持する仕組みを実装することが多い。しばしば用いられる手順は次のようなものである。：
- あるタイミングでサーバ側が識別子をブラウザに向けて発行する
- ブラウザからサーバに送られるリクエストにはその識別子が含まれるようになっている
- サーバはその識別子にもとづいてセッションを維持する
ここでは、この識別子のことを「セッションID」と呼ぶことにする。
セッションIDの搬送手段
セッションIDを搬送する手段として、主に次の3種類がある。
- Cookie
- URLリライティング
- hiddenフィールド
(1) CookieによるセッションIDの搬送
Set-Cookieレスポンスヘッダを用いてサーバ側がCookieを発行し、そのCookieをブラウザが自動でサーバへ送り出す方式であり RFC 6265 に規定されてる。プログラミングの手間が最も少ないこともあり、セッションIDの搬送に最も多く用いられていると考えられる。
Cookieを発行する際に与える属性には次のような注意を払う。
- domain={Cookie返送先ドメイン}
Cookie返送先のサーバ群を指定するために、その範囲を指定する属性である。この属性には必要最小限のサーバが含まれるようにインターネットドメイン表記で設定する。 ドメインを階層深く指定することによってCookieを使用するサーバ群が限定されて他のサーバへの露出を避けることができる。
また、この属性自体を設定しないことによって範囲を設定しないこととなり、返送先はサーバ単体を指すことになる。
例
× Set-Cookie: name=value; domain=example.jp; ...
○ Set-Cookie: name=value; domain=foods.onlineshop.example.jp; ...
◎ Set-Cookie: name=value; ...
- path={サイト内のパスのプレフィクス}
path属性に示されたパスのプレフィクスが同一サーバに同居している別のアプリケーションのリソースをカバーすることがないようにする。
加えて、末尾には / を付けるようにする。なぜならば支障のあるブラウザが存在しているからである。URIのマッチングを行うロジックが相違していることに起因する。
例
× Set-Cookie: name=value; domain=...; path=/
△ Set-Cookie: name=value; domain=...; path=/application5/section3
◎ Set-Cookie: name=value; domain=...; path=/application5/section3/
- max-age={有効期間(秒数)} expires={満了日付} （どちらか一方）
長い有効期間または長い満了期日を指定しないようにする。
あるいは、これらの属性をどちらも指定しない。
これらの属性をどちらも指定しなければ Cookieの有効期間は「ブラウザ限り」、すなわちブラウザのプログラムが稼働している間のみとなる。
例
× Set-Cookie: name=value; ...; expires=Fri, 08 Dec 2036 02:33:11 GMT
× Set-Cookie: name=value; ...; max-age=8640000
◎ Set-Cookie: name=value; ... (expiresやmax-ageを指定しない)
- secure （指定するかしないか）
TLSもしくはSSLを用いている場合、原則としてsecure属性を指定する。
secure属性を指定すると、TLSもしくはSSLで保護された通信が用いられている場合のみ、Cookieがブラウザから送出されるようになる。
(2) URLリライティングによるセッションIDの搬送
サーバからブラウザにHTMLドキュメントを送り出す際、そこに書かれているURLのそれぞれにセッションIDを含めるよう書き換えてから送出する方式。
URLリライティングの方式では、URLの一部にセッションIDが含まれているため、キャッシュ、ログ、Referer:ヘッダ等を通じて第三者にその値が漏えいするおそれがある。
URLリライティングは、Cookieが使用できない場面でやむを得ず使用する以外、使用を推奨しない。
(3) hiddenフィールドによるセッションIDの搬送
すべてのページ遷移をフォームデータの送信の形で記述し、フォーム中のhiddenフィールドにセッションIDを含める方式。Cookie、URLリライティングに比べ、第三者に値が流出する事故が起こる要因は少ない。ただし、自然なハイパーリンクの実装のためにJavaScriptのコードを記述する必要が生じる。
セッションID侵害手口の分類
セッション乗っ取りは、正規ユーザが用いているセッションIDを攻撃者が支配下におくことにより、攻撃者が正規ユーザになりすましてWebアプリケーションを操作するものである。
攻撃者が正規ユーザのセッションIDを支配下に置く手口には次の3種類がある。
(1) セッションIDの推測
生成規則が複雑でないセッションIDの現在使われている値を試行錯誤で見つけ出す
(2) セッションIDの奪取
ネットワーク盗聴やスクリプト注入を用いて、実際に使われているセッションIDの値を入手する
(3) セッションIDのお膳立て
罠のハイパーリンクやスクリプト注入を用いて、被害者のブラウザにセッションIDを植え付ける
上記の手口への対策方法はそれぞれ次の記事を見られたい。
- 推測への対策：
記事「セッション乗っ取り: #2 セッションID強度を高める」 - 奪取への対策：
記事「セッション乗っ取り: #3 https:の適切な適用」
記事「スクリプト注入: #1 対策」 - お膳立てへの対策：
記事「セッション乗っ取り: #4 セッションIDお膳立てへの対策」
記事「スクリプト注入: #1 対策」
