<div class="widget">
    <div class="widget-header">
      <div class="title">
        <span class="fs1" aria-hidden="true" data-icon="&#xe092;"></span> A1 - SQL Injection - ActiveRecord Scope
      </div>
    </div>
    <div class="widget-body">
      <div id="accordion1" class="accordion no-margin">
        <div class="accordion-group">
          <div class="accordion-heading">
            <a href="#collapseFive" data-parent="#accordion1" data-toggle="collapse" class="accordion-toggle">
              <i class="icon-info icon-white">
              </i>
              Description
            </a>
          </div>
          <div class="accordion-body in collapse" id="collapseFive" style="height: auto;">
            <div class="accordion-inner">
             <p class="desc">
        ActiveRecord provides a useful tool for it's Models called a <i>scope</i>. In the words of the documentation:
       </p>
       <pre><i>
"Scoping allows you to specify commonly-used queries which can be referenced as <br/>method calls on the association objects or models."
       </i></pre>
       <p class="desc">
        This means that we can call a scope as a method and that the scope can be used for common queries such as <i>where</i> and <i>join</i>. Developers must be careful not to interpolate or concatenate user input into these scope calls as this can lead to SQL Injection. This is a common mistake made and can have serious consequences.
       </p>
            </div>
          </div>
        </div>
        <div class="accordion-group">
          <div class="accordion-heading">
            <a href="#collapseSix" data-parent="#accordion1" data-toggle="collapse" class="accordion-toggle">
              <i class="icon-bug icon-white">
              </i>
              Bug
            </a>
          </div>
          <div class="accordion-body collapse" id="collapseSix" style="height: 0px;">
            <div class="accordion-inner">
        <p class="desc">
        Within app/models/analytics.rb:
        </p>
        <pre class="ruby">
        class Analytics < ActiveRecord::Base
          attr_accessible :ip_address, :referrer, :user_agent

          <span style="background-color:yellow">scope :hits_by_ip, ->(ip,col="*") { select("#{col}").where(:ip_address => ip).order("id DESC")}</span>

          def self.count_by_col(col)
            calculate(:count, col)
          end
        </pre>
       <p class="desc">
        Additionally, within app/controllers/admin_controller.rb:
       </p>
       <pre class="ruby">
        def analytics
          if params[:field].nil?
            fields = "*"
          else
            <span style="background-color:yellow">fields = params[:field].map {|k,v| k }.join(",")</span>
          end

          if params[:ip]
            <span style="background-color:yellow">@analytics = Analytics.hits_by_ip(params[:ip], fields)</span>
          else
            @analytics = Analytics.all
          end
          render "layouts/admin/_analytics"
        end
       </pre>
       <p class="desc">
        Within the controller we call the method <i>hits_by_ip</i>. This method is actually a scope as highlighted (above) in the Analytics model. The field object, defined within the controller, represents user-input that is intended to control the column returned by the SQL query. The field object represents the HTTP Request's parameter key. So this means we can control at least a portion of the query. Due to the fact that this input is used as an interpolated value within the query string, we have control over a larger portion of the query.
       </p>
            </div>
          </div>
        </div>
        <div class="accordion-group">
          <div class="accordion-heading">
            <a href="#collapseSeven" data-parent="#accordion1" data-toggle="collapse" class="accordion-toggle">
              <i class="icon-lightning icon-white">
              </i>
              Solution
            </a>
          </div>
          <div class="accordion-body collapse" id="collapseSeven" style="height: 0px;">
            <div class="accordion-inner">
               <p><b>SQL Injection - ATTACK</b></p>
         <p class="desc">
          Navigate to the admin analytics panel. Send a request to search by an IP. Modify the request to change the parameter key to a partial SQL statement that returns all users and their information from the database:
         </p>
         <pre>
        GET /admin/1/analytics?ip=127.0.0.1&field%5B*%20from%20users--%5D= HTTP/1.1
        Host: railsgoat.dev
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
        Accept-Language: en-US,en;q=0.5
        Accept-Encoding: gzip, deflate
        Cookie:[redacted]
        Connection: keep-alive
         </pre>
         <p class="desc">
        Essentially we are changing the intended SQL query from:
         </p>
         <pre>
        SELECT <span style="background-color:yellow">UserInput</span> FROM "analytics"  WHERE "analytics"."ip_address" = '127.0.0.1' ORDER BY id DESC
         </pre>
         <p class="desc">
        to:
         </p>
         <pre>
        SELECT * from users-- FROM "analytics" WHERE "analytics"."ip_address" = '127.0.0.1' ORDER BY id DESC
         </pre>
         <p><b>SQL Injection - SOLUTION</b></p>
         <p class="desc">
        To resolve this issue, do not interpolate user-provided input into SQL queries. However, it is always a good idea to create a whitelist of acceptable values when writing any code that is intended to be powerful and very flexible but that also leverages user-input to make these potentially security-impacting decisions. Within the Analytics model, we have a method called <i>parse_field</i>:
         </p>
         <pre class="ruby">
         def self.parse_field(field)
            valid_fields = ["ip_address", "referrer", "user_agent"]

            if valid_fields.include?(field)
              field
            else
              "1"
            end
         end
         </pre>
         <p class="desc">
        When used properly, this method prevents anything that does not match those items in the <i>valid_fields</i> array from reaching the SQL query. For example, within the admin controller we can prevent anything that does not match that white-list from inclusion into the query by doing the following:
         </p>
         <pre class="ruby">
          def analytics
            if params[:field].nil?
              fields = "*"
            else
             fields = params[:field].map {|k,v| <span style="background-color:yellow">Analytics.parse_field(k)</span> }.join(",")
            end

            if params[:ip]
              @analytics = Analytics.hits_by_ip(params[:ip], fields)
            else
              @analytics = Analytics.all
            end
            render "layouts/admin/_analytics"
          end
         </pre>
         <p class="desc">
        Effectively, we've changed any malicious data provided by the user into the number '1' by leveraging the above code.
         </p>
            </div>
          </div>
        </div>
      <div class="accordion-group">
          <div class="accordion-heading">
            <a  style="background-color: rgb(181, 121, 158)" href="#collapseEight" data-parent="#accordion1" data-toggle="collapse" class="accordion-toggle">
              <i class="icon-aid icon-white">
              </i>
              Hint
            </a>
          </div>
          <div class="accordion-body collapse" id="collapseEight" style="height: 0px;">
            <div class="accordion-inner">
              Administrative analytics functionality need further security analysis. Now might be a good time to test for SQLi.
            </div>
          </div>
        </div>
   </div>
    </div>
  </div>