O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Ruby on Rails
Building and Breaking Rails App
• Released to the world as ‘extracted’ from BaseCamp
(37Signals) by @dhh during July 2004.
• Merged with Merb Project during December 2008 and Rails
3.0 was released.
• Two supported branch of development currently:
– Rails 3.x
– Rails 4.x
RoR: Web Blog Example
Our Blog is a web application where one or more Users
can self-register and sign-in using their registered
Upon sign-in each User should be able to publish Blog
Post that is visible to any user or visitor of the portal.
Any User or Visitor of the portal should optionally
Comment on any Blog Post.
Learning Ruby on Rails
• Ruby on Rails Official Guide
• Agile Web Development with Rails
• Ruby on Rails Podcasts
• Rails Code School
• Rails Cast
Breaking Ruby on Rails Applications
Image (Karate) by Nicholas Riggle from The Noun Project CC By 2.0
Penetration Testing Rails App
• Black/Gray Box Approach
– Conventional Testing
– Fingerprinting Rails Framework
– Rails specific Vulnerability Testing
– Rails specific Weakness Testing
• White Box Approach
– Automated Scan for known Vulnerabilities
– Attack Surface enumeration through Routes
– Authentication & Authorization Testing
– Common Rails information disclosures (secret_token.rb)
– Model Attributes Security
– Custom/Unconventional SQL Queries Audit
– Responsive View Audit
Fingerprinting Rails Applications
• No generic and definitive technique!
– It’s a cat & mouse game really.
– Session Identifier
– Asset Pipeline
– [ … ]
Fingerprinting Rails Application
Not so easy for an application served with a reverse
proxy which is almost always the case in production.
Fingerprinting Rails Application
Leveraging the assets pipeline which is enabled by default from Rails 3.1
Automated Testing: Brakeman
Need source code access !
Automated Testing: grep(1)
You will be surprised to see how effective this is !
Attack Surface: Routes
• Default Routing
– <Resource> is handled by app/controllers/<resources>_controller.rb
– CRUD on Resource
• A whole set of attacks are possible on Session
Management functionality of any Web
– Session Hijack, Session Fixation, Session Id Prediction, Session
Data Tampering, Leveraging Session Data for RCE etc.
• Rails provide inbuilt Session Management
– The session object is available to application
developer as a Hash/Map to store arbitrary data.
– The session object is serialized and stored in
corresponding session storage as per configuration.
– Signed cookie is used for session storage by default.
Not a Good idea !
Session Security: Best Practices
Enforce SSL in order to avoid sniffing of session id
Re-generate session after authentication to avoid session fixation
Store session in database instead of Cookie which is default
Cookie based Session Store are susceptible to Replay Attacks
• Multiple Popular Authentication Plugin
– RESTful Authentication
– Auto-generated Registration, Confirmation, Login,
Forgot Password etc.
– Controller filter for enforcing authentication.
• Generic Issues
– Weak Session Management
– Weak Authentication Enforcement
– Weak Password Encryption
• Plugin/Gem Specific
– Devise Vulnerabilities
– Lack of Authentication Enforcement
– Timing Attacks
– Information Gathering through default message
Are all controllers protected by Authentication System?
• Not provided by default in the framework.
– Encourages RESTful design.
• Easy to implement RBAC on Resources
– Multiple Gem/Plugin available
Example usage of CanCan for Authorization
• Authorization Plugin or Custom Coded?
• Every functionality is RESTful?
• Query scoping in Controller
Rails CSRF Protection
CSRF Token generation and checking is enforced by default.
• Application must use Rails Form Tag Helps to
generate forms rather than HTML directly.
• HTTP GET is not protected !
Rails Model Security
• The Business Logic Layer
– Database Abstraction through ORM
– Entity Relationship Definition
– Business Logic
• Common Security Issues
– Attribute Mass Assignment
• Mitigated by default in newer version of Rails
– Custom (insecure) SQL Queries
– Business Logic Vulnerabilities
Rails Model: Attribute Mass Assignment
The Malicious Input
Rails Model: Insecure SQL Queries
The application developer should ensure that the Query Interface
understand the difference between Query and Data.
Rails Model: SQL Injection Vectors
• ActiveRecord does not escape parameters for
• Dynamic parameters are encoded by default
unless explicitly marked as safe.
• There are scope for Reflected XSS
– Strings marked explicitly with html_safe method.
– Textile/Markdown Injection
– Insecure used of content_tag
• Rails 3.x is vulnerable to Clickjacking & UI
Redressing Type of attacks in default
– Easy Mitigation
• gem ‘secureheaders’ in Gemfile