What is XSS ?

In this attack, victim's browser may execute malicious scripts because browser trusts the source of the content even when it's not coming from the correct source.

Here is our blog on XSS written sometime back.

How CSP can be used to mitigate and report this attack ?

By using CSP, we can specify domains that are valid sources of executable scripts. Then a browser with CSP compatibility will only execute those scripts that are loaded from these whitelisted domains.

Please note that CSP makes XSS attack a lot harder but CSP does not make XSS attack impossible. CSP does not stop DOM-based XSS (also known as client-side XSS). To prevent DOM-based XSS, Javascript code should be carefully written to avoid introducing such vulnerabilities.

In Rails 5.2, a DSL was added for configuring Content Security Policy header.

Let's check the configuration.

We can define global policy for the project in an initializer.

# config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy do |policy|
policy.default_src :self, :https
policy.font_src :self, :https, :data
policy.img_src :self, :https, :data
policy.object_src :none
policy.script_src :self, :https
policy.style_src :self, :https, :unsafe_inline
policy.report_uri "/csp-violation-report-endpoint"
end

We can override global policy within a controller as well.

# Override policy inline

class PostsController < ApplicationController
content_security_policy do |policy|
policy.upgrade_insecure_requests true
end
end

# Using mixed static and dynamic values

class PostsController < ApplicationController
content_security_policy do |policy|
policy.base_uri :self, -> { "https://#{current_user.domain}.example.com" }
end
end

Content Security Policy can be deployed in report-only mode as well.

Here is global setting in an initializer.

# config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy_report_only = true

Here we are putting an override at controller level.

class PostsController < ApplicationController
content_security_policy_report_only only: :index
end

Policy specified in content_security_policy_report_only header will not be enforced, but any violations will be reported to a provided URI. We can provide this violation report URI in report_uri option.

# config/initializers/content_security_policy.rb

Rails.application.config.content_security_policy do |policy|
policy.report_uri "/csp-violation-report-endpoint"
end

If both content_security_policy_report_only and content_security_policy headers are present in the same response then policy specified in content_security_policy header will be enforced while content_security_policy_report_only policy will generate reports but will not be enforced.

class UsersController < ApplicationController
  def index
    User.order("#{params[:order]} ASC")
  end
end

Although this code is looking fine on the surface, we can see the issues looking at the example from rails-sqli.

pry(main)> params[:order] = "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)"

pry(main)> User.order("#{params[:order]} ASC")
User Load (1.0ms)  SELECT "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC
=> [#<User:0x00007fdb7968b508
  id: 1,
  email: "piyush@example.com",
  authentication_token: "Vkn5jpV_zxhqkNesyKSG">]

There are many Active Record methods which are vulnerable to SQL injection and some of these can be found here.

However, in Rails 5.2 these APIs are changed and they allow only attribute arguments and Rails does not allow raw SQL. With Rails 5.2 it is not mandatory but the developer would see a deprecation warning to remind about this.

irb(main):004:0> params[:order] = "email"
=> "email"
irb(main):005:0> User.order(params[:order])
  User Load (1.0ms)  SELECT  "users".* FROM "users" ORDER BY email LIMIT $1  [["LIMIT", 11]]
=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>

irb(main):008:0> params[:order] = "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)"
irb(main):008:0> User.order("#{params[:order]} ASC")
DEPRECATION WARNING: Dangerous query method (method whose arguments are used as raw SQL) called with non-attribute argument(s): "(CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END)". Non-attribute arguments will be disallowed in Rails 6.0. This method should not be called with user-provided values, such as request parameters or model attributes. Known-safe values can be passed by wrapping them in Arel.sql(). (called from irb_binding at (irb):8)
  User Load (1.2ms)  SELECT  "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC
=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>

In Rails 6, this will result into an error.

In Rails 5.2, if we want to run raw SQL without getting the above warning, we have to change raw SQL string literals to an Arel::Nodes::SqlLiteral object.

irb(main):003:0> Arel.sql('title')
=> "title"
irb(main):004:0> Arel.sql('title').class
=> Arel::Nodes::SqlLiteral

irb(main):006:0> User.order(Arel.sql("#{params[:order]} ASC"))
  User Load (1.2ms)  SELECT  "users".* FROM "users" ORDER BY (CASE SUBSTR(authentication_token, 1, 1) WHEN 'k' THEN 0 else 1 END) ASC
=> #<ActiveRecord::Relation [#<User id: 1, email: "piyush@example.com", authentication_token: "Vkn5jpV_zxhqkNesyKSG">]>

This should be done with care and should not be done with user input.

Here is relevant commit and discussion.

Rails has implemented caching using an abstract class ActiveSupport::Cache::Store which defines the interface that all cache store classes should implement. Rails also provides few common functionality that all cache store classes will need.

Prior to Rails 5.2 ActiveSupport::Cache::Store didn't have any method to set multiple entities at once.

In Rails 5.2, write_multi was added . Each cache store can implement this method and provide the functionality to add multiple entries at once. If cache store does not implement this method, then the default implementation is to loop over each key value pair and sets it individually using write_entity method.

Multiple entities can be set as shown here.

Rails.cache.write_multi name: 'Alan Turning', country: 'England'

redis-rails gem provides redis as cache store. However it does not implement write_multi method.

However if we are using Rails 5.2, then there is no point in using redis-rails gem, as Rails 5.2 comes with built in support for redis cache store, which implements write_multi method. It was added by this PR.

We need to make following change.

# before
config.cache_store = :redis_store

# after
config.cache_store = :redis_cache_store

redis-rails repo has a pull request to notify users that development of this gem is ceased. So it's better to use redis cache store that comes with Rails 5.2.

It was proposed to use AES-256-GCM authenticated encryption as the default cipher for encrypting messages because of following reasons:

• It produces shorter ciphertexts and performs quick encryption and decryption.
• It is less error prone and more secure.

So, AES-256-GCM became default cipher for encrypting messages in Rails 5.2 .

If we do not want AES-256-GCM as default cipher for encrypting messages in our rails application, then we can disable it.

Rails.application.config.active_support.use_authenticated_message_encryption = false

Default Encryption for cookies and sessions was also updated to use AES-256-GCM in this pull request.

If we do not want AES-256-GCM as default encryption of cookies and sessions, then we can disable it too.

Rails.application.config.active_support.use_authenticated_cookie_encryption = false

Now consider the following scenario.

In one of the searches on google.com, we see a link to bigbinary.com. On clicking the link, we are navigated to bigbinary.com.

When somebody gets redirected to bigbinary.com from google.com, the HTTP REFERRER is set to google.com

If bigbinary.com uses redirect_back in its code then the user will get redirected to google.com which might be undesired behavior for some applications.

To avoid such cases, Rails 5.2 has added a flag allow_other_host to not allow redirecting to a different host other than the current site.

By default, allow_other_host option is set to true. So if you do not want users to go back to google.com then you need to explicitly set allow_other_host: false.

> request.host
#=> "http://www.bigbinary.com"

> request.headers["Referrer"]
#=> "http://www.google.com"

# This will redirect back to google.com
redirect_back(fallback_path: "/")

# This will not redirect back to google.com
redirect_back(fallback_path: "/", allow_other_host: false)

However these methods broke query caching of ActiveRecord::FinderMethods#exists? method. Let's check the issue.

>> User.cache do
>>   2.times { User.exists?(1) }
>> end

User Exists (2.1ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

User Exists (2ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

As we can see, query was not cached and sql was executed second time.

From Rails 5.2, MySQL and PostgreSQL adapters are no longer override select_{value,values,rows} methods which fix this query caching issue.

Also, the performance improvement provided by these methods was marginal and not a hotspot in Active Record, so this change was accepted.

Let's check query caching of ActiveRecord::FinderMethods#exists? after the change.

>> User.cache do
>>   2.times { User.exists?(1) }
>> end

User Exists (2.1ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

CACHE User Exists (0.0ms)  SELECT  1 AS one FROM "users" WHERE "users"."id" = $1 LIMIT $2  [["id", 1], ["LIMIT", 1]]

Now, query has been cached as expected.

This change has been backported in rails 5.1 from version 5.1.2 as well.

One other case that Rails developers have to take care of is ensuring that the Ruby version used to run Rails by the deployment tools is the one that is desired. In order to ensure that we add ruby version to Gemfile. This will help bundler install dependencies scoped to the specified Ruby version.

Good News! Rails 5.2 makes our work easy.

In Rails 5.2, changes have been made to introduce .ruby-version file and also add the Ruby version to Gemfile by default after creating an app.

Let's create a new project with Ruby 2.5 .

$ rvm list default

  Default Ruby (for new shells)

     ruby-2.5 [ x86_64 ]


$ rails new my_new_app

In our new project, we should be able to see .ruby-version in its root directory and it will contain value 2.5. Also, we should see following line in the Gemfile.

ruby "2.5"

Assume that current date is Tue, 27 Feb 2018.

# find previous thursday
>> Date.yesterday.beginning_of_week(:thursday)
=> Thu, 22 Feb 2018

# find next thursday
>> Date.tomorrow.end_of_week(:friday)
=> Thu, 01 Mar 2018

Rails 5.2 has introduced methods Date#prev_occurring and Date#next_occurring to find next & previous occurring day of the week.

# find previous thursday
>> Date.prev_occurring(:thursday)
=> Thu, 22 Feb 2018

# find next thursday
>> Date.next_occurring(:thursday)
=> Thu, 01 Mar 2018

To have consistent and symmetrical behaviour across all the attribute extensions, it was decided to support specifying a default value using default option for all the module and class attribute macros as well.

mattr_accessor, mattr_reader and mattr_writer macros generate getter and setter methods at the module level.

Similarly, cattr_accessor, cattr_reader, and cattr_writer macros generate getter and setter methods at the class level.

Before Rails 5.2

Before Rails 5.2, this is how we would set the default values for the module and class attribute accessor macros.

module ActivityLoggerHelper
  mattr_accessor :colorize_logs
  mattr_writer :log_ip { false }

  self.colorize_logs = true
end

class ActivityLogger
  include ActivityLoggerHelper

  cattr_writer :logger { Logger.new(STDOUT) }
  cattr_accessor :level
  cattr_accessor :settings
  cattr_reader :pid { Process.pid }

  @@level = Logger::DEBUG
  self.settings = {}
end

After Rails 5.2

We can still set a default value of a module or class attribute accessor by providing a block. In this pull request, support for specifying a default value using a new default option has been introduced.

So instead of

cattr_writer :logger { Logger.new(STDOUT) }

or

cattr_writer :logger
self.logger = Logger.new(STDOUT)

or

cattr_writer :logger
@@logger = Logger.new(STDOUT)

we can now easily write

cattr_writer :logger, default: Logger.new(STDOUT)

Same applies to the other attribute accessor macros like mattr_accessor, mattr_reader, mattr_writer, cattr_accessor, and cattr_reader.

Note that, the old way of specifying a default value using the block syntax will work but will not be documented anywhere.

Also, note that if we try to set the default value by both ways i.e. by providing a block as well as by specifying a default option; the value provided by default option will always take the precedence.

mattr_accessor(:colorize_logs, default: true) { false }

Here, @@colorize_logs would be set with true as per the above precedence rule.

Here is a test which verifies this behavior.

Finally, here is simplified version using the new default option.

module ActivityLoggerHelper
  mattr_accessor :colorize_logs, default: true
  mattr_writer :log_ip, default: false
end

class ActivityLogger
  include ActivityLoggerHelper

  cattr_writer :logger, default: Logger.new(STDOUT)
  cattr_accessor :level, default: Logger::DEBUG
  cattr_accessor :settings, default: {}
  cattr_reader :pid, default: Process.pid
end

Before Rails 5.2, to specify a default value for a class_attribute, we needed to write like this.

class ActivityLogger
class_attribute :logger
class_attribute :settings

self.logger = Logger.new(STDOUT)
self.settings = {}
end

As we can see above, it requires additional keystrokes to set a default value for each class_attribute.

Rails 5.2 has added support for specifying a default value for a class_attribute using default option.

class ActivityLogger
class_attribute :logger, default: Logger.new(STDOUT)
class_attribute :settings, default: {}
end

This enhancement was introduced in this pull request.

Notifier.welcome(User.first).deliver_later

It uses ActionMailer::DeliveryJob as the default job class to send emails. This class is defined internally by Rails.

The DeliveryJob defines handle_exception_with_mailer_class method to handle exception and to do some housekeeping work.

def handle_exception_with_mailer_class(exception)
  if klass = mailer_class
    klass.handle_exception exception
  else
    raise exception
  end
end

One might need more control on the job class to retry the job under certain conditions or add more logging around exceptions.

Before Rails 5.2, it was not possible to use a custom job class for this purpose.

Rails 5.2 has added a feature to configure the job class per mailer.

class CustomNotifier < ApplicationMailer
  self.delivery_job = CustomNotifierDeliveryJob
end

By default, Rails will use the internal DeliveryJob class if the delivery_job configuration is not present in the mailer class.

Now, Rails will use CustomNotifierDeliveryJob for sending emails for CustomNotifier mailer.

CustomNotifier.welcome(User.first).deliver_later

As mentioned above CustomNotifierDeliveryJob can be further configured for logging, exception handling and reporting.

By default, deliver_later will pass following arguments to the perform method of the CustomNotifierDeliveryJob.

• mailer class name
• mailer method name
• mail delivery method
• original arguments with which the mail is to be sent

class CustomNotifierDeliveryJob < ApplicationJob

  rescue_from StandardError, with: :handle_exception_with_mailer_class

  retry_on CustomNotifierException

  discard_on ActiveJob::DeserializationError

  def perform(mailer, mail_method, delivery_method, *args)
    logger.log "Mail delivery started"
    klass = mailer.constantize
    klass.public_send(mail_method, *args).send(delivery_method)
    logger.log "Mail delivery completed"
  end

  def handle_exception_with_mailer_class(exception)
    if klass = mailer_class
      klass.handle_exception exception
    else
      raise exception
    end
  end
end

We can also simply inherit from the ActionMailer::DeliveryJob and override the retry logic.

class CustomNotifierDeliveryJob < ActionMailer::DeliveryJob
  retry_on CustomNotifierException
end

Rails allows us to create index on a database column by means of a migration. By default, the sort order for the index is ascending.

But consider the case where we are fetching reports from the database. And while querying the database, we always want to get the latest report. In this case, it is efficient to specify the sort order for the index to be descending.

We can specify the sort order by adding an index to the required column by adding a migration .

add_index :reports, [:user_id, :name], order: { user_id: :asc, name: :desc }

PostgreSQL

If our Rails application is using postgres database, after running the above migration we can verify that the sort order was added in schema.rb

create_table "reports", force: :cascade do |t|
  t.string "name"
  t.integer "user_id"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name", order: { name: :desc }
end

Here, the index for name has sort order in descending. Since the default is ascending, the sort order for user_id is not specified in schema.rb.

MySQL < 8.0.1

For MySQL < 8.0.1, running the above migration, would generate the following schema.rb

create_table "reports", force: :cascade do |t|
  t.string "name"
  t.integer "user_id"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name"
end

As we can see, although the migration runs successfully, it ignores the sort order and the default ascending order is added.

Rails 5.2 and MySQL > 8.0.1

MySQL 8.0.1 added support for descending indices.

Rails community was quick to integrate it as well. So now in Rails 5.2, we can add descending indexes for MySQL databases.

Running the above migration would lead to the same output in schema.rb file as that of the postgres one.

create_table "reports", force: :cascade do |t|
  t.string "name"
  t.integer "user_id"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
  t.index ["user_id", "name"], name: "index_reports_on_user_id_and_name", order: { name: :desc }
end

A preview mailer can be setup as shown here.

class NotificationMailer < ApplicationMailer
def notify(email: email, body: body)
user = User.find_by(email: email)
mail(to: user.email, body: body)
end
end

class NotificationMailerPreview < ActionMailer::Preview
def notify
NotificationMailer.notify(email: User.first.email, body: "Hi there!")
end
end

This will work as expected. But our email template is displayed differently based on user's role. To test this, we need to update the notify method and then check the updated preview.

What if we could just pass the email in the preview URL.

http://localhost:3000/rails/mailers/notification/notify?email=superadmin@example.com

In Rails 5.2, we can pass the params directly in the URL and params will be available to the preview mailers.

Our code can be changed as follows to use the params.

class NotificationMailerPreview < ActionMailer::Preview
def notify
email = params[:email] || User.first.email
NotificationMailer.notify(email: email, body: "Hi there!")
end
end

This allows us to test our mailers with dynamic input as per requirements.

If we generate a new Rails app using Rails 5.2, we will see bootsnap gem in the Gemfile. bootsnap helps in reducing the boot time of the app by caching expensive computations.

In a new Rails 5.2 app, boot.rb will contain following content:

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)

require 'bundler/setup' # Set up gems listed in the Gemfile.
require 'bootsnap/setup' # Speed up boot time by caching expensive operations.

if %w[s server c console].any? { |a| ARGV.include?(a) }
  puts "=> Booting Rails"
end

This sets up bootsnap to start in all environments. We can toggle it per environment as required.

This works out of the box and we don't have do to anything for the new app.

If we are upgrading an older app which already has bootsnap, then we need to make sure that we are using bootsnap >= 1.1.0 because new Rails apps ship with that version constraint.

If the app doesn't contain the bootsnap gem already then we will need to add it manually since rails app:update task adds the bootsnap/setup line to boot.rb regardless of its presence in the Gemfile.

By using fetch_values we are able to get values for multiple keys in a hash.

capitals = { usa: "Washington DC",
             china: "Beijing",
             india: "New Delhi",
             australia: "Canberra" }

capitals.fetch_values(:usa, :india)
#=> ["Washington DC", "New Delhi"]

capitals.fetch_values(:usa, :spain) { |country| "N/A" }
#=> ["Washington DC", "N/A"]

Rails 5.2 introduces method fetch_values on HashWithIndifferentAccess. We'll hence be able to fetch values of multiple keys on any instance of HashWithIndifferentAccess class.

capitals = HashWithIndifferentAccess.new
capitals[:usa] = "Washington DC"
capitals[:china] = "Beijing"

capitals.fetch_values("usa", "china")
#=> ["Washington DC", "Beijing"]

capitals.fetch_values("usa", "spain") { |country| "N/A" }
#=> ["Washington DC", "N/A"]

cookies[:username] = {value: "sam_smith", expires: Time.now + 4.hours}

The above code sets cookie which expires in 4 hours.

The expires option, is not supported for signed and encrypted cookies. In other words we are not able to decide on server side when an encrypted or signed cookie would expire.

From Rails 5.2, we'll be able to set expiry for encrypted and signed cookies as well.

cookies.encrypted[:firstname] = { value: "Sam", expires: Time.now + 1.day }

# sets string `Sam` in an encrypted `firstname` cookie for 1 day.

cookies.signed[:lastname] = {value: "Smith", expires: Time.now + 1.hour }

# sets string `Smith` in a signed `lastname` cookie for 1 hour.

Apart from this, in Rails 5.1, we needed to provide an absolute date/time value for expires option.

# setting cookie for 90 minutes from current time.

cookies[:username] = {value: "Sam", expires: Time.now + 90.minutes}

Starting Rails 5.2, we'll be able to set the expires option by giving a relative duration as value.

# setting cookie for 90 minutes from current time.

cookies[:username] = { value: "Sam", expires: 90.minutes }

# After 1 hour

> cookies[:username]
> #=> "Sam"

# After 2 hours

> cookies[:username]
> #=> nil
> ~~~