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:
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.
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:
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
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:
(ho ipotizzato nel mio post il solito modello User con email e password,
da
qui l’esempio del find_by_id) 
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 beerThe 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:
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.
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:
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 interpretazioneE 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
GitHub - medihack/param_checker: ParamChecker is a Ruby library for validating and casting strings. Therefore it is a handy way to check GET/POST parameters.
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
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