Maneira de proteger seu site contra SQLi

Maneira de proteger seu site contra SQLi



Maneira de proteger seu site contra SQLI

Oi todos os usuários, esta é simples tutorial para iniciantes sobre como proteger seu site contra SQL Injection e este tutorial também vai ajudar a verificar se o seu site é vulnerável a SQLI e como torná-lo resistente a SQLI.

O que é SQL Injection?

SQL significa Structured Query Language, e é a linguagem utilizada pelos bancos de dados mais website. SQL Injection é uma técnica usada por hackers para adicionar seu próprio SQL para SQL do seu site para ter acesso a informações confidenciais ou para alterar ou apagar os dados que mantém o seu site funcionando. Vou falar apenas uma forma de SQL Injection ataque que permite que um hacker para fazer logon como um administrador - mesmo se ele não sabe a senha.

O seu site é vulnerável?

Se seu site tem um formulário de login para um administrador fazer o login, ir para o site agora, em nome de usuário o tipo de campo o nome do usuário administrador.

No campo Senha, digite ou cole o seguinte:

x' ou 'a' = 'a

Se o site não permite que você faça o login usando essa seqüência que você pode relaxar um pouco, este artigo provavelmente não se aplica a você. No entanto, você pode tentar essa alternativa:

x' ou 1=1--

Ou você pode tentar colar uma ou ambas as acima para o login e campo de senha. Ou se você está familiarizado com SQL você pode tentar algumas outras variações. Um hacker que realmente quer ter acesso ao seu site irá tentar muitas variações antes que ele desista.

Se você fosse capaz de fazer login usando qualquer um desses métodos, em seguida, obter a sua tecnologia web para ler este artigo, e de ler todos os outros métodos de injeção de SQL. Os hackers e "kiddies skript" saber todas essas coisas; techs seu web precisa de saber isso também.


Se você fosse capaz de entrar, então o código que gera a SQL para o login parecido com este:

$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

Quando você log em geral, digamos usando o admin user e senha secreta, o que acontece é que o administrador é colocado no lugar de $ username e secreto é colocado no lugar de $ password. O SQL que é gerado, então fica assim:

SELECT * FROM usuários WHERE username = 'admin' = PASSWORD e 'segredo'

Mas quando você entra x 'ou' a '=' a como senha, o SQL que é gerado parecido com este:

SELECT * FROM usuários WHERE username = 'admin' e senha = 'x' ou 'a' = 'a'

Observe que a string: x 'ou' a '=' a injetou uma frase extra na cláusula WHERE: ou 'a' = 'a'. Isto significa que o WHERE é sempre verdadeiro, e assim essa consulta retornará uma linha conter detalhes do usuário.

Se houver apenas um único usuário definido no banco de dados, então os detalhes do usuário que sempre será retornado eo sistema irá permitir que você faça o login! Se você tiver vários usuários, então um desses usuários serão devolvidos ao acaso.

Como resistir contra SQLI


Fixação essa brecha de segurança não é tão difícil. Existem várias maneiras de fazê-lo. Se você estiver usando o MySQL, o método mais simples é escapar o nome de usuário e senha, usando o
mysql_escape_string() or mysql_real_escape_string() functions, e.g.:

$userid = mysql_real_escape_string($userid);
$password = mysql_real_escape_string($password);
$sql =
"SELECT * FROM users
"WHERE username = '" . $username .
"' AND password = '" . $password . "'";

Agora, quando o SQL é criado, ele sairá como:

SELECT * FROM usuários ONDE username = 'admin' e senha = 'x \' ou \ 'a \' = \ 'a'

As barras invertidas (\) tornar o banco de tratar a citação como um personagem normal, e não como um delimitador, de modo que o banco de dados já não interpreta o SQL como tendo um OR na cláusula WHERE.

Este é apenas um exemplo simplista. Na prática você vai fazer um pouco mais do que isso, pois há muitas variações sobre esse ataque. Por exemplo, você pode estruturar o SQL de forma diferente, buscar o usuário usando o nome de usuário e só então verificar manualmente que as partidas senha ou certifique-se de usar sempre variáveis ​​bind (a melhor defesa contra injeção de SQL e fortemente recomendado!). E você deve sempre escapar todos os dados de entrada usando as funções apropriadas de qualquer língua o seu site está escrito em - e não apenas dados que está sendo usado para login.
Postagem anterior
Próxima postagem

postagem escrita por: