==Phrack Inc.==

               Volume 0x0f, Issue 0x45, Phile #0x0c of 0x10

|=-----------------------------------------------------------------------=|
|=--------------=[ Attacking Ruby on Rails Applications ]=---------------=|
|=-----------------------------------------------------------------------=|
|=---------------------=[ joernchen of Phenoelit ]=----------------------=|
|=---------------------=[ [email protected] ]=----------------------=|
|=-----------------------------------------------------------------------=|

--[ Table of contents

0 - Intro
1 - A Brief Overview
   1.1 - User input
   1.1.1 - POST/PUT/GET application/x-www-form-urlencoded
   1.1.2 - Multiparameter attributes
   1.1.3 - POST/PUT text/xml
   1.1.4 - POST/PUT application/json
   1.1.5 - GET vs. POST/PUT
2 - Common pitfalls
   2.1 - Sessions
   2.2 - to_json / to_xml
   2.3 - Code / Command Execution
       2.3.1 - Classical OS Command Injection
       2.3.2 - eval(user_input) and Friends
       2.3.3 - Indirections
   2.4 - Mass assignments
   2.5 - Regular Expressions
   2.6 - Renderers
   2.7 - Routing
3 - My favourite technique - CVE-2013-3221
4 - Notes on Code Injection Payloads
5 - Greetz and <3
A - References


--[ 0 - Intro

This little article aims to give an introduction to the topic of attacking
Ruby on Rails applications. It's neither complete nor dropping 0day. It's
rather the authors attempt to accumulate the interesting attack paths and
techniques in one write up. As yours truly spend most of his work on Ruby
on Rails applications in the time when Rails version 3 was current, some of
the described techniques are not applicable to Rails 4 any more. However
there is still a broad attack surface of older applications as migrating
Rails code up one or two version appears to be a real pain in the ass for
lager projects (if you doubt this ask your local Rails startup peeps :) ).


--[ 1 - A Brief Overview

Basically Ruby on Rails [0] is a Model-View-Controller (MVC) based web
application framework. It's overloaded with functionality, and this
functionality is what at the end of the day introduces the fine bugs we
all are looking for.

MVC is a software design pattern, which just says roughly the following:

The model is where the data lives, along with the business logic. So the
model is an abstraction to the database. The view is what you see, like
the HTML templates which get rendered. The controller itself is, what you
interact with. It takes requests and decides upon them what to do with the
data which were submitted.

This architecture is reflected in Rails on the file system, a sample
application's directory structure would look like this:

You are viewing proxied material from srcr.nl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.