evil.example.comがドメイン属性を.example.comに設定したCookieを設定した場合、ブラウザはこのCookieをfoo.example.comへのリクエストに含めます。
Tangled Webは、foo.example.comの場合、そのようなCookieはfoo.example.comによって設定されたCookieとほとんど区別がつかないと述べています。ただし、RFCによると、Cookieのドメイン属性をサーバーに送信する必要があります。これにより、foo.example.comは、evil.example.comによって設定されたCookieを区別して拒否できるようになります。
現在のブラウザの実装の状態はどうなっていますか？ドメインはCookieとともに返送されますか？
RFC 2109 と RFC 2965 は、Cookie の処理を標準化するための歴史的な試みでした。残念ながら、それらはブラウザーが実際に行うこととは似ていないため、完全に無視する必要があります。
実際の動作は、主に元の Netscape cookie_spec によって定義されていましたが、これは仕様として非常に不十分であり、ブラウザのさまざまな違いが生じています。
RFC 6265 は、この混乱を一掃し、ブラウザーが何を目指すべきかを明確に成文化する試みです。歴史上、ブラウザがこれを行ったことがないため、domainブラウザが送信する必要があるとは言いません。path
Cookie が親 (*) からのものであることを検出できないためdomain、Cookie を別々に保持したい場合は、ドメインが重複しないようにホスト名に注意する必要があります。設定されている場合、オンにdomain設定された Cookieexample.comは常に に継承されfoo.example.comます。
したがって、将来的に個別の Cookie を持つサブドメインが必要になる可能性がある場合は、サイトに「no-www」ホスト名を使用しないでください (親から機密性の高い Cookie を読み取れないようにする必要があります)。evil.example.comまた、 Cookie の値が他のサイトに挿入されるのを防ぐために、完全に別個の Cookie コンテキストが本当に必要な場合は、example.com完全に別個のドメイン名を使用するしかありません。
一部の攻撃モデルに対して有効な代替手段は、たとえばHMACを使用して、生成するすべての Cookie 値に署名することです。
*: ある種の方法があります。必要な Cookieと同じ設定で Cookie を削除してみてください。そのときに Cookie が消えた場合は、それらと設定があったはずなので、元の Cookie は問題ありませんでした。そこにまだ Cookie がある場合、それは別の場所からのものであり、無視することができます。これは不便で、JavaScript なしで行うのは非現実的です。原則として、攻撃者は挿入された Cookie を同時に削除する可能性があるため、完全ではありません。domainpathdomainpath
Cookieの現在の標準はRFC6265です。Cookie:このバージョンでは、ヘッダーが簡略化されています。ブラウザname=valueは、ドメインのような属性ではなく、Cookieのペアを送信するだけです。このヘッダーの仕様については、RFCのセクション4.2を参照してください。また、セクション8.6、弱い整合性を参照してください。ここでは、foo.example.comが.example.comにCookieを設定でき、bar.example.comはそれが設定したCookieではないことを認識できないという事実について説明しています。自体。
Zalewski の本と彼のhttps://code.google.com/p/browsersec/wiki/Mainは、RFC よりも優れていると思います。ブラウザーの多数の HTTP 機能の実装は、厄介で非標準であることで有名です。