こんにちは。木村です。
今回は3.1 CSRF Countermeasuresです。
原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。
では、以下訳です。
——————————————————
3.1 CSRF Countermeasures
3.1 CSRFの対策方法
- First, as is required by the W3C, use GET and POST appropriately. Secondly, a security token in non-GET requests will protect your application from CSRF.
- まず最初にW3Cが求めるようにGETとPOSTを適切に使用する。2番目に、GETではないリクエストにセキュリティトークンを付加することでCSRFからあなたのアプリケーションを守ります。
The HTTP protocol basically provides two main types of requests – GET and POST (and more, but they are not supported by most browsers). The World Wide Web Consortium (W3C) provides a checklist for choosing HTTP GET or POST:
HTTPプロトコルは基本的に主に2つのタイプのリクエストを提供します。GETとPOSTです(他にもありますが、ほとんどのブラウザでサポートされていません)。 The World Wide Web Consortium(W3C)はHTTP GETまたはPOSTの仕様を選択する時のチェックリストを提供しています。
Use GET if:
GETを使う場合：
- The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
- インタラクションな操作が問い合わせである(すなわち、検索や読み込みや参照のような安全な操作のことです)
Use POST if:
POSTを使う場合：
- The interaction is more like an order, or
- The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
- The user is held accountable for the results of the interaction.
- インタラクションな操作が命令である、または
- 操作の影響でリソースの状態を変更することがユーザにわかりやすい(例えば、サービスへの登録です)、または
- ユーザが操作結果の責任を負わせられる。
If your web application is RESTful, you might be used to additional HTTP verbs, such as PUT or DELETE. Most of today‘s web browsers, however do not support them – only GET and POST. Rails uses a hidden _method field to handle this barrier.
もしあなたのWebアプリケーションがRESTfulならば、あなたはPUTやDELETEのような追加のHTTPメソッドに慣れていることでしょう。
しかしながら、今日のWebブラウザのほとんどは、GETとPOSTだけをサポートしてPUTやDELETEをサポートしていません。
Railsはこの障壁に対処するために、hiddenの_methodフィールドを使用します。
The verify method in a controller can make sure that specific actions may not be used over GET. Here is an example to verify the use of the transfer action over POST. If the action comes in using any other verb, it redirects to the list action.
コントローラのverifyメソッドはGETで特定のアクションが使用できないように確認することができます。POST上でtransferアクションの使用を検証する例は次の通りです。もし何か別のメソッドを使用したアクションが来た場合、listアクションにリダイレクトしています。
verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}
With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application.
この予防策によって、ブラウザが送るイメージへのGETリクエストがWebアプリケーションに受理されないため、上記の攻撃(3. Cross-Site Request Forgery (CSRF)で例に挙げられている攻撃)は動作しません。
But this was only the first step, because POST requests can be sent automatically, too. Here is an example for a link which displays www.harmless.com as destination in the browser’s status bar. In fact it dynamically creates a new form that sends a POST request.
しかし、これは最初のステップに過ぎません。なぜなら、POSTリクエストも自動的に送ることができるからです。ブラウザのステータスバーに目的地としてwww.harmless.comと表示しているリンクの例が次の通りです。実際にはそのリンクはPOSTリクエストを送る新しいフォームを動的に生成します。
<a href="http://www.harmless.com/" onclick="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = 'http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>
Or the attacker places the code into the onmouseover event handler of an image:
つまり、攻撃者はイメージのonmouseoverイベントハンドラにコードを設置しています。
<img src="http://www.harmless.com/img" width="400" height="400" onmouseover="..." />
There are many other possibilities, including Ajax to attack the victim in the background. The solution to this is including a security token in non-GET requests which check on the server-side. In Rails 2 or higher, this is a one-liner in the application controller:
バックグラウンドで攻撃するためにAjaxを含んでいると、他に多くの可能性があります。この問題の解決方法はGETではないリクエストにサーバ側でチェックするセキュリティトークンを付加することです。Rails2またはそれ以上のバージョンでは、application controllerでワンライナーで書かれています。
protect_from_forgery :secret => "123456789012345678901234567890..."
This will automatically include a security token, calculated from the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won’t need the secret, if you use CookieStorage as session storage. It will raise an ActionController::InvalidAuthenticityToken error, if the security token doesn’t match what was expected.
これはRailsによって生成される全てのフォームとAjaxリクエストに、現在のセッションとサーバ側の秘密の文字列から作られるセキュリティトークンを自動的に付加します。セッションストレージとしてCookieStorageを使用しているならば、秘密の文字列は必要ありません。セキュリティトークンが期待されるものとマッチしなければ、ActionController::InvalidAuthenticityTokenエラーが発生するでしょう。
Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form. Read more about XSS later.
cross-site scripting(XSS)は全てのCSRF対策を回避することに注意してください。
XSSは攻撃者にページ上の全ての要素へのアクセスを許します。そのため、攻撃者はフォームからCSRFセキュリティトークンを読み込むか、直接フォームを投稿することができます。
XSSについての詳細は後述します。
——————————————————
次回は4 Redirection and Filesです。
