2011年10月13日木曜日

CookieのDomain属性は *指定しない* が一番安全

たまに誤解があるようですが、Cookieを設定する場合のDomain属性は *設定しない* のがもっとも安全です。以下、例示により説明します。

# このエントリは、はてなダイアリーの過去のエントリからの転載です

example.com上で稼働しているWebアプリケーションで以下の2種類のSet-Cookieについて比較します。
Set-Cookie: SESS1=F3B435;
Set-Cookie: SESS2=2A9E86; Domain=example.com;
SESS2の指定の方がドメインを明示しているので安全と思っている人がいるようですが、これは誤りです。Set-Cookieの際のDomain属性は、指定しない方が安全です。その理由は以下の通りです。
  • Domain属性を指定しないCookieは、Cookieを発行したホストのみに送信される
  • Domain属性を指定したCookieは、指定のホストおよびそのサブドメインのホストに送信される
すなわち、Domain=example.comを指定したCookieは、www.example.comにも送信されます。Domain属性を指定しないCookieは、example.comに送信され、www.example.comには送信されません。
これは、CookieのRFC2965(旧規格)、RFC6265(現規格)には明確に記述されています。
3.3.1 【中略】
Domain Defaults to the effective request-host. (Note that because there is no dot at the beginning of effective request-host, the default Domain can only domain-match itself.)
http://www.ietf.org/rfc/rfc2965.txt
4.1.2.3. The Domain Attribute
【中略】If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.
http://www.ietf.org/rfc/rfc6265.txt
実際のブラウザで調査したところ、Domain属性のないCookieの挙動は以下の結果となりました。
IE9サブドメインにも送信される
Firefox 7.0.1RFC6265通り
Google Chrome 14.0.835.202RFC6265通り
Safari 5.1RFC6265通り
Opera 11.51RFC6265通り
iモード(P-07A)サブドメインにも送信される
Android 2.3.3RFC6265通り
IEiモードRFCに準拠していませんが、その他のメジャーなブラウザRFC通りの動作です。重大な問題とは言えませんが、RFC通りにしてもらいたいですね。
ところで、冒頭で「たまに誤解がある」と書きましたので、ドヤ顔で「CookieはDomain属性を明示すべし」と解説した文書がないか検索してみましたら、ありましたね。
Cookieを発行する際に与える属性には次のような注意を払う。
・domain={Cookie返送先ドメイン}
 domain属性に複数のサーバが含まれるようなドメインを指定しない。
 ドメインを階層深く指定することでCookieを使用するサーバが限定されて他のサーバへの露出を避けることができる。
 例
  × Set-Cookie: name=value; domain=example.jp; ...
  ◎ Set-Cookie: name=value; domain=foods.onlineshop.example.jp; ...
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/302.html
「階層深く」というあたりが妙な表現ですが、いずれの場合でもDomain属性を指定しない状態が、Cookieの送信先を限定できるという意味で一番安全です。
ところで、この文書、色々妙なことが書いてあります。続きを引用します。
・path={サイト内のパスのプレフィクス}
 path属性に示されたパスのプレフィクスが同一サーバに同居している別のアプリケーションリソースをカバーすることがないようにする。
 加えて、末尾には / を付けるようにする。
 例
  × Set-Cookie: name=value; domain=...; path=/
  △ Set-Cookie: name=value; domain=...; path=/application5/section3
  ◎ Set-Cookie: name=value; domain=...; path=/application5/section3/
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/302.html
引用した文書は、セッションハイジャック防止という文脈で書かれているのですが、その場合、CookieのPath属性を指定しても意味がないことが知られています。詳しくは、高木浩光@自宅の日記 - 共用SSLサーバの危険性が理解されていないをご覧ください。
また、(Pathの)「末尾には / を付けるようにする」というのも変です。CookieRFCにはこんな説明はありませんし、RFCで例示されているPath属性の例にも、末尾の / はありません。おそらく、Path=/fooと指定したCookieが /foobar というディレクトリにも送信されることを懸念しての指示だと思いますが、無用な懸念です。
まとめると、Domain属性とPath属性は以下の基準で判断します。
[注]
本エントリの記述内容は、すべて筆者の個人的見解であって、筆者の所属組織とは無関係です。

0 件のコメント:

コメントを投稿

フォロワー