aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source
diff options
context:
space:
mode:
authorJeremy Kemper <jeremy@bitsweat.net>2013-12-12 20:41:14 -0700
committerJeremy Kemper <jeremy@bitsweat.net>2013-12-17 13:14:17 -0700
commit1650bb3d56897cfef4c7e6b86a36eed4f1a41df5 (patch)
tree6f2e5fc872568c8d0f74e17e0e05230c6173526e /guides/source
parent290368bdb2c9ecb7d6212a1d3767ae69554788a9 (diff)
downloadrails-1650bb3d56897cfef4c7e6b86a36eed4f1a41df5.tar.gz
rails-1650bb3d56897cfef4c7e6b86a36eed4f1a41df5.tar.bz2
rails-1650bb3d56897cfef4c7e6b86a36eed4f1a41df5.zip
CSRF protection from cross-origin <script> tags
Thanks to @homakov for sounding the alarm about JSONP-style data leaking
Diffstat (limited to 'guides/source')
-rw-r--r--guides/source/security.md8
1 files changed, 5 insertions, 3 deletions
diff --git a/guides/source/security.md b/guides/source/security.md
index c698959a2c..21cc3deb8a 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -230,13 +230,15 @@ Or the attacker places the code into the onmouseover event handler of an image:
<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:
+There are many other possibilities, like using a `<script>` tag to make a cross-site request to a URL with a JSONP or JavaScript response. The response is executable code that the attacker can find a way to run, possibly extracting sensitive data. To protect against this data leakage, we disallow cross-site `<script>` tags. Only Ajax requests may have JavaScript responses since XmlHttpRequest is subject to the browser Same-Origin policy - meaning only your site can initiate the request.
+
+To protect against all other forged requests, we introduce a _required security token_ that our site knows but other sites don't know. We include the security token in requests and verify it on the server. This is a one-liner in your application controller:
```ruby
-protect_from_forgery secret: "123456789012345678901234567890..."
+protect_from_forgery
```
-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. If the security token doesn't match what was expected, the session will be reset. **Note:** In Rails versions prior to 3.0.4, this raised an `ActionController::InvalidAuthenticityToken` error.
+This will automatically include a security token in all forms and Ajax requests generated by Rails. If the security token doesn't match what was expected, the session will be reset.
It is common to use persistent cookies to store user information, with `cookies.permanent` for example. In this case, the cookies will not be cleared and the out of the box CSRF protection will not be effective. If you are using a different cookie store than the session for this information, you must handle what to do with it yourself: