Rails (In)Security

$ whoami

Maurizio Del Corno

Security Consultant

Developer

DAFAQ IS RAILS?

• Rails è un Framework

• Creato da @dhh

• Costruito su Ruby

INSTALL @ WINDOWS

http://railsinstaller.org/

SECURE BY DESIGN

• CSRF Protection

• SQLi praticamente impossibili

• Tutto escapato

MA QUESTO NON CI SALVA DEL TUTTO!

REGULAR EXPRESSION IN RUBY ovvero come RTFM ci avrebbe potuto salvare

UOT?

STOP! HAMMER TIME!

MATCH vs #{HTTP_VERB}

Rails implementa una protezione contro il CSRF…

…ma solo su POST (e giustamente!)

Per definire una rotta possiamo usare il verbo HTTP

post ‘/path/che/vogliamo’ => ‘controller#method’

match ‘/path/che/vogliamo’ => ‘controller#method’

Oppure possiamo usare la funzione “match”

RISULTATO:

POST

POST

POST

GET

U MAD BRO?

ENCODERS

Rails fa escaping di tutto di default… o quasi!

JSON, Javascript & CSS vengono passati “as is”!

HACKERS

MASS ASSIGNMENT

C’era una volta

E il suo grande amico…

…BENDER?!?!

MA COME E’ POSSIBILE?

Abuso della funzione Model.update_attributes(*args)

In questo modo il nostro controller accetta parametri del tipo:

=> /path?model[attr1]=val&model[attr1]=val&model[attr1]=val

E possiamo aggiornali come:

=> Model.update_attributes(params[:model])

…e se tra i parametri inseriamo qualcosa che nel form non c’è?

Come per esempio inserire tra le chiavi pubbliche la nostra?

<input type=“hidden” value=“USER_ID” name=“public_key[user_id]”>

L’avete messo attr_accessible vero??

ALL’INIZIO AVEVO DETTO CHE LE SQLi ERANO

“PRATICAMENTE” IMPOSSIBILI

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2695

GRAZIE DELL’ATTENZIONE