Ruby
on Rails is a popular framework for web applications, built on the dynamic Ruby
programming language. Estimates indicate that a quarter of a million websites
use it, including Airbnb, Basecamp, Groupon, Hulu, and Slideshare. Developers
love working with it because it is expandable and it helps them get from
concept to prototype quickly.
I am
a good believer in secure by default and making security easy for developers.
Some can argue that by create security easy, it can make developers pay less
attention to security and possibly lead them to making creating security
mistakes. Kind of like a horse with blinkers on. In reality I think it is
probably a balance, do not create security invisible to the developer but
instead create it just easy enough for them to implement in right way.
So
be warned! Do not just RORs built in security features thinking that they offer
a 100% most effective way at mitigating the vulnerabilities they could designed
to prevent against. Instead, learn how to used them rightly and know their
limitations.
For
major security issues or error, the current release series, the next most
recent one, and the last additional major series may receive or take patches
and some latest versions. This is currently new versions 5.0.x and 4.2.x.
When
a release series is no longer supported, it’s your own responsibility to deal
with issues or errors. We can offers backports of the fixes and publish them to
git, however there may be no new versions released. If you are not comfortable
maintaining your own versions, you should upgrade to a new supported version.
As
we have seen, Rails provides many built in security features to help protect
our applications, data and users from web based virus attacks and some other
attacks. But we also saw that these have their limitations. For security
features that Rails does not provide by default there are always Gems, lots and
lots of Gems
System
or devise is a popular authentication and authorisation Gem for Rails. It provides
secure password storage using bcrypt to hash salted passwords. User lockouts,
user registration, forgot password functionality and more.
Although
system or Devise’s own README states, “If you may building your 1ST Rails
application, we recommend you do not use Devise or System”, I would ignore this
statement. If you are security aware and you have built applications in other
frameworks before, I do not see any issue or error with using Devise or system
for your IST Rails application.
URL:
https://github.com/plataformatec/devise
Brakeman
Brakeman
is a Static Code Analysis (SCA) tool for Rails applications.
It searches your application’s source code for potential vulnerabilities.
Although it can report the occasional False or Positive, personally, I think
this is a great Gem and one I would definitely recommend running against your
application before going into production. Even better, run it after every
commit.
URL:
https://github.com/presidentbeef/brakeman
secure_headers
Developed
by Twitter, Secure Headers is a Gem that implements security related HTTP (Hypertext Transfer Protocol)
headers into your application’s HTTP(Hypertext Transfer Protocol)
responses. Headers such as Content
Security Policy to help protect against Cross-Site Scripting (XSS) attacks,
HTTP Strict Transport Security (HSTS) to ensure your site is only accessible
over secure HTTPS, X-Frame-Options and others.
URL:
https://github.com/twitter/secureheaders
rack-attack
Developed
by Kickstarter, Rack::Attack is a Gem for blocking & throttling abusive
requests. Personally, I use
Rack::Attack to prevent forms being abused, for example, instead of
implementing a CAPTCHA on a submission form, I use Rack::Attack to ensure it is
not submitted too many times in a short space of time. This would prevent
automated tools from abusing the form submission. It also supports whitelisting
and blacklisting of requests.
