Instrutor: Como você
viu até agora, as injeções de SQL são muito perigosas.
Além disso, eles são muito fáceis de encontrar e muito fáceis de encontrar.
Você os encontrará em todos os lugares em alguns sites realmente famosos.
As pessoas tentam evitar essas vulnerabilidades usando filtros.
Os filtros podem parecer que não há explorações,
mas se você realmente se esforçar ao usar codificações,
diferentes tipos de codificação ou usar um proxy,
poderá ignorar a maioria desses filtros.
Alguns programadores usam uma lista negra.
Por exemplo, eles impedem o uso de união, eles
impedem o uso de pastilhas e coisas assim.
Novamente, não é 100% seguro.
Pode ser ignorado.
Usando uma lista de permissões?
Exatamente os mesmos problemas da lista negra.
A melhor maneira de fazer isso é programar seu aplicativo
Web de uma maneira que não permita que o código seja injetado nele e,
em seguida, executado.
A melhor maneira de fazer isso é usar uma declaração parametrizada
onde os dados e o código são separados.
A melhor maneira de mostrar o que quero
dizer com isso é usar um exemplo.
Estou mantendo a menor quantidade de programação neste exemplo.
Não quero que seja um exemplo de programação.
Na verdade, há erros na programação, mas estou
tentando dar a você o conceito
mais do que como programá-lo.
O código vulnerável que estávamos analisando costumava fazer isso.
Ele costumava selecionar * nas contas em que o nome de usuário é igual
ao que colocamos na caixa de texto1.
Em seguida, costumávamos colocar no
textbox1, vamos
colocá-lo aqui, costumávamos dizer admin e depois
fechar a citação.
Então, podemos fazer uma união selecionar e executar
outra coisa.
Depois que terminamos, costumávamos adicionar o comentário, que basicamente
ignora tudo o que vem depois dele.
Então, quando você copiar e
colar aqui, verá o
que está acontecendo.
Agora, vamos nos livrar disso,
porque isso apenas torna as cores não agradáveis.
(murmura), na verdade, vou colocar um comentário sobre isso.
Ele fará um select * nas contas
em que o nome de usuário
é igual a admin, union union e execute o que quisermos.
Isso é muito ruim e é muito difícil de proteger.
Como eu disse, usando
filtros e outras coisas, apenas esconderemos o problema, não o corrigiremos.
A melhor maneira
de fazer isso é usar as instruções parametrizadas da mesma maneira.
Esta é a maneira segura de fazer isso.
Primeiro de tudo, você prepara sua declaração.
A maioria das linguagens como PHP
e todas elas, na verdade, têm uma função como essa.
Você pode preparar selecionar * nas contas em que o nome
de usuário é igual ao ponto de interrogação.
Então você envia os valores.
Então, o PHP agora sabe.
A instrução SQL é select * nas contas em que
o nome de usuário é igual a algo.
Então vai levar o valor da caixa de texto1.
Portanto, mesmo se entrarmos e usarmos
nossa declaração bem sorrateira
aqui e colá-la
ali, o aplicativo Web saberá que o valor
para isso é admin union select.
Na verdade, ele tenta
ir e seleciona * das contas em que o nome
de usuário e, na verdade, adiciona suas próprias
cotações e tenta encontrar um nome de usuário com o seguinte nome de usuário.
Essa coisa toda será executada assim.
Portanto, será * selecionado nas contas
em que o nome de usuário é igual ao admin union
select, esta hashtag.
O que você colocar na sua caixa de texto será enviado como um valor.
O aplicativo da web saberá que isso
é um valor, não é um código e nunca será executado.
Portanto, isso o protegerá contra injeções de SQL.
Você pode usar os filtros como segunda linha
de defesa, e também aconselho que
você use o mínimo de privilégios possível.
Para cada banco de dados, use um usuário com a
menor quantidade de privilégios que desejar.
Não permita que os usuários façam o que quiserem.
Se for um site simples que apenas faz seleção, permita
apenas que o usuário selecione.
Se precisar apenas selecionar e inserir,
permita apenas que eles selecionem e insiram.
Essa é uma regra que você deve manter com
tudo, mesmo nos sistemas Linux.
Verifique se as permissões são sempre o menos possível.
Cada usuário não possui permissões extras
desnecessárias.