Newsgroup: it.comp.www.asp
Titolo: sql iniections

 
Ho capito il problema delle sql iniections ma non riesco a trasformare
questa query in una quey sicura.
strSQL = "SELECT nome_utente, pwd_utente, cod FROM Utenti WHERE nome_utente
= '" & login & "' AND pwd_utente = '" & pw & "' "
set objConn = server.createObject("ADODB.Connection")
objConn.open Application("DB_DataSource")
set objRs = server.createObject("ADODB.Recordset")
objRs.open strSQL, objConn
Ho trovato un articolo su internet che fa un esempio di sql sicura ma non
riesco ad applicarlo al mio caso. Fonte:
http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf
CREATE PROCEDURE getPressRelease
@pressReleaseID integer AS
SELECT title, description, releaseDate, body FROM pressReleases WHERE
pressReleaseID = @pressReleaseID
Grazie per l'attenzione
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 pressReleaseID = @pressReleaseID
Questa qua sopra č la sintassi per creare una Stored Procedure.
Semprechč il database che usi le supporti.
CREATE PROCEDURE LoginUtenti
(
@login varchar(50),
@pwd varchar(50)
)
AS
SELECT nome_utente, pwd_utente, cod 
FROM Utenti 
WHERE nome_utente = @login
AND pwd_utente = @pwd
Nel caso di SQLserver, lanci Query analizer e cosě crei la procedura.
Poi, da ASP, NON farai piů "Select..." ma "EXEC", passando di seguito i 
valori alla SP.
strSQL = "EXEC LoginUtenti " & login & ", " & pw
Apri il recordset....e ci sei.
Certo che se devi fare una SP per ogni query... meglio una funzioncina 
per eliminare caratteri fetenti no?
 
------------------------------------------------
Meglio dire a tua madre che fai il pianista 
in un bordello, piuttosto che il webmaster.
------------------------------------------------

 per eliminare caratteri fetenti no?
no è meglio usare proprio le SP, le quali offrono un notevole vantaggio
anche in termini di performance ed inoltre ti permette di separare
completamente i tier data con logica di bussines, se lasci tutte le query
sotto forma di sp nel db un domani una migrazione a un altro db sarà un
semplice gioco da ragazzi e l'impatto di migrazione sarà minimo, se invece
lasci tutto sotto forma di query oltre a dover modificare il db ti tocca
modificare il codice cosa mica tanto simpatica
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch

 per eliminare caratteri fetenti no?
la cosa migliroe in assoluto riomangono le SP. In piu' aggiungerei di
tipizzare i parametri quando vengono passati sia in input che in output.
Invece di fare una SP per ogni query puoi inserire N query all'inetrno della
stessa SP parametrizzandola e utilizzando il costrutto:
IF
BEGIN
    select...
END
-- 
Lino Mari [mod - it.economia.e-commerce]
http://www.ebow.it
 - e-business on web!
http://www.ebow.it/blog/
 - Mktg Log
http://www.dev2dev.it
 - La rete ha connesso nuove particelle - d2D004

 END
Ciao Lino,
occhio che procedendo in questo modo rischi che venga effettuata una nuova
ricompilazione della stored procedure in base al parametro di input che
discrimina il tipo di query.
Dal punto di vista delle prestazioni è molto meglio avere un numero
superiore di procedure che eseguono operazioni "atomiche", in modo da
ridurre al minimo la generazioni di nuovi piani di esecuzione e facilitarne
il loro riutilizzo.
Ciao!
-- 
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com
http://italy.mvps.org

 facilitarne il loro riutilizzo.
Ciao Lorenzo,
pienamente d'accordo con te. Pero' è anche vero che in progetti dove le SP
dieventerebbero diverse centinaia per avere un minimo di razionalizzazione e
gestione delle SP a volte bisogna mediare :)
Cmq è giusta la tua precisazione.


 modificare il codice cosa mica tanto simpatica
si puo' ancora fare una cosa per la portabilita' del db.
si inserisce un ulteriore strato tra database e datalayer: un oggetto che
sia capace di leggere una lista di query e chiamate alle sp, che sappia
codificare i parametri come vuole oracle oppure sql server oppure mySql
(qualcuno ha provato la versione con le sp?) e restituisca recordset e
parametri di output. il datalayer chiedera' solamante l'esecuzione di
quella query della lista, identificata da un codice univoco e si becca il
risultato. cambiando server db basta usare l'applicazione di "raccordo"
per quel tipo di db senza cambiare il datalayer.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 per quel tipo di db senza cambiare il datalayer.
mmh personalmente non apprezzo questo sistema in quanto non permette di
sfruttare al top le particolarità di ogni singolo db, rendendo il tutto si
più scalabile ma molto meno performante.
Inoltre quel layer che cerchi tu esiste da parecchio ed è deprecato si
chiama odbc :-P


 chiama odbc :-P
no, mi sono spiegato male, allora.
lo strato serve proprio _per_ sfruttare le capacità del singolo db.
ad esempio: le chiamate che si scrivono per eseguire sp su sqlServer e
oracle sono diverse in un caso si hanno delle riche nell'altro un cursore,
quindi cambio di db=> cambio di datalayer e verifica di un mucchio di
funzioni.
