Understanding the Rails Authenticity Token

What happens

When the user views a form to create, update, or destroy a resource, the Rails app creates a random authenticity_token, stores this token in the session, and places it in a hidden field in the form. When the user submits the form, Rails looks for the authenticity_token, compares it to the one stored in the session, and if they match the request is allowed to continue.

Why it happens

Since the authenticity token is stored in the session, the client cannot know its value. This prevents people from submitting forms to a Rails app without viewing the form within that app itself. Imagine that you are using service A, you logged into the service and everything is ok. Now imagine that you went to use service B, and you saw a picture you like, and pressed on the picture to view a larger size of it. Now, if some evil code was there at service B, it might send a request to service A (which you are logged into), and ask to delete your account, by sending a request to http://serviceA.com/close_account. This is what is known as CSRF (Cross Site Request Forgery).

Understanding attr_accessible – Secure Your Rails Application

What is the attr_accessible directive ?

So, when you open up your devise User model, and you notice a line similar to that :

attr_accessible :username, :email, :password

The first thing that is important to know about, if you don’t really, is that attr_accessible is simply an instance method, a function as most non-ruby programmers would name. This is actually a part of ActiveModel::MassAssignmentSecurity::ClassMethods, which already some something about its usage. It’s there to prevent mass assignment security attacks.
But what exactly is that ?

 In Ruby on Rails, a mass assignment is when you save more than one attributes of a model to your database. For instance :

current_user.save current_user.update_attributes(...) current_user.update_attribute(...)   <- THIS IS NOT A MASS ASSIGNMENT

Top Web Application Security Problems

How to secure a Web application to avoid hacking? Here are the top most common security risks for a web application that a developer should be awared of.

1.  Cross-site Scripting

Social network and public forum application usually re-post a user post to other readers. When the application display a user post without sanitize the data, a hacker can enter harmful JavaScript in the page.  The JavaScript code will be executed when readers read the page.  The script can steal a user session cookies, redirect a user to a look-a-like-site, or stealing data etc ... Always sanitize user entered data and reject the request for suspicious text.

2.  Session fixation

A hacker obtains a valid session cookie for a particular web site by visiting a web page in the site .  The hacker may post a JavaScript in the web site which replace a visitor cookie with this new session cookie.  When a user view the infested page, the session cookie will be therefore replaced.  The user may be fooled to login again which the hacker can access the account from another machine using the same session cookie.  Web developer needs to sanitize a user post to strip out JavaScript before re-display the text.