アーカイブ

第4章 2.セッション乗っ取り：セッションIDとセッションID侵害手口

公開日：2007年6月28日

独立行政法人情報処理推進機構
セキュリティセンター

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

まず、セッションを維持するためのセッションIDを搬送する3つの手段に関する考慮事項を述べる。次に、セッションIDを侵害する手口を大きく3つに分類して示す。

セッションを維持する仕組み

Webブラウザと Webサーバの間の通信に用いられる HTTP（Hypertext Transfer Protocol）には、セッション、すなわち複数のWebページからなる操作の流れを維持するための仕組みが十分には備わっていない。

そこで、WebアプリケーションエンジンあるいはWebアプリケーションそのものがセッションを維持する仕組みを実装することが多い。しばしば用いられる手順は次のようなものである。

あるタイミングでサーバ側が識別子をブラウザに向けて発行する
ブラウザからサーバに送られるリクエストにはその識別子が含まれるようになっている
サーバはその識別子にもとづいてセッションを維持する

ここでは、この識別子のことを「セッションID」と呼ぶことにする。

セッションIDの搬送手段

セッションIDを搬送する主要な手段として下記の3つ手段がある。

Cookie
hiddenフィールド
URLリライティング

注：これら以外には、アクセストークンに保持させることがある。

(1) CookieによるセッションIDの搬送

Set-Cookieレスポンスヘッダを用いてサーバ側がCookieを発行し、そのCookieをブラウザが自動でサーバへ送り出す方式であり RFC 6265(注釈)に規定されてる。プログラミングの手間が最も少ないこともあり、セッションIDの搬送に最も多く用いられていると考えられる。

注釈：

RFC 6265

Cookieを発行する際に与える属性には次のような注意を払う。

domain={Cookie送信先ドメイン}: Cookie送信先のドメインを指定するために、その範囲を指定する属性である。この属性には必要最小限のドメインが含まれるようにインターネットドメイン表記で設定する。

この属性を設定しないことによって、送信先をCookieを発行したサーバに限定することができる。

値を設定した場合には、Cookieを発行したサーバのみではなく、設定したドメイン記述の配下のサーバにも送信先となるため注意が必要となる。

例
×　Set-Cookie: name=value; domain=example.jp; ...
△　Set-Cookie: name=value; domain=foods.onlineshop.example.jp; ...
◎　Set-Cookie: name=value; ...

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がブラウザから送出されるようになる。

httponly （指定するかしないか）: 原則としてhttponly属性を指定する。 HTTPテキスト内のスクリプトでCookieにアクセスする場合は、httponly属性を指定しない。

httponly属性を指定すると、HTTPテキスト内のスクリプトからCookieをアクセスできなくなる。これにより、ウェブサイトにクロスサイト・スクリプティングの脆弱性があっても、その脆弱性によってCookieを盗まれるという事態を防止できる。

(2) hiddenフィールドによるセッションIDの搬送

すべてのページ遷移をフォームデータの送信の形で記述し、フォーム中のhiddenフィールドにセッションIDを含める方式。Cookie、URLリライティングに比べ、第三者に値が流出する事故が起こる要因は少ない。ただし、自然なハイパーリンクの実装のためにJavaScriptのコードを記述する必要が生じる。

(3) URLリライティングによるセッションIDの搬送

サーバからブラウザに HTMLドキュメントを送り出す際、そこに書かれているURLのそれぞれにセッションIDを含めるよう書き換えてから送出する方式。

URLリライティングの方式では、URLの一部にセッションIDが含まれているため、キャッシュ、ログ、Referer:ヘッダ等を通じて第三者にその値が漏えいするおそれがある。

URLリライティングは、Cookieが使用できない場面でやむを得ず使用する以外、使用を推奨しない。