Michele Gardellin:
>> Se i caratteri come l'apostrofo possono causare problemi per campi
>> come quello della password, significa probabilmente che
>> l'applicazione fa una query direttamente sul database (e
>> conseguentemente le password sono in chiaro nel database - il che
>> non mi sembra proprio una cosa ragionevole).
>>
> Alquanto O.T. ma curioso per questa affermazione
>
> query("SELECT count(*) FROM users WHERE user='$user' e
> pass=md5('$pass')
>
> Mi sembra una cosa che vedo spessissimo nelle applicazioni web,
> questo implica un sql_injection ? Ha tutti i presupposti di non
> convertire in hash la password ma di usarla direttamente in DB
Ok, in questo caso non sarebbero in chiaro, ma sinceramente non vedo
perche' fare eseguire la funzione di md5 direttamente al database e
complicarsi la vita riducendo il numero di caratteri per la password per
evitare sql injection (escludo il fatto che nella funzione che mostri
tui le password nel db sono md5 "dirette" senza salt, comunque una
brutta idea).
La una funzione molto piu' robusta e' (ovviamente assumendo di fare un
escape su tutti i parametri passati a sql):
SELECT COUNT(*) FROM users WHERE user = '$user'
Se il count e' uno, allora:
SELECT passwordhash FROM users WHERE user = '$user'
(ovviamente puoi implementare la cosa in modo diverso facendo una sola
SELECT passwordhash FROM users WHERE user = '$user' nella prima stringa
SQL e poi fare un conteggio via codice)
- prendi il salt associato a questo user (tipicamente un certo numero di
byte "appesi" alla fine dell'hash)
- calcola via codice (non via DB) ad es. "sha256(password ricevuta +
salt) + salt"
- confronta "sha256(password ricevuta + salt) + salt" con "passwordhash"
..
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
