「Double Submit Cookie」はOWASPが提唱するCSRF対策の1つです。
しかし「安全なWebアプリケーションの作り方」の著者である徳丸さんは、ブログで次のように指摘しています。
Double Submit Cookieは、サーバー側で状態を保持する必要が無いため、RESTとの相性が良いというのも最近好まれる理由かと思いますが、外部からクッキーを変更されないことを前提しているところが微妙なところです。
サーバーレスアプリケーションのCSRF対策でDouble Submit Cookieを検討されている人（私もそう）には残念ですが、他の方法を考えた方が良さそうです。
OWASPのDouble Submit Cookieの項を翻訳したものを載せておきます。
If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie.
セッションにCSRFトークンを保持することが難しければ、代替の防御手段としては Double Submit Cookie の利用が挙げられる。
A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.
Double Submit Cookie は、Cookie とリクエストパラメータの両方で乱数値を送り、サーバで Cookie 値とリクエスト値が一致するか検証することとして定義されている。
When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id.
ユーザがサイトで認証しているとき、サイトは (暗号理論的に強度の高い) 擬似乱数値を生成し、それをユーザのマシン上のセッションIDとは分けられた Cookie として設定すべきである。
The site does not have to save this value in any way, thus avoiding server side state.
サーバ側で状態を知ることを避けるため、サイトは何らかの方法でこの値を保存する必要はない。
The site then requires that every transaction request include this random value as a hidden form value (or other request parameter).
そのときサイトは、hidden フォーム値 (もしくは他のリクエストパラメータ) として、あらゆるトランザクションリクエストがこの乱数値を含むことを要求する。
A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy.
オリジン間攻撃者は same-origin policy (同一生成元ポリシー) により、サーバから送られたいかなるデータを読み取ることも、Cookie 値を改変することもできない。
This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
これは、攻撃者が悪意のあるCSRFリクエストによって目当ての値を被害者に送らせたとしても、攻撃者は Cookie に保持した値を変更することも読み取ることもできなくなることを意味する。
Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.
Cookie 値とリクエストパラメータもしくはフォーム値が一致しなければならないことから、攻撃者はでたらめなCSRF値でリクエストの投稿を強制することができなくなる。
As an example, the Direct Web Remoting (DWR) Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.
例として、Direct Web Remoting (DWR) Javaライブラリver.2.0は、Double Cookie Submission を透過的に実装したCSRFプロテクションを持っている。
When the UI and the function service reside in different hosts, the Double Submit Cookie guard turns difficult to implement because the UI body and the Set-Cookie response header will be generated as part of different requests to different processes.
UIとロジックが別々にホストされているとき、UI自体と Set-Cookie レスポンスヘッダは異なるプロセスの異なるリクエストの一部として生成されるので、Double Submit Cookie による保護が難しくなる。
The Set-Cookie response header would need to be induced by a request from the client javascript.
Set-Cookie レスポンスヘッダは、クライアントの JavaScript からのリクエストによって生成させる必要がある。
In that case, making sure that both the UI and the service request came from a client serviced by the same UI origin appears as difficult as the original issue.
その場合、UIとクライアントから来たリクエストの両方が、同じUIを生成元とすることを確認するのは元の問題と同じくらい難しい。
以上です。このエントリでは Double Submit Cookie について調べました。
コメントを送る
コメントはブログオーナーのみ閲覧できます