example.org が Cookie を使用してユーザーを認証し、クロスサイト リクエスト フォージェリ保護を実装していないとします。CSRF 攻撃に対して保護されたサード パーティの Cookie を無効にした example.org ユーザーですか (example.org へのすべての機密要求には有効な認証 Cookie の存在が必要であると仮定します)? そうでない場合、evil.com が example.org ユーザーの名前で機密性の高い操作を実行する方法を示す例を挙げていただけますか?
2 に答える
サード パーティの Cookie を無効にしても、ブラウザはサード パーティのサイトによって設定された Cookie を拒否するだけです。したがって、サイトAからページにアクセスしていて、サイトBから要求されたリソースがある場合、ブラウザはサイトAからのものではない Cookie をすべて拒否します。
ただし、サード パーティのサイト セットの Cookie が既に存在する場合、つまり、サード パーティのサイトに直接アクセスしたことがある場合、ブラウザはそれらをリクエストで送信します。したがって、サイトAからページにアクセスしていて、サイトBから要求されたリソースがある場合、ブラウザはサイトBに設定された Cookie を送信します。
つまり、サード パーティの Cookie を無効にしても、CSRF からは保護されません。
まず、サード パーティの Cookieの仕組みを理解する必要があります。最も一般的な説明には広告が含まれているため、私も同じことを行います。
サイトにアクセスしsomesite.com
、グラフィック広告が含まれている場合。
サイトが広告へのリクエストを行うとき(広告がads.comからのものであると仮定)、広告のads.com
読み込みを要求し、Cookieの保存を許可します. その Cookie を使用して、ユーザーのプロファイルを作成できます。そのため、サード パーティの Cookieはトラッキング Cookieと呼ばれることがあります。
サード パーティの Cookie をブロックすると、ブラウザーは (この例では) Cookie の保存を許可しませんads.com
(ただし、広告は引き続き表示されます)。
したがって、 とのセッションが開いていて、mymail.com
を入力すると、からの操作を要求するイメージ(例: img src=mymail.com/deleteAll ) があるとします。evil.com
evil.com
mymail.com
ブラウザはこのサイトにリクエストを送信しますが、開いているセッションがあり、csrf on に対する保護がないためmymail.com
、リクエストは、セッションがあるため、既に持っている Cookie で渡されmymail.com
ます。
さらに読むために、 OWASPのcsrf防止チートシートを読むことをお勧めします。