From Rails Security
to Application Security

Steffen Bartsch, Carsten Bormann

{sbartsch,cabo}@tzi.org

Overview

What Goes Wrong?

Historic Vulnerabilities

SSL: MITM attack on cipher suites which are not authenticated; Rails: fixed in 1.2.4, 1.2.5; URL Session ids; JSON XSS: faulty escaping for JSON; http://directwebremoting.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html Thus: Monitor your app stack for relevant security announcements

How About App Security in Rails?

Focus of This Talk:
App-specific Security

How do we do that? Systematically? Security Engineering!

Classical
Security Engineering

As known from Software Engineering

For Example: A Conference Web App

just a few functional requirements

Security Objectives

Non-functional Requirements from business owner; Any quantifications? (how many 9s?)

Overall Architecture


identify threats according to app architecture

Threat Matrix


                       Guests     Attendee   Competitor    Session hosts        Developers         Admin               Non-human
 Application           Vandalism             Sabotage                           Backdoors          Misconfiguration    Software bug
 Web Framework         Remote vul            DoS                                                   Misconfiguration    Software bug
 Application Server    DoS                   DoS                                                   Misconfiguration    Software bug
 Database              Remote vul                                                                  Misconfiguration    Software bug
 Operating System      Remote vul            Bribe                                                 Misconfiguration    Software bug
 File system                                                                                       Misconfiguration    Software bug
 Hardware                                    Bribe                                                 Misconfiguration    Hardware defect
                                                                                                   Human error
 Data center                                 Bribe                                                 Misconfiguration    Natural disaster
                                             Physical defense failure                                                  AC failure
 Network Infrastructure                                                                                                Routing failure
Problem: consistency in actors, areas, attack vectors

Attack Tree

Threats to availability only! Problem: scope? what to cover? Where to stop? Get an idea of how diverse attacks can be; see also: http://www.schneier.com/paper-attacktrees-ddj-ft.html

Attack Tree

Risk = Damage * Probability

Damage, Probability: e.g. Magnitudes; Probability, Losses: High, Medium, Low

Risk Assessment

consider vulnerabliities

Risk Assessment

App integrity; propagation: helps on AND edges (social engineering) Problem: Damage, Probability, Risk are dependent on lots of attributes such as security measures (e.g. User error: complexity? usability, undo?);

Application Security Policy

Application side; countermeasures

Design Time vs.
Agile Development


Agile Security Engineering?

  • Missed anything?
  • Security aspect? Completeness?
  • Scope/mission creep
  • Next iteration: Conference workflow
  • Change in functional requirement: unpublished, unannounced conference
  • Also: Process Confabulation
  • Parts of threat analysis and risk assessment resuable
Testing! Problem: how to integrate non-functional reqs in test?

In Rails Apps:
Authentication &
Authorization

Authentication Plugins

Authorization Plugins

MCVPriv.ContextComplexity
acl_system2xxsimple
authorizationxxxmedium
RESTful_ACLxxxxsimple
ActiveACLxxxhigh
Lots and lots; Categories
  • Model/View/Controller: location of restrictions
  • Privilege concept; Context constraints
  • Complexity

Authorization Plugins


class ConferenceController < ApplicationController
  access_control :DEFAULT => [:admin],
    [:index, :show]  => [...],
    [:edit, :update] => [:admin, :conference_organizer]
end

cond = permit?([:admin, :conference_organizer]) ? 
           {} : {:published => true}
Conference.find(:all, :conditions => cond)


<% restrict_to [:admin, :conference_organizer] do %>
  <%= link_to 'Edit', edit_conference_path(conference) %>
<% end %>
Programmatic authorization rule definition: not DRY; Rules repeating through-out code; Evolution of security policies? E.g.: no more editing of conferences through conference organizers Not even object-specific? Dynamic?

declarative_
authorization

Declarative Authorization


class ConferencesController < ApplicationController
  filter_access_to :all

  def index
    @conferences = Conference.with_permissions_to(:read)
  end
end


<%= link_to 'Edit', edit_conference_path(conference)
            if permitted_to? :edit, conference %>
  • Restrictions through privileges and context; privileges may be CRUD actions
  • query rewriting, controller filter, view restrictions
  • constraint vs. authorization check
  • Takes context object into account and checks attributes
  • There's more: Model security

Defense In Depth


class Conference
  using_access_control
end


begin
  Conference.create(params[:conference])
rescue Authorization::NotAuthorized
  # handle failed authorization check
end
Raises exception if not allowed according to rules

Authorization Rules: DSL


role :guest do
  has_permission_on :conferences, :to => :read
end

role :attendee do
  includes :guest
end

role :conference_organizer do
  has_permission_on :conferences, :to => :manage
end
  • Authorization rules in one place written in a DSL
  • Readable, extendable for domain experts
  • end-user development

Authorization Data Model



 ----- App domain ----|-------- Authorization conf ---------|------- App domain ------


                       includes                   includes
                        .--.                        .---.
                        |  v                        |   v
  .------.  can_play  .------.  has_permission  .------------.  requires  .----------.
  | User |----------->| Role |----------------->| Permission |<-----------| Activity |
  '------' *        * '------' *              * '------------' 1        * '----------'
                                                      |
                                              .-------+------.
                                           1 /        | 1     \ *
                                 .-----------.   .---------.  .-------------.
                                 | Privilege |   | Context |  | Constraints |
                                 '-----------'   '---------'  '-------------'
Marked in red: concepts provided by the plugin; Constraints: what happens when we'd like to allow access based on attributes of an instance of the context: describe which one it applies to

Attribute Constraints


role :attendee do
  includes :guest
  has_permission_on :conference_attendees, 
                    :to => :delete do
    if_attribute :attendee => is { user }
  end
end
aka. Authorization Constraints; context constraint; needs structure to enable query rewriting etc.

Attribute Constraints


role :attendee do
  includes :guest
  has_permission_on :conference_attendees, 
                    :to => :delete do
    if_attribute :attendee => is { user }
  end

  has_permission_on :talk_attendees, :to => :create do
    if_attribute :talk => {
                   :conference => {
                     :attendees => contains {user} }}
  end
end
conditions may be nested; OR-combination of multiple condition statements; AND in one statement Not the Panacea, though: Scope: Authorization for non-trivial cases

Demo

Short: Showing login with different roles; Unpublished one to be seen by everyone Integrate Conference workflow: - guests, attendees seeing only published conferences; Security check page: Dotty-Graph; Display Rules (syntax highlighting, simplified); XACML-Export - auth rules helpful way of communicating with business owner

Outlook

Self-service Authorization



role :secretary do
  has_permission_on :projects, :to => :read
  may_extend_to :project_manager
end
Flexibility, especially needed in SME if authorization is introduced as part of a enterprise web application for the first time, hindering familiar and efficient workflows; Integrity and availability often with higher priority than confidentiality; Needs specific measures
  • Monitoring
  • Non-destructing actions
  • Transactions and Undo

agile security engineering - declarative_authorization to the help with a declarative, dry approach and context constraints; not the silver bullet, for simplest cases might be unnecessary; still for enterprise applications a helpful way to communicate with the business owner. Check it out, fork it at github and tell us what you think about it.