サイト運営者は、サイトにアクセスしているブラウザのクッキージャーにCookieを設定するようリクエストできます。あなたのサイトが機能するために必要なセッション間でのクッキーの永続性の維持を選択することができます(ユーザーがログインしたままにするためにセッションクッキーを提示する必要があります)。しかし、あなたはクッキージャーを「所有している」わけではなく、あなたが設定したセッションクッキーとともに他のクッキー(セッションクッキーと永続クッキーの両方を含む)を提示することはできません。一般に、あなたのコードはあなたが期待するクッキーを探し、期待していないクッキーは無視しなければなりません。彼らがあなたの支配下にないためにあなたが期待していなかった "余分な"クッキーの存在に基づいて何らかの行動を取ることは、良い習慣ではありません。
ユーザーは、ブラウザの助けを借りて、クッキージャーを制御するユーザーです。クッキーの取り扱いを完全に無効にするか(またはクッキーをサポートしていないクライアントを使用する)かを選択できます。あなたのセッションクッキーが期待どおりに戻ってこないことが判明した場合、クライアントがクッキーをサポートしていないか、フォールバックを実装していないと思われることをユーザーに知らせることが良いでしょうクッキーを必要としないセッション管理を計画していますが、私の意見では、「余分な」クッキーが受信された場合に警告メッセージは適切ではありません。
ユーザーはブラウザを制御するので、クッキージャーを手動で編集することで、ブラウザに好きなクッキーを設定できます。サイトのドメインとパスに適用されるCookieが設定されている場合、クライアントはそのCookieをHTTPリクエストとともにサイトに送信します。
また、サイトがドメインの一部を他のサイトと共有している場合、他のサイトはサイトにも表示されるCookieを設定することがあります。たとえば、サイトがhttp://site1.example.com/
にアクセス可能で、別のサイトがhttp://site2.example.com/
にある場合、site2のオペレータはexample.com
に設定されたドメインでCookieを設定できます。その場合、site1
とsite2
(およびその他のサブドメインはexample.com
)。
あなたが管理しているドメインでしかサイトにアクセスできない場合でも、ブラウザーで「スーパークッキー」防止機能が無効になる可能性があります(「.com」などのトップレベルドメイン名に設定されたCookie) 。通常、ブラウザはこれらの「公開サフィックス」(https://tools.ietf.org/html/rfc6265#section-5.3を参照)を許可しないでください。ただし、高度なブラウザ設定で無効にすることは可能です。
他のドメインのCookieを使用してサイトを攻撃する可能性を回避するには、CookieのドメインとパスとCookieの値自体が一致することを確認することをお勧めします。
これらのCookieを送信すると、その出所を特定するのに役立ちます。 – Rei
残念ながら、私はそれらを保管していませんでした。クッキーを処理するバグが原因で、私のサーバー側のエンジンがクラッシュしたためにのみ、この効果に気付きました。バグは修正されましたが、何らかのトラップを書いてから、これらのクッキーを取得するために特別な訪問者を待つ必要があります。 – johnfound
あなたが待っている間、すべてのクッキーを記録してください。しかし、あなたのエンジンはクッキーのために墜落しましたか?それには何か問題があります。たぶんあなたは、コードレビューでコードを投稿するべきです。 – Rei