Newsgroup: it.comp.software.database
Titolo: doppio utente db

ciao a tutti, sto continuando a sviluppare un cms e mi veniva in mente 
da un p� la seguente domanda.
premetto che gi� faccio opera sanificazione (? si dice cos�?) e uso 
prepared statement per essere "sicuro" di non incorrere in injection pi� 
o meno volute, per� ipotizzavo:
e se, almeno per le select, che alla fine sono il 98% delle query che 
vengono fatte dalla parte di cms che l'utente normale usa, usassi un 
diverso utente del db con grant di solo select?
immaginavo cos� che per le funzioni "avanzate" tipo inserimento 
commenti, login ecc. uso l'account "normale" e sanifico (?), ma per il 
resto delle opzioni immagino che posso benissimo usare un utente che ha 
dei limiti cos� se anche uno provasse a far danni tipo 
http://sito/index.php?id=1';drop
 table ecc.... l'utente con cui viene 
effettuata la query non avrebbe grant per fare un drop table.
ovviamente continuerei ad usare i sanitize e le prepared, la mia domanda 
sarebbe se questo metodo ha senso e innalza la sicurezza o se alla fine 
il "trucco" non vale la candela.
grazie a tutti.

 
se ti scoprono il primo utente, cosa ti fa pensare che non riescano a 
scoprire anche il secondo?
vedi se possono essere piu' indicate le stored procedures.
su mssql (quello conosco...) puoi rendere eseguibili le sp per un certo
utente togliendogli nel contempo qualsiasi accesso diretto alle tabelle
sottostanti. 
cosi' se anche qualcuno accede con l'utente usato dal sito, al massimo
puo' eseguire le sp, ma non leggere direttamente il contenuto delle tabelle. 
se le sp sono pensate come si deve, imho e' piu' robusto che non avere due 
utenti distinti.
verifica le possibilita' del tuo rdbms.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--


la mia domanda era riferita ad un'ipotesi di sql injection tramite query 
eseguite con paramteri provenienti da web.
ad esempio per prendere il contenuto di una pagina la query � (ad 
esempio) "SELECT text FROM pagine WHERE id='".$_REQUEST['id']."'" (qui � 
php)
ora, ovviamente se io scrivo invece che un valore numerico per riferirmi 
alla pagina, bens� un qualcosa tipo id=1';drop table pagine where 1='1
che succede? che (ammesso che l'abbia scritta bene) mi cancellano 
l'intera table.
se invece l'utente con cui la select � fatta, pu� fare solo select, (e 
qui chiedo) nell'esempio, immagino, la seconda query non verr� eseguita.
Grazie

 
con una stored procedure, elimini almeno questo problema alla radice.
se preferisci comporre il codice nella pagina php, il rischio injection 
non lo puoi eliminare con due utenti distinti: le tue pagine devono per 
forza accettare input dall'esterno e qualcosa nel db, prima o poi, lo 
devono scrivere...
lo puoi ridurre, lo puoi relegare a poche pagine, ma imho vale la pena 
pensare a soluzioni alternative.
si capisce che mi piacciono le sp?
:-)


 il "trucco" non vale la candela.
Il "trucco" non vale la candela.
Potrebbe aver senso in caso di applicazioni molto specifiche, ad esempio 
un motore di ricerca dove il 99% degli accessi al database passa per una 
stessa "porta" (e la stessa query) mentre le operazioni di modifica 
usano altri canali. Pu� aver senso anche nel caso tu abbia anche lato 
applicativo due tipologie completamente diverse di utenti, es: utente 
standard e amministrativo.
Piuttosto valuta se il database che usi (su i.c.j. parlate di MySQL. 
Per� chi ti risponde, non tu) permette di porre limiti pi� "fini" 
all'utente (es. update s�, drop e delete no.), magari tarate in funzione 
della tabella.
Comunque se usi a monte astrazioni (come i PreparedStatement che citi) 
che verificano esattezza e precisione sintattica della query, al 99% sei 
a posto.
I tre principi di fondo sono:
- parametrizzare le query
- mai creare query concatenando stringhe
- i dati in ingresso vanno esplicitamente convertiti (lo fanno i setXYZ 
dei PreparedStatement)
Se vuoi aumentare ulteriormente il livello di sicurezza usa uno strato 
sw apposito (N.B.: gli ORM non sono indenni a priori da problemi di SQL 
injection) ed eventualmente stored procedure (come suggerito da Paolo 
opg), anche se cos� rischi di ridurre la portabilit� verso altri engine.
Ciao,
Pablo