Insecure Direct Object References (IDOR) in Rails: Proper Authorization Checks

Insecure Direct Object References, or IDOR, is a common web application vulnerability that can lead to unauthorized access to data. In Ruby on Rails applications, where convention over configuration is key, it’s crucial to be vigilant about how objects are exposed to users. This post will explore what IDOR is, how it can manifest in a Rails application, and how to prevent it with proper authorization checks.

What is an Insecure Direct Object Reference (IDOR)?

Imagine you have a key to your apartment, number 101. This key should only open your door. An IDOR vulnerability is like having a magical key that can be slightly changed to open apartment 102, 103, and so on, just by changing the number on the key.

In a web application, an IDOR occurs when the application uses a user-supplied identifier (like a record ID from the URL) to access an object directly, without verifying that the user is authorized to access that specific object.

For example, if a user can view their invoice at /invoices/123, an attacker might try changing the URL to /invoices/124 to see if they can view someone else’s invoice. If the application doesn’t check who owns invoice 124, it’s vulnerable to IDOR.

A Vulnerable Rails Example

Let’s look at a typical Rails controller that might be vulnerable to IDOR.

class InvoicesController < ApplicationController
  before_action :authenticate_user!

  def show
    @invoice = Invoice.find(params[:id])
  end
end

In this example, the authenticate_user! before_action (common with the Devise gem) ensures that only logged-in users can access the show action. However, it doesn’t check if the logged-in user is the owner of the invoice they are trying to view.

So, if User A has an invoice with id=1, they can view it at /invoices/1. But if User B has an invoice with id=2, User A could potentially access it by navigating to /invoices/2. The Invoice.find(params[:id]) call will happily fetch any invoice from the database as long as its ID exists.

Fixing the IDOR Vulnerability

The key to preventing IDOR is to always authorize access to objects based on the current user’s permissions.

In our InvoicesController, we should scope the invoice lookup to the current user’s invoices. Assuming a User has many invoices, we can do this:

class InvoicesController < ApplicationController
  before_action :authenticate_user!

  def show
    @invoice = current_user.invoices.find(params[:id])
  end
end

Now, when current_user.invoices.find(params[:id]) is called, Rails will execute a SQL query similar to this:

SELECT "invoices".* FROM "invoices" WHERE "invoices"."user_id" = ? AND "invoices"."id" = ? LIMIT 1

The user_id will be the ID of the currently logged-in user. If an attacker tries to access an invoice that doesn’t belong to them, find will raise an ActiveRecord::RecordNotFound exception, and they will get a 404 Not Found error, which is the correct behavior.

Other Mitigation Strategies

While scoping your queries is the most direct way to fix IDOR vulnerabilities, here are some other strategies and best practices:

1. Use Authorization Gems

Gems like Pundit and CanCanCan provide a more structured way to handle authorization logic.

With Pundit, you would create a policy class for your model:

# app/policies/invoice_policy.rb
class InvoicePolicy < ApplicationPolicy
  def show?
    record.user == user
  end
end

And in your controller:

# app/controllers/invoices_controller.rb
class InvoicesController < ApplicationController
  before_action :authenticate_user!

  def show
    @invoice = Invoice.find(params[:id])
    authorize @invoice
  end
end

The authorize @invoice call will use the InvoicePolicy to check if the current_user is allowed to see the @invoice. If not, it will raise an exception.

2. Use Non-Guessable Identifiers (UUIDs)

Instead of using sequential integer IDs in your URLs, consider using UUIDs (Universally Unique Identifiers).

You can generate UUIDs for your models in your migrations:

create_table :invoices, id: :uuid do |t|
  # ...
end

A URL with a UUID would look like this: /invoices/123e4567-e89b-12d3-a456-426614174000.

While this makes it much harder for an attacker to guess other object IDs, it’s important to remember that UUIDs are not a substitute for proper authorization checks. They are a form of security through obscurity. If an attacker manages to get ahold of another user’s UUID, they can still access it if you don’t have authorization in place.

Conclusion

Insecure Direct Object References can create serious data leaks in your Rails application. The most effective way to prevent them is to always verify that the current user is authorized to access the requested resources.

Key takeaways:

• Always scope your queries: Use associations like current_user.invoices to ensure users can only access their own data.
• Use authorization gems: Pundit or CanCanCan can help you organize your authorization logic.
• Consider UUIDs: They make it harder to guess object IDs but are not a replacement for authorization.

By implementing these practices, you can build more secure and robust Rails applications.