質問: `AngularJS`の`CSRF`対策がどのように動作しているのかがよくわかりません。 また、サーバー側に`header('Access-Control-Allow-Origin: *');` の設定を行なっていますが、やはりこの場合は、`AngularJS`の`CSRF`対策が 無効化されてしまうのでしょうか? 昨日さっぱりわからなかったので、調べた上で現時点の知識を記載して まとめましたが、間違いなどのご指摘も頂ければ幸いです。 `CSRF`自体は、私は以下のような感じで理解しています。 「自サイトを`www.hogehoge.co.jp`として 罠サイトが`www.wanawana.com`としますと 自サイト`www.hogehoge.co.jp`にログイン状態のユーザーが 罠サイト(`www.wanawana.com`)内の`www.hogehoge.co.jp`へのリンク クリックするとします。 ログイン状態を識別するためのクッキーが `www.hogehoge.co.jp`へ送信されてしまうので、 ログイン後の操作が可能なようなリクエストを`javascript`などで 作成してあれば、そのリクエストは許可されるため ユーザーの意図しないログイン後の操作を行えてしまう。」 次に、 `AngularJS`の`CSRF`対策の私の理解ですが、 「`X-XSRF-TOKEN`という名前の`Cookie`をサーバーで発行(`www.hogehoge.co.jp`のサーバー) すると、 `AngularJS`はその名前の`Cookie`が存在する場合に、`Http`リクエストに対して`X-XSRF-TOKEN`という 名前のカスタムヘッダー(値はその`Cookie`)を自動で付与する。 サーバー側では、そのカスタムヘッダーを検証して、正規のリクエストかどうかを 判断する。 この場合において、罠サイトで攻撃者がCSRFを成功させるためには、 `www.hogehoge.co.jp`の`X-XSRF-TOKEN`用の`cookie`を`Javascript` で読み出して、`X-XSRF-TOKEN`という名前の`Http`カスタムヘッダーの値として設定 しなければなりません。そして、`Javascript`で読み出してカスタムヘッダーを作成 することは可能です。 カスタムヘッダーがあると、`Same-Origin Policy`の許可状態を確認するために プリフライトリクエストがサーバー側(`www.hogehoge.co.jp`のサーバー)に飛び サーバー側が許可していなければ、許可しない通知がブラウザに届く、そのため 攻撃者が作成したカスタムヘッダー付きのリクエスト自体がサーバーに飛ばない ことになる。 そのため、`CSRF`攻撃の防御に成功する。」 上記に記載した、私が理解するところの、`CSRF`と`AngularJS`の`CSRF`防御の仕組みですが サーバー側で、`Same-Origin Policy`を許可する `header('Access-Control-Allow-Origin: *');` のような設定を行なっている場合は、`AngularJS`の`CSRF`防御の仕組みが無効になってしまうかと 思われるのですが、理解はあっておりますでしょうか? 昨日、一晩考えたんですが、多分こういう風になっているんじゃないかと 推論や演繹による理解で本当はどうなっているのか、よくわからず、詳しいお方の お知恵を頂ければ幸いです。 参考サイト Cross Site Request Forgery (XSRF) Protection
回答: ご提示のURLに書いてありますが、`X-XSRF-TOKEN`は、「Cookieから取得して」「HTTPヘッダにセットする」流れになっています。そして、JavaScriptから「Cookieの内容を読める」のは同一生成元のCookieに限られますので、他のサイトに書かれたJavaScriptからこの値を取得することはできません(もちろん、レンタルサーバなどで不必要に広いドメイン指定をしていた場合などは別ですが)。 また、クロスドメインのXHRで`X-XSRF-TOKEN`のようなカスタムヘッダを使う場合、`OPTIONS`でプレフライトリクエストを投げます。そのレスポンスで`Access-Control-Allow-Headers: X-XSRF-TOKEN`を返すようにしておかないと、このヘッダを含むリクエストは通りません(同一ドメインの場合は問題ありませんが)。積極的な防御というわけではないのですが、`OPTIONS`への対応を実装していない場合、**結果的に**クロスドメインでのリクエストは失敗します。