Challenge 2: Strong Parameters and a Mass Assignment Attack — Solution

class ProductsController < ApplicationController
  private

  def product_params
    params.require(:product).permit(:name, :description, :price)
  end
end

# What a malicious submission would need to include:
# An attacker (using browser dev tools to edit the form's HTML, or
# bypassing the form entirely with a crafted HTTP request) would need to
# add an extra field to the submitted data, such as
# product[featured]=true, hoping that value reaches Product.new or
# product.update directly.
#
# Why product_params as written stops it:
# .permit(:name, :description, :price) explicitly whitelists only those
# three keys. Even if product[featured]=true is present anywhere in the
# raw submitted params, it is silently filtered out and never appears in
# the hash product_params actually returns -- Product.new(product_params)
# or product.update(product_params) never even sees a featured value at
# all, regardless of what was submitted.

=begin
Notes:
- The vulnerability this challenge describes only exists if a controller
  ever uses the unfiltered params[:product] directly instead of the
  permitted product_params -- strong parameters are a discipline the
  controller code must actually follow, not something Active Record
  enforces on its own.
- This mirrors the SQL injection lesson from Chapter 5: the framework
  provides the safe tool (permit here, parameterized queries there), but
  it's still possible to bypass it by not using that tool correctly.
=end