I'm a PHP developer learning Ruby on Rails by reading Michael Hartl's tutorial. Here is a quote from the book, referring to csrf_meta_tag
:
...the Rails method
csrf_meta_tag
[prevents] cross-site request forgery (CSRF), a type of malicious web attack. Don’t worry about the details (I don’t); just know that Rails is working hard to keep your application secure.
The thing is, I'm genuinely curious. How does inserting csrf-param
and csrf-token
meta tags prevent CSRF? I tried Googling, but couldn't find anything.
Rails, like most modern frameworks, comes with CSRF protection baked in. It does so by setting the CSRF token in the session, in the meta tags in your site’s <head /> area, and as a hidden field in each form. Alex Taylor explains how this works: There are two components to CSRF.
...the Rails method csrf_meta_tag[prevents] cross-site request forgery (CSRF), a type of malicious web attack. Don’t worry about the details (I don’t); just know that Rails is working hard to keep your application secure.
The error messages can be cryptic, and the only place in the Rails Guides CSRF is mentioned is in the Ruby on Rails Security Guide and briefly in the csrf_meta_tags page. You’d think it would be covered in Working with JavaScript in Rails, but there isn’t a single mention of it.
Even the “csrf-token” meta tag is inserted for you as long as you leave the csrf_meta_tags line in your application.html.erb layout file. When a request is made, Rails ensures both the session cookie and the form parameter match up. It does this with the protect_from_forgery line in your ApplicationController.
csrf_meta_tag
is basically fulfilling the same thing as hidden form fields but is there to give javascript requests that aren't tied to a form an easy way of getting the token.
If you use the jquery-ujs library the content of that meta tag is automatically added (as a request header) to any ajax requests made.
The csrf_meta_tag
inserts what is essentially a digitial signature into the page, acting as verification that requests coming into the application server are, in fact, from properly logged in users. This helps prevent cross-site scripting (a script on a completely unrelated page firing requests off to say, GMail, while you're logged into your GMail in another tab).
I guess to clarify, the csrf_meta_tag
itself doesn't prevent an unrelated page from firing off requests to your GMail (or any other service that is the target of the attack), but the "digital signature" in the csrf_meta_tag
is used to verify the validity of said requests. Invalid requests (i.e. from cross-site scripting attempts) should fail validation, and are therefore discarded.
To say it another way, from the attacker's point of view:
Before csrf_meta_tags
existed (they aren't exclusive to Rails by any means), successful cross-site scripting attacks allowed a malicious site to submit data to a web app in a way that makes the request appear as if it's being done on the user's behalf. So, let's say you're an admin on a web service, and in one browser tab you're logged into the admin panel for that service. If a malicious site open in another tab targeted your service for an attack, the malicious site might be able to run scripts that make admin requests, such as dumping list of users from the database, stealing other sensitive data, or potentially harming, damaging, or destroying data contained in the service, all while appearing (from the server's standpoint) to be valid requests from the admin themselves. The csrf_meta_tag
is a way to sign requests, and help thwart such attempts from being successful.
There's a much more detailed explanation available here.
It would also be educational to do a "view source" on one of your Rails-generated pages, and you'll see what the CSRF tag looks like.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With