Aggiornate Rails

Una sql injection in active record, ma solo se siete stati incauti e
avete distribuito secret.rb
http://weblog.rubyonrails.org/2013/1/2/Rails-3-2-10--3-1-9--and-3-0-18-have-been-released/

Paolo

Io sto preparando un post sull’exploit. Sinceramente l’approccio che
avrei
usato un filter su quello che arriva ai dynamic finder methods.

Facendo reverse dalla patch per ora nn sono riuscito a scrivere
l’exploit.

Paolo
Il giorno 03/gen/2013 19:33, “Paolo M.”
[email protected]
ha scritto:

Ciao,

2013/1/3 Paolo P. [email protected]:

Io sto preparando un post sull’exploit. Sinceramente l’approccio che avrei
usato un filter su quello che arriva ai dynamic finder methods.

Facendo reverse dalla patch per ora nn sono riuscito a scrivere l’exploit.

Se non l’avete gia’ letto sul blog di Phusion c’e’ un post che spiega
per bene la cosa:
http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts

ciao ciao,
matteo.

Il giorno 04/gen/2013, alle ore 11:55, Paolo P.
[email protected] ha scritto:

Bello, nel frattempo sto preparando un post un po’ pippoto su quanto sia
bello aggiungere un po’ di defensive programming quando prendi params e lo
dai in pasto al tuo ORM di quartiere.

vabb, se non puoi fidarti neanche del caro vecchio ORM sotto casa (dove
magari ti facevi preparare una query prima di andare a scuola), vuol
dire che il mondo sta andando davvero a rotoli :'D

A.


http://andreapavoni.com

Bello, nel frattempo sto preparando un post un po’ pippoto su quanto sia
bello aggiungere un po’ di defensive programming quando prendi params e
lo
dai in pasto al tuo ORM di quartiere.

Paolo

2013/1/4 bugant [email protected]

Se non l’avete gia’ letto sul blog di Phusion c’e’ un post che spiega


$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

Bello, nel frattempo sto preparando un post un po’ pippoto su quanto sia
bello aggiungere un po’ di defensive programming quando prendi params e lo
dai in pasto al tuo ORM di quartiere.

vabb, se non puoi fidarti neanche del caro vecchio ORM sotto casa (dove magari
ti facevi preparare una query prima di andare a scuola), vuol dire che il mondo
sta andando davvero a rotoli :'D

Effettivamente, la mia idea di ‘defensive programming’ e`: “usare in
modo corretto l’ORM”. Non posso difendermi a priori da tutti gli
attacchi possibili… no?


David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

Infatti ActiveRecord ti protegge dalla SQL Injection facendo un filtro
basilare ad esempio sull’escape di caratteri particolari come ', & e
altro.

Nel caso particolare non era un problema di escape quanto di gestione
del
parametro che veniva interpretato come opzioni da passare alla select
invece che come argomento della clausola where:

User.find_by_id(1) # REGULAR CALL => SELECT “users”.* FROM “users” WHERE
“users”.“id” = 1 LIMIT 1 User.find_by_id({:select =>"* from users where
id=4 --"}) # INJECTION => SELECT * from users where id=4 – FROM “users”
WHERE “users”.“id” IS NULL LIMIT 1

Quello che intendo io con “defensive programming” gestire quanto letto
dall’esterno in maniera coerente con la business logic della nostra
applicazione.

Ad esempio, supponiamo che i nostri id abbiano determinati valori (ad
esempio da 500 a 1200… li ho usati anche nel post :P)… l’approccio
normale sarebbe quello di di passare params[:id] a find_by_id delegando
ad
ActiveRecord tutto quanto.
Secondo me, un approccio difensivo (se volete paranoico ma i casi di SQL
Injection quando accadono… fanno male) quello di aggiungere dei
controlli sul valore del parametro letto in modo da verificare che sia
effettivamente qualcosa di “sensato” per la nostra applicazione.

Voi cosa ne pensate?
Benvenute le critiche anche feroci a questo mio approccio.

Paolo

2013/1/4 Riccardo L. [email protected]

bello aggiungere un po’ di defensive programming quando prendi params
modo corretto l’ORM". Non posso difendermi a priori da tutti gli
[email protected]
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

(ho ipotizzato nel mio post il solito modello User con email e password,
da
qui l’esempio del find_by_id) :stuck_out_tongue:

2013/1/4 Paolo P. [email protected]

WHERE “users”.“id” IS NULL LIMIT 1
Injection quando accadono… fanno male) quello di aggiungere dei
2013/1/4 Riccardo L. [email protected]

sia


L’esperienza quello che ottieni quando non ottieni quello che desideri.
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com


$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

imho quando si usa una find_by_something l’orm dovrebbe preoccuparsi che
il
parametro passato come chiave di ricerca di “something” sia castato al
tipo
di dato sul db corrispondente, o a stringa se poi ci sono livelli
successivi di interpretazione

Poi non dovrebbe essere l’ORM a proteggermi dall’SQL injection?
E’ stato patchato il find_by in ActiveRecord infatti, o no?

2013/1/4 David W. [email protected]

modo corretto l’ORM". Non posso difendermi a priori da tutti gli
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Riccardo

L’esperienza quello che ottieni quando non ottieni quello che desideri.

imho quando si usa una find_by_something l’orm dovrebbe preoccuparsi che il
parametro passato come chiave di ricerca di “something” sia castato al tipo
di dato sul db corrispondente, o a stringa se poi ci sono livelli
successivi di interpretazione

E soprattutto non capisco che senso abbia consentire di usare un
metodo find_by_something omettendo il primo parametro, che sarebbe il
“something”…


Giuseppe C.

Ecco qui il mio post con il pippotto sul defensive programming…
scatenatevi con i commenti.

http://armoredcode.com/blog/cve-2012-5664-sql-injection-on-rails-dot-dot-dot-again/

Paolo

2013/1/4 Sante R. [email protected]

imho quando si usa una find_by_something l’orm dovrebbe preoccuparsi che il
parametro passato come chiave di ricerca di “something” sia castato al tipo
di dato sul db corrispondente, o a stringa se poi ci sono livelli
successivi di interpretazione


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com

2013/1/4 Giuseppe C. [email protected]:

imho quando si usa una find_by_something l’orm dovrebbe preoccuparsi che il
parametro passato come chiave di ricerca di “something” sia castato al tipo
di dato sul db corrispondente, o a stringa se poi ci sono livelli
successivi di interpretazione

E soprattutto non capisco che senso abbia consentire di usare un
metodo find_by_something omettendo il primo parametro, che sarebbe il
“something”…

da quel che capisco io accidentale, per il fatto che i dynamic
finder prendono comunque un numero di argomenti variabili (nel senso
di #find_by_x_and_y) e il caso in cui ci fossero meno parametri di
quelli impliciti nel nome non era gestito.

La patch fa esattamente questo check.


twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

Il giorno 05 gennaio 2013 00:11, Paolo M.
[email protected]ha scritto:

@Paolo P.: qualcosa era stato fatto
https://github.com/medihack/param_checker
Uno dei problemi come segnalare che i parametri sono sbagliati. Non
solo degli attaccanti potrebbero mandare valori sbagliati, ma anche
utenti normali. Aggiungere messaggi a errors e usare i normali
meccanismi di active record?

Per le query pi complesse (es. ricerche) io creo sempre un oggetto pi
complesso su cui configurare tutte le varie opzioni.
E’ un’ordine di grandezza pi facile da sviluppare e testare.
Usare le valditations mi sembra una buona strada.

@Paolo P.: qualcosa era stato fatto
https://github.com/medihack/param_checker
Uno dei problemi è come segnalare che i parametri sono sbagliati. Non
solo degli attaccanti potrebbero mandare valori sbagliati, ma anche
utenti normali. Aggiungere messaggi a errors e usare i normali
meccanismi di active record?

Matteo C. wrote in post #1091180:

Per le query pi complesse (es. ricerche) io creo sempre un oggetto pi
complesso su cui configurare tutte le varie opzioni.
E’ un’ordine di grandezza pi facile da sviluppare e testare.

Più o meno riesco ad immaginarlo ma ci puoi fare un esempio?

Grazie

Ultimamente sto facendo una cosa simile anche io. Immaginando di avere
un modello AR ed una vista contenente una tabella che mostra esso e dati
provenienti da altre N tabelle in join con esso (con necessit di operare
degli ordinamenti eventuali sui dai provenienti dalle join).

In questo caso quello che faccio una cosa tipo (molto schematizzato):

class SearchProxy
def initialize(user, project, options={})

end

def entries
find
filter
sort
paginate
end

private

def find

end

def filter

end

def sort

end

def paginate

end
end

I cardini dell’oggetto li passo nell’initializer, gli altri parametri
nelle options e poi dentro faccio le cose che servono, le join, le
concatenazioni AR, dei query methods accessori, le memoizzazioni
necessarie e via dicendo. Viene molto fico.

-f

Hanno trovato un’altra vulnerabilità, più seria della precedente:
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ

Altro upgrade!

Paolo

Ho appena finito di patchare al volo pi di 30 app in prod. Che sudata.

Se qualcuno di voi ha bisogno di un POC che ho scritto per verificare se
la vostra app sia vulnerabile o meno (ad es dopo l’applicazione della
patch via initializer) mi scriva.

Non lo sharo perch sono stati gi distribuiti troppi dettagli in merito
alla vuln.

Ciao,

On Jan 9, 2013, at 11:43:07 PM, Paolo M. wrote:

Hanno trovato un’altra vulnerabilit, pi seria della precedente:

https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ

Altro upgrade!

~Marcello

come non detto:

https://github.com/rapid7/metasploit-framework/pull/1281

aggiornate / patchate ASAP!

~Marcello

~ [email protected]
~ http://sindro.me/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs