Classic ASP SQL Injection Protection
https://stackoverflow.com/questions/149848
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Qual è un modo efficace per proteggere contro l'iniezione sql per un'app ASP classica?
Cordiali saluti, lo sto usando con un DB di accesso. (Non ho scritto l'app)
Soluzione
Procedure memorizzate e / o dichiarazioni preparate:
Catching SQL Injection e altre richieste Web dannose
Con Access DB, puoi ancora farlo, ma se sei già preoccupato per SQL Injection, penso che devi comunque uscire da Access.
Ecco un link alla tecnica in Access:
http://www.asp101.com/samples/storedqueries.asp
Si noti che ciò che protegge in genere dall'iniezione non è la stessa procedura memorizzata, ma il fatto che sia parametrizzata e non dinamica. Ricorda che anche gli SP che creano codice dinamico possono essere vulnerabili all'iniezione se usano parametri in determinati modi per costruire il codice dinamico. Nel complesso, preferisco gli SP perché formano un livello di interfaccia che le applicazioni arrivano al database, quindi le app non sono nemmeno autorizzate a eseguire codice arbitrario in primo luogo.
Inoltre, il punto di esecuzione della procedura memorizzata può essere vulnerabile se non si utilizzano comandi e parametri, ad es. questo è ancora vulnerabile perché è costruito dinamicamente e può essere un obiettivo di iniezione:
Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;
Ricorda che il tuo database deve difendere il proprio perimetro e se vari accessi hanno i diritti di INSERT / UPDATE / DELETE nelle tabelle, qualsiasi codice in quelle applicazioni (o applicazioni compromesse) può essere un potenziale problema. Se gli accessi dispongono solo dei diritti per eseguire le stored procedure, questo forma una canalizzazione attraverso la quale è possibile garantire molto più facilmente il comportamento corretto. (Simile ai concetti OO in cui gli oggetti sono responsabili delle loro interfacce e non espongono tutti i loro meccanismi interni.)
Altri suggerimenti
Ecco un paio di script sqlinject che ho creato molto tempo fa una versione semplice e una versione estesa:
function SQLInject(strWords)
dim badChars, newChars, i
badChars = array("select", "drop", ";", "--", "insert", "delete", "xp_")
newChars = strWords
for i = 0 to uBound(badChars)
newChars = replace(newChars, badChars(i), "")
next
newChars = newChars
newChars= replace(newChars, "'", "''")
newChars= replace(newChars, " ", "")
newChars= replace(newChars, "'", "|")
newChars= replace(newChars, "|", "''")
newChars= replace(newChars, "\""", "|")
newChars= replace(newChars, "|", "''")
SQLInject=newChars
end function
function SQLInject2(strWords)
dim badChars, newChars, tmpChars, regEx, i
badChars = array( _
"select(.*)(from|with|by){1}", "insert(.*)(into|values){1}", "update(.*)set", "delete(.*)(from|with){1}", _
"drop(.*)(from|aggre|role|assem|key|cert|cont|credential|data|endpoint|event|f ulltext|function|index|login|type|schema|procedure|que|remote|role|route|sign| stat|syno|table|trigger|user|view|xml){1}", _
"alter(.*)(application|assem|key|author|cert|credential|data|endpoint|fulltext |function|index|login|type|schema|procedure|que|remote|role|route|serv|table|u ser|view|xml){1}", _
"xp_", "sp_", "restore\s", "grant\s", "revoke\s", _
"dbcc", "dump", "use\s", "set\s", "truncate\s", "backup\s", _
"load\s", "save\s", "shutdown", "cast(.*)\(", "convert(.*)\(", "execute\s", _
"updatetext", "writetext", "reconfigure", _
"/\*", "\*/", ";", "\-\-", "\[", "\]", "char(.*)\(", "nchar(.*)\(")
newChars = strWords
for i = 0 to uBound(badChars)
Set regEx = New RegExp
regEx.Pattern = badChars(i)
regEx.IgnoreCase = True
regEx.Global = True
newChars = regEx.Replace(newChars, "")
Set regEx = nothing
next
newChars = replace(newChars, "'", "''")
SqlInject2 = newChars
end function
" Un modo efficace per proteggere contro l'iniezione sql per un'app ASP classica " è convalidare spietatamente tutti gli input. Periodo.
Le sole procedure memorizzate e / o un diverso sistema di database non equivalgono necessariamente a una buona sicurezza.
MS ha recentemente pubblicato uno strumento di ispezione dell'iniezione SQL che cerca input non convalidati utilizzati in una query. È quello che dovresti cercare.
Usando le query parametrizzate, devi creare un oggetto comando, assegnargli i parametri con un nome e un valore, se lo fai non dovrai preoccuparti di nient'altro (facendo riferimento a SQL sq injection;))
http://prepared-statement.blogspot.com /2006/02/asp-prepared-statements.html
E non fidarti delle procedure memorizzate, possono diventare anche un vettore di attacco se non usi dichiarazioni preparate.
se le procedure memorizzate non sono un'opzione - e anche se lo sono - convalida accuratamente tutti gli input
Ehi, qualsiasi database valido come lo sviluppatore che lo usa.
Niente di più ma niente di meno.
Se sei un buon sviluppatore puoi costruire un sito di e-commerce usando file di testo come database. Sì, non sarà buono come il sito Web Oracle, ma andrà bene per le piccole aziende come la produzione di gioielli personalizzati da casa.
E se sei un buon sviluppatore, non utilizzerai istruzioni SQL inline nelle tue pagine ASP. Anche in Access hai la possibilità di creare e utilizzare query ..
Store procs con verifica dei dati, insieme alla codifica html - è il modo migliore per prevenire eventuali attacchi SQL Injection.
Lo strumento Microsoft Source Code Analyzer per SQL Injection è disponibile per trovare le vulnerabilità dell'iniezione SQL in Codice ASP
Il passaggio a SQL Express almeno è un'ottima opzione. Renderà le cose molto più sicure. Anche se l'utilizzo di parametri e Stored procedure può essere di grande aiuto. Consiglio inoltre di convalidare attentamente gli input per essere sicuri che corrispondano a ciò che ti aspetti.
Per valori come i numeri è abbastanza facile estrarre il numero per verificare che sia effettivamente solo un numero. Esci da tutti i caratteri speciali per SQL. In questo modo si eviterà che il tentativo di attacco funzioni.
