Identification Failures in Hanami

Identification failures in Hanami applications typically occur when the framework's routing and parameter handling mechanisms are exploited to access resources without proper authorization. These vulnerabilities often stem from predictable ID generation, insufficient validation, or improper handling of request parameters.

In Hanami, the most common identification failure pattern involves accessing records through predictable IDs in RESTful routes. Consider a typical Hanami controller action:

module Web::Controllers::Users::Show
  include Web::Action

  def call(params)
    user = UserRepository.new.find(params[:id])
    self.body = { user: user }
  end
end

This code appears secure but suffers from identification failure because it trusts the params[:id] value without validation. An attacker can enumerate through sequential IDs to access user records they shouldn't see. The issue is compounded when Hanami's auto-serialization converts database records to JSON without filtering sensitive fields.

Another Hanami-specific manifestation occurs in the framework's form handling. When using Hanami's form helpers, developers might inadvertently expose ID fields:

<%= form_for :user, action: routes.users_path do |f| %>
  <%= f.hidden_field :id %>
  <%= f.text_field :name %>
  <%= f.submit %>
<% end %>

If the form processing action doesn't validate that the submitted ID belongs to the current user, attackers can modify the hidden field to manipulate other users' records.

Hanami's entity system can also introduce identification failures through improper entity initialization. When entities are constructed with untrusted parameters:

user = User.new(params[:user])
user.save

An attacker can include unexpected ID parameters in the payload, potentially overwriting existing records or accessing unauthorized resources.

Detecting identification failures in Hanami requires examining both the routing layer and controller implementations. The framework's explicit routing syntax makes it easier to identify vulnerable patterns:

root to: 'home#index'
get '/users/:id', to: 'users#show'
put '/users/:id', to: 'users#update'

Vulnerable routes are those that expose resource IDs without authentication or authorization checks. A security scan should flag any route that accepts an ID parameter and doesn't verify the requester's permissions.

middleBrick's Hanami-specific detection identifies identification failures through several mechanisms. The scanner analyzes the runtime behavior of API endpoints, attempting to access resources using predictable ID patterns. For Hanami applications, it specifically tests:

• Sequential ID enumeration to detect IDOR (Insecure Direct Object Reference) vulnerabilities
• Parameter manipulation in form submissions to test for BOLA (Broken Object Level Authorization)
• Entity deserialization with malicious ID values
• Cross-user data access through predictable identifiers

The scanner also examines Hanami's configuration files for security-related settings. For instance, it checks if database IDs are sequential integers or if UUIDs are used, which provides better protection against enumeration attacks.

Using middleBrick's CLI for Hanami applications:

npx middlebrick scan https://api.yourapp.com --framework hanami

The framework flag helps middleBrick apply Hanami-specific detection patterns, including analysis of Hanami's entity and repository patterns that might introduce identification vulnerabilities.

Remediating identification failures in Hanami requires leveraging the framework's built-in security features and following best practices for authorization. The first line of defense is implementing proper authorization checks in controllers:

module Web::Controllers::Users::Show
  include Web::Action

  def call(params)
    user = UserRepository.new.find(params[:id])
    
    if user.nil? || user.id != current_user.id
      halt 403, 'Forbidden'
    end

    self.body = { user: user }
  end
end

This pattern ensures users can only access their own resources. For more complex authorization scenarios, Hanami's policy system provides a structured approach:

class UserPolicy
  def initialize(current_user, target_user)
    @current_user = current_user
    @target_user = target_user
  end

  def show?
    @current_user.admin? || @current_user.id == @target_user.id
  end
end

Then in the controller:

module Web::Controllers::Users::Show
  include Web::Action

  def call(params)
    user = UserRepository.new.find(params[:id])
    policy = UserPolicy.new(current_user, user)

    if policy.show?
      self.body = { user: user }
    else
      halt 403, 'Forbidden'
    end
  end
end

Hanami's entity system can be hardened against identification failures by using UUIDs instead of sequential IDs. In your entity definition:

class User < Hanami::Entity
  attributes do
    attribute :id, Types::UUID
    attribute :name, Types::String
    attribute :email, Types::String
  end
end

Configure your database migration accordingly:

Hanami::Model.migration do
  change do
    create_table :users do
      primary_key :id, :uuid, default: 'gen_random_uuid()'
      column :name, :text, null: false
      column :email, :text, null: false
    end
  end
end

For form handling, always validate that submitted IDs match the authenticated user's context:

module Web::Controllers::Users::Update
  include Web::Action

  def call(params)
    user = UserRepository.new.find(params[:id])
    
    if user.id != current_user.id
      halt 403, 'Forbidden'
    end

    user.update(params[:user])
    user.save
    self.body = { user: user }
  end
end

Finally, implement comprehensive logging to detect identification failure attempts:

Hanami::Model::Sqlite.configure do
  schema 'db/schema.sql'
  migrations 'db/migrations'
  
  logger Hanami::Logger.new('db', level: :warn)
end