Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Pessoal...Sofri uma invasão num Admin usando ACESS, mesmo tomando o cuidado de usar o Replace("Aspas Simples")!! Daí resolvi ler um pouco mais sobre o SQLInjection e fiz alguns testes em dois BDS diferentes...retirei o Replace("Aspas Simples") nos dois casos só pra fazer os testes...
Numa aplicação q usa SQLServer, realmente a vulnerabilidade é gigantesca! Só com o comando ' or 1=1-- consegui burlar a senha! Depois usei o ' having 1=1-- e de posse do nome da tabela consegui até incluir um novo administrador e senha nela e em seguida loguei na area restrita com ela!
Depois fiz o mesmo teste numa aplicação usando ACESS, só q os resultados obtidos são diferentes! Conforme abaixo:
>
****
SQLServer :
COMANDO ' or 1=1--
- Consegui burlar a senha e acessar a area restrita
' having 1=1--
Consegui Pegar o nome da tabela e depois injetar Um novo Admin e senha nesta tabela
' ; INSERT INTO minhatabela VALUES('iporto','1984')-- CONSEGUI INCLUIR UM user e senha depois de ter conseguido pegar o nome da tabela com o comando having!!
NO ACESS
COMANDO ' or 1=1--
- MENSAGEM DE ERRO: "Syntax error in string in query expression 'tbUser = '' or 1=1--' and tbSenha = '''. ELE ATÉ TROUXE OS NOMES DAS COLUNAS, TBUSER E TB SENHA (É UMA BRECHA...MAS NÃO TROUXE O NOME DA TABELA E NEM DEIXOU LOGAR)
' having 1=1--
- Syntax error in string in query expression '1=1--' and tbSenha = '''. NÃO TROUXE NENHUMA INFORMAÇÃO RELEVANTE
' ; INSERT INTO minhatabela VALUES('iporto','1984')-- MENSAGEM DE ERRO: "Characters found after end of SQL statement. " E NÃO GRAVOU NA TABELA!
DETALHE: Foi só retornar o Replace(AspasSimples) q consegui evitar os comandos acima
Enfim...nos meus testes o SQLServer me pareceu bem mais vulnerável ao Injection q o ACCESS!! engraçado como q o cara conseguiu invadir mesmo eu usando o Replace("AspasSimples") e ainda usando o ACCESS!! o cabra deletou meu bd inteiro! sorte q eu tinha um back dele de uma semana atrás! Gostaria de algumas dicas voltadas pro ACCESS... Alguem sabe alguns comandos q funciona no ACCESS pra me precaver?
Grato
Patrique estrela, o problema de tratar dessa forma é que algumas vezes deixamos de ter "conteúdo". Imagine um sistema de fórum que não permita a inclusão de "DROP", "INSERT", "DELET", "SELECT" e outros?
A VALIDAÇÃO dos campos que serão utilizados na SQL é muito importante. Faça o Replace das aspas simples por duas aspas simples, VALIDE cada campo de seu form para o tipo de dado do campo do BD e verifique também se existe para seu BD os "caracteres de escape" (//,\,|) para que uma determinada palavra ou caractere não seja interpretada pelo BD.
É...a sugestão do Patrique está bem completa! só não entendi muito bem o problema que o Salgado falou..., tipo pra que alguem vai querer colocar uma palavra reservada, tipo Drop, Select, Delet como usuário ou senha?? Com certeza deve ser alguém mal intencionado..penso eu.
A sugestão da validação dos campos é bem legal! No próprio form... tipo um Javascript p/ tratar o campo pra q não receba estes valores! Fazer mais ou menos assim:
****
IsSóString(user) e IsNumeric(senha)
Daí só texto pro campo user e a senha aceitando só valores numéricos..fica bem legal tb! Até um simples "maxlength" no Input tb já dá uma quebrada! Mas daí o cara pode executar o Injection via Query também! Mas até aí é outra situação..onde os Replace entram! É aquele tal negócio..quanto mas você puder dificultar melhor!
Agradeço aos colegas!
É...a sugestão do Patrique está bem completa! só não entendi muito bem o problema que o Salgado falou..., tipo pra que alguem vai querer colocar uma palavra reservada, tipo Drop, Select, Delet como usuário ou senha?? Com certeza deve ser alguém mal intencionado..penso eu.
Não necessariamente é alguém mal intencionado, imagine criar um sistema de Blog que será disponibilizado par acadastros externos, um surfista que não manja nada de programação pode criar um usuário: Surfista e senha: dropador. Aqui mesmo no fórum, tudo bem que estamos em PHP, mas os sistemas em ASP não bloqueiam o cadastro dessas palavras.
A sugestão da validação dos campos é bem legal! No próprio form... tipo um Javascript p/ tratar o campo pra q não receba estes valores! Fazer mais ou menos assim:IsSóString(user) e IsNumeric(senha)
Daí só texto pro campo user e a senha aceitando só valores numéricos..fica bem legal tb!
Agradeço aos colegas!
Com certeza, validação via JS e também no ASP.
sempre uso essa:
Anti-SQLInject
Function SafeSQL(sInput)
TempString = sInput
'sBadChars=array("select", "drop", ";", "--", "insert", "delete", "xp_", "#", "%", "&", "'", "(", ")", "/", "\", ":", ";", "<", ">", "=", "[", "]", "?", "`", "|")
sBadChars=array("select", "drop", ";", "--", "insert", "delete", "xp_", "#", "%", "&", "'", "(", ")", ":", ";", "<", ">", "=", "[", "]", "?", "`", "|")
For iCounter = 0 to uBound(sBadChars)
TempString = replace(TempString,sBadChars(iCounter),"")
Next
SafeSQL = TempStringE para usar na SQL
SQL = "SELECT * FROM Cal_Events WHERE Cal_EventID = " & SafeSQL(request.querystring("eventID"))
concordo com o salgado
se fizermos as verificacoes necessarias nao ha necessidade de excluir palavra nenhuma
A solução que adotei no meu sistema foi fazer um select usando apenas o usuário, se encontrar, eu verifico se a senha está correta.
Fica mais ou menos assim:
SELECT senha FROM usuario WHERE email = 'e_mail_que_usuario_digitou'
If (senha_do_recordset == 'senha_que_usuario_digitou')
...
muito boa a solucão do Oenning :D
Mais somente o tratamento de Aspas Simples não garante a sua segurança, eu particulamente fiz uma function e com ela eu nunca tive problema com invasão, inclusive já fiz uns testes e nenhum sql injection conseguiu burlar o sistema.
Segue abaixo a function
End function []'s