Top 5 Security Guides for your Rails App

Top 5 Security Guides for your Rails App

Rails App

Security has been a major issue for the sensitive information and classified data that are shared over internet with the help of web applications.  Let’s have a quick understanding – what attackers do and how they do it. We’re sure the quickies below will help to make your Rails app more secure and stealthier.

1. Sessions

ROR_Sub_banners29_2_16_-4

In networking “Sessions” indicates the time of browsing a website by a user. Without sessions the user would have no identity, so you/user have to authenticate on every request.

There are several ways in which hackers use sessions to exploit sensitive information, such as Session Hijacking, Replay Attack, Session Fixation and Session Expiry.

Rails create a new/ fake session when a new user accesses the application and loads the existing session if the user has already used the same. Many storage mechanisms are provided in Rails for session hashes, the most important of them is ActionDispacth::Session::Cookie Store. Another way is to set the expiry time-stamp of the cookie with the session id. Here is an example:

class Session <ActiveRecord::Base

defself.sweep (time = 1.hour) iftime.is_a?(String)

time = time.split.inject { |count, unit| count.to_i.send(unit)

end

delete_all “updated_at< ‘#{time.ago.to_s(:db)}'”

end

end

2. Cross Site Request Forgery (CSRF)

ROR_Sub_banners29_2_16_v1

When the user authenticates a malicious code or a link in a page which access a web application, it is Cross-Site Request Forgery known as CSRF. If the session for that application is still active, the application becomes vulnerable, as any attacker may execute unauthorized commands.

To prevent CSRF attacks, you should use GET and POST method appropriately. Rails use a hidden _method to handle additional HTTP verbs such as PUT, PATCH and DELETE. A required security token has introduced to protect against all other forged requests.

            protect_from_forgery with: :exception

This includes a security token in all forms and Ajax requests generated by Rails automatically. An exception will be thrown if the security token doesn’t match.

3. Redirection and Files

ROR_Sub_banners29_2_16_-2

This process involves redirection of user to a fake web application which looks and feels exactly like the original application. Then the attackers can get the information about the user or can originate a self-contained attack. This can be prevented using a legacy action:

def legacy

redirect_to(params.update(action:’main’))

end

When uploading a file, make sure not to overwrite important files and process the media file asynchronously. The file should be saved and processing request in the database should be scheduled. Users should be restricted not to download arbitrary files. File name like “../../../etc/passwd” can download server’s login information. Rails make it possible to check that the requested file is in the expected directory.

basename = File.expand_path(File.join(File.dirname(__FILE__), ‘../../files’))

filename = File.expand_path(File.join(basename, @file.public_filename))

raise if basename !=

File.expand_path(File.join(File.dirname(filename), ‘../../../’))

send_file filename, disposition: ‘inline’

4. Injection

ROR_Sub_banners29_2_16_-3

Injection is a class of attacks that uses injection of data in to a web application in order to facilitate the execution of harmful data in an unexpected manner. This includes Cross-Site Scripting (XSS), SQL injection, CSS Injection, Command Line injection, Header injection.

Rails provide some helper methods to prevent SQL injection and Cross-Site Scripting. There is a method called sanitize() as a model for whitelist CSS filter, this can be used as a countermeasure of CSS injection. You should update the Rails version to 2.1.2 to prevent header injection.

5. Denial of Service: DOS

ROR_Sub_banners29_2_16_-5

DOS, and DDOS attacks are not going to steal your data or spread malware. They just want to shut you down. DDOS is crude but effective. To mount a distributed denial of service attack, just call up 500 of your closest friends, have them appraise to amnesty international’s website and keep pressing refresh for an hour. Bots can be substituted for friends.

This blog explains five important vulnerabilities and how to protect against them. However, there are lots of other things you need to know when developing Rails app that are not covered here, so make sure you get the escapes and proofing’s from @Andolasoft. We use Ruby on Rails as a core technology for delivering high quality secured web apps. We develop and maintain code base, use many technologies to protect you from hackers.

Do you have something to add up? Please drop in your comments below or talk to us.

Jay
Jayadev Das
jayadev.das@andolasoft.com

Do what you do best in – that’s what I’ve always believed in and that’s what I preach. Over the past 25+ years (yup that’s my expertise ‘n’ experience in the Information Technology domain), I’ve been consulting to small, medium and large companies ‘bout Web Technologies, Mobile Future as well as on the good-and-bad of tech. Blogger, International Business Advisor, Web Technology Expert, Sales Guru, Startup Mentor, Insurance Sales Portal Expert & a Tennis Player. And top of all – a complete family man!