{"id":24783,"date":"2019-09-05T12:15:22","date_gmt":"2019-09-05T09:15:22","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=24783"},"modified":"2019-09-05T10:14:00","modified_gmt":"2019-09-05T07:14:00","slug":"ensuring-security-covered-application","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/ruby\/ensuring-security-covered-application\/","title":{"rendered":"Ruby on Rails Developer Series: Ensuring Security is Covered in Your Application"},"content":{"rendered":"\n

Welcome to the last and fourth blog post in my Ruby on Rails Developer Series. In this part, our goal is to go over some major security themes to ensure best practices. We will piggyback from the project you have been building in the other parts and use project-specific scenarios that will help secure the application. The series theme is to make you feel confident as an engineer in building a structured project with Ruby on Rails.<\/p>\n\n\n\n

1. Authentication<\/h2>\n\n\n\n

Having authentication set up helps verify that the user is sanctioned to have access. Say you wanted to access a specific item in our Todo list todos\/{:todo_id}\/item\/{:item_id}<\/code>, however, if we don\u2019t validate, the user has access to view records. They can easily change the numbers of the todo_id<\/code> and item_id<\/code> and view those.<\/p>\n\n\n\n

I recommended you use an existing gem-like devise<\/a> for authentication. Devise uses Bcrypt which makes it extremely difficult to for hackers to compute a password as it\u2019s computationally expensive with time. Devise has modules to also help with recovering passwords, registering, tracking user sign-ins, locking records, etc.<\/p>\n\n\n\n

2. Strong Parameters<\/h2>\n\n\n\n

Having strong parameters is when you securely permit the data being sent to you from a request. Let us say we created a form that creates a Todo record: If we followed this common pattern Todo.create(params[:todo]<\/code>. And say the form was altered with fields that don\u2019t exist in the model then rails will raise an exception. The same scenario works for updating values in a form if there is something we didn\u2019t want to be updated.<\/p>\n\n\n\n

What do I do?<\/strong><\/p>\n\n\n\n

By using strong parameters, you whitelist the values that can be used.<\/p>\n\n\n\n

params.require(:todo).permit(:name, :priority)<\/code><\/p>\n\n\n\n

Now if the user submits the form with incorrect data to the parameterized fields the form will throw an error.<\/p>\n\n\n\n

How do I use it?<\/strong><\/p>\n\n\n\n

\n
\n\n\n\n
\n
1<\/div>\n
2<\/div>\n
3<\/div>\n
4<\/div>\n
5<\/div>\n
6<\/div>\n
7<\/div>\n<\/td>\n
\n
\n
def create<\/code><\/div>\n
    <\/code>Todo.create(todo_params)<\/code><\/div>\n
end<\/code><\/div>\n
 <\/div>\n
def todo_params<\/code><\/div>\n
    <\/code>params.<\/code>require<\/code>(:todo).permit(:name, :priority)<\/code><\/div>\n
end<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n\n\n\n

3. Slug it!<\/h2>\n\n\n\n

A slug is part of a URL that identifies a particular record in an easy-to-read form. Slugs are good because we don\u2019t have to reveal the id<\/code> of the record.<\/p>\n\n\n\n

I recommend using FriendlyId<\/a> as it\u2019s the \u201cSwiss Army bulldozer\u201d of slugging and permalink plugins for ActiveRecord.<\/p>\n\n\n\n

After implementing, we can change our show<\/code> methods to look like this:<\/p>\n\n\n\n

Todo.friendly.find(params[:id])<\/code><\/p>\n\n\n\n

params[:id]<\/code> \u2013 will contain the slug as we now use it as the id of the record.<\/p>\n\n\n\n

4. Use HTTPS<\/h2>\n\n\n\n

Protect sensitive data, especially logins or payment pages. These are easily sniffed when traffic is unencrypted since cookies are easily obtainable through cross-site scripting (XSS).<\/p>\n\n\n\n

In the application config file you will need to specify config.force_ssl = true<\/code>.<\/p>\n\n\n\n

Learn how to create an SSL certificate here<\/a>.<\/p>\n\n\n\n

5. Cross-Site Request Forgery (CSRF)<\/h2>\n\n\n\n

What is this?<\/strong><\/p>\n\n\n\n

The attack method of cross-site request forgery is the idea that someone can insert malicious code into the application and trick the server to think the user is authenticated. This could allow the attacker to execute unauthorized commands.<\/p>\n\n\n\n

How do I enable this?<\/strong><\/p>\n\n\n\n

Add protect_from_forgery with: :exception<\/code> in the application controller.<\/p>\n\n\n\n

You can rescue forgery if the request is invalid as follows:<\/p>\n\n\n\n

\n
\n\n\n\n
\n
1<\/div>\n
2<\/div>\n
3<\/div>\n<\/td>\n
\n
\n
rescue_from ActionController::InvalidAuthenticityToken <\/code>do<\/code> |exception|<\/code><\/div>\n
  <\/code>sign_out_user # Example method that will destroy the user cookies<\/code><\/div>\n
end<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n\n\n\n

6. Check for Active Record Exceptions<\/h2>\n\n\n\n

One good thing we did in the previous part<\/a> of the series was create an Exception Concern that sat on the top layer of the Application Controller to guard for specific application Active Record exceptions.<\/p>\n\n\n\n

The module below rescues these specific Active Record Exceptions:<\/p>\n\n\n\n

\n
\n\n\n\n
\n
01<\/div>\n
02<\/div>\n
03<\/div>\n
04<\/div>\n
05<\/div>\n
06<\/div>\n
07<\/div>\n
08<\/div>\n
09<\/div>\n
10<\/div>\n
11<\/div>\n
12<\/div>\n
13<\/div>\n<\/td>\n
\n
\n
module ExceptionHandler<\/code><\/div>\n
  <\/code>extend ActiveSupport::Concern<\/code><\/div>\n
 <\/div>\n
  <\/code>included <\/code>do<\/code><\/div>\n
    <\/code>rescue_from ActiveRecord::RecordNotFound <\/code>do<\/code> |e|<\/code><\/div>\n
      <\/code>render json: { message: e.message }, status: 404<\/code><\/div>\n
    <\/code>end<\/code><\/div>\n
 <\/div>\n
    <\/code>rescue_from ActiveRecord::RecordInvalid <\/code>do<\/code> |e|<\/code><\/div>\n
      <\/code>render json: { message: e.message }, status: 422<\/code><\/div>\n
    <\/code>end<\/code><\/div>\n
  <\/code>end<\/code><\/div>\n
end<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n\n\n\n

You can find more exceptions to guard for here<\/a>.<\/p>\n\n\n\n

Wrapping up the series<\/h2>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

You have done it! Time to pat yourself on the back as we have planned to build our application and have built a structured project using Ruby on Rails.<\/p>\n\n\n\n

In this series, the goal was to outline how to bolster your API with strong top layers of infrastructure and Postgres, dockerize your project and add security layers to mitigate attacks to your application.<\/p>\n\n\n\n

I wanted to thank everyone for reading this series and I hope you feel more confident as an engineer building a rails application!<\/p>\n\n\n\n

I hope outlined the other parts for you to (re)visit.<\/p>\n\n\n\n

Part One<\/a><\/p>\n\n\n\n

Part Two<\/a><\/p>\n\n\n\n

Part Three<\/a><\/p>\n\n\n\n

Additional resources<\/h2>\n\n\n\n