SQL Injection

[Felipe Antunes 0]

A pratica de ataques via SQL INJECTION hoje é bem mais comum do que já foi em 1999 quando sofri meu primeiro ataque via SQL INJECTION, na época tinha pouco tempo de "mercado" e mau mau sabia oque era uma select, porém ainda hoje vejo muitos debaterem a seu respeito, e recentemente em outro tópico que foi encerrado, o assunto tinha voltado a tona e começado a ser debatido.

 

Entendendo o SQL INJECTION.

 

o SQL INJECTION não é uma falha do ASP, ou do PHP, ou de qualquer outra linguagem, qualquer banco de dados SQL é passivel do erro, tal como sql server, mysql e muitos outros.

 

o SQL INJECTION nunca será "corrijido" pois na prática não é um erro.

 

Na Prática.

select * from tabela where campo = 'clausula'

Na SQL acima estamos fazendo uma consulta ao banco de dados, junto a tabela, cuja qual o campo seja = 'clausula'

 

Vimos que o uso de ' é sempre usado antes de escrevemos nossa "string" de consulta, determinando que dentro do SQL um texto(string) será usado, caso contrario o SQL entenderia que clausula seja um comando do SQL e não um texto simples.

 

Agora para tornar a coisa dinamica, trocamos o clausula por uma variavel passada pelo "url".

 

select * from tabela where campo = '"&request("clausula")&"'"

 

request("clausula") poderia ser request.form("clausula") ou request.querystring("clausula")

 

Dessa forma, um valor qualquer será passado para a nossa SQL, imaginamos que clausula = FULANO.

select * from tabela where campo = 'FULANO'"

 

porém o que aconteceria se clausula = FUL'ANO.

select * from tabela where campo = 'FUL'ANO'"

Isso fária com que um erro fosse gerado pelo DataBas, pois ele entendia que a SQL terminaria no L e o restante ANO seria um comando SQL e não um texto.

 

fazendo isso o usuário poderia então "complementar" a sua SQL com códigos passivos, tais como clausula = ' or 1 = 1 or '

select * from tabela where campo = '' or 1 = 1 or ''"

 

dessa forma o "texto" or 1 =... passaria ser um comando SQL e não um simples texto, e ai morre o perigo.

 

 

O MAIOR ERRO COMETIDO POR PROGRAMADORES (NA MINHA OPINIÃO)

O maior erro de vários programadores, é aplicar filtros de palavras em suas consultas tentando com isso evitar o SQL INJECTION mas prejudicam drasticamente a sua aplicação.

 

Recentemente em um tópico encerrado o moderador xanburzum insentiva outro membro a usar a função abaixo para se proteger, quando na verdade não é nescessário nada disso.

Function SafeSQL(sInput)
  TempString = sInput
  sBadChars=array("select", "drop", ";", "--", "insert", "delete", "xp_", "#", "%", "&", "'", "(", ")", ":", ";", "<", ">", "=", "[", "]", "?", "`", "|") 
  For iCounter = 0 to uBound(sBadChars)
    TempString = replace(TempString,sBadChars(iCounter),"")
  Next
  SafeSQL = TempString
End function

Vamos entender o código, inicialmente ele trasforma o sInput em uma variavel TempString (essa parte acho desnescessário já que hora nem uma o valor de sInput será alterado não tem o porque usarmos duas variaveis para o mesmo caso.

 

Em Seguida ele cria um array com palaras chaves que ele quer "evitar".

sBadChars=array("select", "drop", ";", "--", "insert", "delete", "xp_", "#", "%", "&", "'", "(", ")", ":", ";", "<", ">", "=", "[", "]", "?", "`", "|") 

Agora ele percorre esse array, apagando as palavras chaves da string.

 

Com a função passada por ele, jamais poderemos gravar em nosso banco de dados as palavras mensionadas, textos importantes serão literalmente apagados de suas strings.

 

Se você estiver fazendo uma pergunta, o sinal de ? será removido da mesma, caso esteja fazendo uma comparação não poderá usar =, o simbolo de # também não poderá ser usado, e em casos onde gravamos códgos html em sistemas adminsitrativos são de fato importantes.

o Exemplo sita apenas 3 agravantes para o fato, mas existem muito outros.

 

Então? como proteger do SQL INJECTION?

Simples, rápido e eficaz, já aprendemos que o vilão são as ', então devemos apenas nos preocupar com ele, e não precisamos excluílo de nossos DB, apenas trata-lo de forma adequada.

select * from tabela where campo = '"&replace(request("clausula"),"'","''")&"'"

O que eu fiz foi trocar as 1 ' por 2 '' dessa forma, ja estamos protegido do SQL INJECTION.

 

Desculpem o texto grande, a bagunça na escrita, erros de português, mas sabem como é... muito tempo escrevendo ifs e elses que esqueci como usar o portugues hehehe.

[hargon 64]

Tópico movido

 

Origem: ASP http://forum.imasters.com.br/public/style_emoticons/default/seta.gif Destino: Artigos, Tutoriais e Matérias (ASP)

[desisto 0]

isso é o que venho dizendo a tempos, de posts mais antigos

 

é tosco a ideia de substituir palavras

 

o usuario nao pode digitar 'deletei sem querer' ou 'dropei uma onda'

 

ahahuahhaauuhahahah

 

 

 

 

chega a ser bizarro, mais amador do que igonrar a falha do injection

 

só bloqueio palavras exatas e no contexto da 'tentativa de invasao', fora isso é passe livre

[Felipe Antunes 0]

Pois é, isso em uma frase, agora imagina ficar sem a "?" ?

 

nesse forum mesmo, imagina quantas frases sem contexto existiriam? não ia existir uma indagação se quer! hueuheuheuheuhe

 

isso é o que venho dizendo a tempos, de posts mais antigos

 

é tosco a ideia de substituir palavras

 

o usuario nao pode digitar 'deletei sem querer' ou 'dropei uma onda'

 

ahahuahhaauuhahahah

 

 

 

 

chega a ser bizarro, mais amador do que igonrar a falha do injection

 

só bloqueio palavras exatas e no contexto da 'tentativa de invasao', fora isso é passe livre

 

[Salgado 4]

Felipe, também sou partidário que a simples substituição da ' (aspa simples) já impede parcialmente uma Injeção de SQL "não autorizada".

 

Agora se pergunte, porque parcialmente? Simples, pois em campos do tipo numérico não é necessário a ' para passar dados, um simples espaço é suficiente para se injetar dados "extras" numa SQL. Sou partidário da total validação dos dados que serão enviados à uma SQL, verificando se os tipos de dados enviados pelo usuários do mesmo tipo que será enviado ao banco, em uma consulta ou outra operação.

 

A palavra chave para se evitar, com sucesso, a maioria das injeções de SQL é "VALIDAÇÃO de tipos".

 

Esse erro de se evitar as palavras "reservadas" de comandos SQL se dá pois um "grande programador" (ninguém daqui) de antigamente começou fazendo simplesmente isso e depois não se atualizou e nem atualizou sua referencia, sendo essa referencia uma das primeiras que surgem em pesquisas por "SQL INJECTION" na língua portuguesa.

 

Vamos continuar essa discussão em alto nível e apresentar prós e contras de cada tipo de "função" ou "rotina" que são normalmente usadas para se evitar a injeção de SQL.

[Felipe Antunes 0]

Os banco de dados aceitam o cadastramento de campos do tipo int usando ', é só você usar a sql de forma correta, e não simplesmente colocar um = var.

 

Assim como pedi a todos vocês via mp, peço novamente que remova o tópico e meu usuario do forum, chega de estresse.

 

Felipe, também sou partidário que a simples substituição da ' (aspa simples) já impede parcialmente uma Injeção de SQL "não autorizada".

 

Agora se pergunte, porque parcialmente? Simples, pois em campos do tipo numérico não é necessário a ' para passar dados, um simples espaço é suficiente para se injetar dados "extras" numa SQL. Sou partidário da total validação dos dados que serão enviados à uma SQL, verificando se os tipos de dados enviados pelo usuários do mesmo tipo que será enviado ao banco, em uma consulta ou outra operação.

 

A palavra chave para se evitar, com sucesso, a maioria das injeções de SQL é "VALIDAÇÃO de tipos".

 

Esse erro de se evitar as palavras "reservadas" de comandos SQL se dá pois um "grande programador" (ninguém daqui) de antigamente começou fazendo simplesmente isso e depois não se atualizou e nem atualizou sua referencia, sendo essa referencia uma das primeiras que surgem em pesquisas por "SQL INJECTION" na língua portuguesa.

 

Vamos continuar essa discussão em alto nível e apresentar prós e contras de cada tipo de "função" ou "rotina" que são normalmente usadas para se evitar a injeção de SQL.

 

[~Thiago Lara 0]

Eu fazia da forma parecida das palavras!

Mas de certa forma, gostei da ideia do salgado de continuarmos a aprofundar essa discussão, afinal segurança é praticamente a alma da aplicação nada adianta ter um ótimo sistema se ele é vulnerável..

 

Alguém mais tem alguma função pra compartilhar? =)