Problema com SQL no Login[Resolvido]

uma forma simples é você não utilizar o AND senha = 'blabla' no seu sql.

por exemplo:

SELECT * FROM tb_usuario WHERE login = "blablabla"
// se o cara tentar realizar um sql injection

SELECT * FROM tb_usuario WHERE login = "" OR 1=1

//só que a validação da senha seria feito via codigo mesmo ex.
if(senha = this.senha)
//realiza login
else
//retorna a pagina de login

Se você usar o Hibernate DIREITO, ele evita o SQL Injection.

Veja um exemplo aqui:

http://www.owasp.org/index.php/Hibernate-Guidelines#Don.27t_use_session.find.28.29

Ele dá um exemplo em que pode haver SQL Injection (quando você concatena os parâmetros, simplesmente) e onde não há SQL Injection (onde você usa o operador “?”) para ele pegar os parâmetros como usuário e senha.

dxos, não adianta só validar a senha no braço como você mostrou. Você não está vendo o problema completo.

O problema mais grave é quando no SQL Injection o cara aproveita que normalmente você acaba rodando os programas com privilégios maiores que os necessários*, e o cracker manda um comando do tipo que dropa tabelas, ou então atualiza as tabelas com valores indevidos, ou remove linhas, ou mesmo insere uma nova linha com usuário e senha do jeito que ele quer.

• Nunca vi um programa SQL que usasse apenas os privilégios necessários, exceto naqueles lugares cheios de frescuras onde você nem pode dar um select no banco - precisa de autorização do CIO, ou coisa parecida.

entanglement:

dxos, não adianta só validar a senha no braço como você mostrou. Você não está vendo o problema completo.

O problema mais grave é quando no SQL Injection o cara aproveita que normalmente você acaba rodando os programas com privilégios maiores que os necessários*, e o cracker manda um comando do tipo que dropa tabelas, ou então atualiza as tabelas com valores indevidos, ou remove linhas, ou mesmo insere uma nova linha com usuário e senha do jeito que ele quer.

• Nunca vi um programa SQL que usasse apenas os privilégios necessários, exceto naqueles lugares cheios de frescuras onde você nem pode dar um select no banco - precisa de autorização do CIO, ou coisa parecida.

respondi desta Forma pois ele perguntou sobre sql.
Eu no caso utilizaria um PreparedStatement …

mas no caso do exemplo que vc usou de darem DROP na tabela via SQL invection e que os sistemas nunca tem os privilegios de segurança no usuario do banco.
ai vai de cabeça das pessoas, se elas não se concientizarem que utilizar os privilegios é MAIS DO QUE NECESSARIO, se tem este recurso pq não utiliza-ló?
claro que só isto não resolve, mais já é de grande ajuda.

aqui na empresa sempre utilizamos, pos perder qualquer dado aqui é “rua” quase certo XD…

apesar que concordo com você em varios pontos…

aew
eu usei um PreparedStatement e deu certo…
ele encara como um parametro e nao uma sql…ai rodou aqui!!

Vlw pela ajuda pessoal!