Protecção de injecção SQL para ASP clássico
Qual é a forma forte de proteger contra a injecção de sql para uma aplicação asp clássica?
para tua informação, estou a usá-lo com um DB de acesso. (Eu não escrevi o app)
8 answers
Procedimentos armazenados e / ou declarações preparadas:
Https://stackoverflow.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks
Captura de injeção de SQL e outros pedidos maliciosos na Web
Com o Access DB, ainda pode fazê-lo, mas se já está preocupado com a injecção de SQL, acho que precisa de sai do acesso de qualquer maneira.
Aqui está um link para a técnica de acesso:Http://www.asp101.com/samples/storedqueries.asp
Note que o que normalmente protege da injecção não é o procedimento armazenado em si, mas o facto de ser parametrizado e não dinâmico. Lembre-se que mesmo SPs que constroem código dinâmico pode ser vulnerável à injeção se eles usam parâmetros de certas maneiras para construir o código dinâmico. No geral, eu prefiro SPs porque eles formam uma interface camada que as aplicações chegam à base de dados, de modo que os aplicativos nem sequer são autorizados a executar código arbitrário em primeiro lugar.
Além disso, o ponto de execução do procedimento armazenado pode ser vulnerável se não usar o comando e os parâmetros, por exemplo, este ainda é vulnerável porque é dinamicamente construído e pode ser um alvo de injecção:
Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;
Lembre-se que a sua base de dados precisa de defender o seu próprio perímetro, e se várias logins têm direitos para INSERT/UPDATE/DELETE em tabelas, qualquer código em essas aplicações (ou aplicações comprometidas) podem ser um problema potencial. Se as login só têm direitos para executar procedimentos armazenados, isto forma um funil através do qual você pode muito mais facilmente garantir o comportamento correto. (Similar a OO concepts where objects are responsible for their interfaces and don't expose all their inner working.)
Aqui estão alguns scripts sqlinject que eu fiz há muito tempo uma versão simples e uma versão estendida:
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
"uma forma forte de proteger contra a injecção de sql para uma aplicação asp clássica" é validar impiedosamente todas as entradas. Periodo.
Os procedimentos armazenados por si só e / ou um sistema de base de dados diferente não correspondem necessariamente a uma boa segurança.
O MS lançou recentemente uma ferramenta de inspeção de injeção SQL que procura dados não validados que são usados numa consulta. É isso que devias procurar.
Aqui está a ligação.: O analisador de código-fonte da Microsoft para a ferramenta de injecção SQL é disponível para encontrar vulnerabilidades de injeção SQL no código ASPUsando o parametrized querys, é necessário criar um objecto de comando, atribuir-lhe parâmetros com um nome e um valor, se o fizer não terá de se preocupar com mais nada (referindo-se à injecção de sql, é claro;)
Http://prepared-statement.blogspot.com/2006/02/asp-prepared-statements.html
E não confiem nos procedimentos armazenados, podem tornar-se um vector de ataque também se não usarem declarações preparadas.Se os procedimentos armazenados não forem uma opção - e mesmo que sejam - valide todas as entradas cuidadosamente
O Analisador de código fonte da Microsoft para a ferramenta de injecção SQL está disponível para encontrar vulnerabilidades de injecção SQL no código ASP
Se é um bom programador, pode criar um site de comércio electrónico utilizando ficheiros de texto como base de dados. Sim, não será tão bom como o site conduzido Oracle, mas ele vai fazer muito bem para pequenas empresas, como a casa baseada, fabricação de jóias personalizadas.
E se for um bom programador, não irá usar declarações SQL em linha nas suas páginas ASP. Mesmo no acesso você tem a opção de construir e usar consulta..
Armazenar procs com verificação de dados, juntamente com o codificador html -- é a melhor maneira de evitar ataques de injeção SQL.
Para valores como números, é bastante fácil extrair o número para verificar se é realmente apenas um número. Escapar a todos os caracteres especiais para SQL. Fazer isso impedirá que a tentativa de ataque funcione.