Strict Secure Cookie と Cookie Prefix

クッキーの Secure 属性についてはいろいろな解説がある通り、この属性が付与されたクッキーは HTTPS 通信でないとサーバーに送信されない。

一方で良く知られていた問題として、 Secure 属性のクッキーは HTTP 通信されたドメインからでも設定できることになっている(少なくとも仕様上は)、というものがある。 少なくとも現行の RFC (RFC6265) の仕様上でも、そうなっている。

結果、例えば公共の Wi-Fi を使っているつもりで悪意ハッカーが運営するアクセスポイントからインターネットアクセスしてしまっていた場合、ブラウザ上の HTTP 通信が一度でも発行されれば、それを利用して任意のドメインへ HTTP でリダイレクトしながら、そこで Secure 属性クッキーを上書き設定した後、 HTTPS へ再度リダイレクトすることで、実質任意ドメインの Secure 属性クッキーを上書いてユーザーに HTTPS 通信させることができるようになる。

これにより、例えば Naive Double Submit Cookie への攻撃であったり、 Session Fixation Attack など、他の脆弱性に晒される可能性が上がる。

緩和的対策としての Strict Secure Cookie

https://chromestatus.com/feature/4506322921848832

少なくとも Chrome と Firefox のブラウザについては、上記攻撃たちへの緩和策として、 Strict Secure Cookie というものを実装し、有効化している。 (RFC 化もその実装の最初から進められていて、今現在では RFC6265 全体を改訂するドラフト に吸収された状態となっている。 draft であるので、まだ approve には至っていない模様)

これは、セキュアではないチャンネル(HTTP)でのアクセスによって Set-Cookie されるクッキーには、 secure 属性を付与することはできないようにし、また、すでに Secure 属性が設定されるクッキーは、 non-secure な Set-Cookie によって上書きできないようにする修正である。

この結果、既に https アクセスしていてクッキーが残っているサイトに向かって MitM で HTTP リダイレクトされてしまったとしても、 Secure 属性の Cookie たちは不変のままで済むことになる。

ただ、長い間アクセスを放置しているなどして、 Cookie が expire しているサイトに飛ばされたり、まだアクセスしたことないサイトに飛んだような場合には、 Secure でないクッキーでよいからブラウザに設定した後に HTTPS リダイレクトを行うことで、やはりこの問題は発生する。 (サーバーからは、送られてきたクッキーが Secure 属性なものだったのかどうかを厳密に判定する術を、後述の cookie prefix を除いて持たない)

より根本解決としての Cookie Prefix

特定の prefix から始まるクッキーは、特定(e.g. https, Domain の未指定)の状況でないと設定できないようにしたのが Cookie Prefix である。 これも同様に RFC6265 の改訂ドラフト最新版には含まれている。

Cookies: HTTP State Management Mechanism

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265.

datatracker.ietf.org

具体的には、 __Secure- から始まるクッキーは、 Secure 属性が指定されていなければ設定できず、 __Host- から始まるクッキーは、さらに Domain 属性が未指定で、かつ、 Path 属性が / でなければ設定できない。

これと Strict Secure Cookie が合わさることにより、モダンなウェブシステムでは適切にクッキーを設定することにより、 MitM からのクッキー改変に完璧に対抗できるようになった。 (と自分は理解した。)

参考資料

Strict secure cookies vs. cookie prefixes

The secure flag on cookies prevent them from being read by an insecure (non-HTTPS) site, but they can still be written or deleted from an insecure site. There are two new browser features that try to

security.stackexchange.com