ou Como Proteger os Dados do Usuário contra a Injeção De SQL
xkcd
curiosidades:
injeção de SQL tem sido em torno de muito desde sites possuem dados armazenados em bancos de dados.
O Open Web Application Security Project classificou os ataques de injeção como uma das 10 maiores ameaças enfrentadas pelas aplicações web em 2017.,
SQL injeção ainda é responsável por muitas grandes vazamentos de dados. Em 2016, as bases de dados de registro de eleitores do Illinois e Arizona State Board of Elections foram violadas. Enquanto nenhuma informação foi roubada no Arizona, em Illinois os atacantes tiveram acesso aos dados dos eleitores, incluindo nome, endereço, data de nascimento, sexo e números parciais de Segurança Social, para cerca de 80.000 pessoas.Isso é assustador, o que é?
SQL injeção é um tipo de ataque que visa a base de dados de uma aplicação através da inserção de código não intencional nos campos de entrada do Usuário., Ao tirar vantagem da sintaxe SQL o atacante pode usar campos de entrada para capturar informações dessas bases de dados — incluindo coisas como senhas e números de cartão de crédito. Alguém pode até assumir o controlo da sua base de dados ou apagar todas as informações que contém.
Como Funciona?a injecção de
SQL funciona utilizando a informação inserida num campo para manipular a declaração SQL correspondente para efectuar uma acção não intencional.,
Aqui está um exemplo básico:
SELECT * FROM customers WHERE name = " + user_name + ";
neste exemplo, digamos que a variável user_name é criada directamente a partir da entrada do utilizador num sítio Web. Essa string é inserida na instrução SQL acima e todos os campos relacionados com esse nome de usuário são devolvidos. Nada de mais.
mas o que acontece se alguém digita Steve” ou 1=1; — como seu nome de usuário? então o SQL gerado seria este:
SELECT * FROM customers WHERE name = "Steve" OR 1=1;--";
Uma vez que 1=1 é sempre verdadeiro, isto retornaria todos os dados na tabela. Nada Bom!,
Let’s take one more look at that comic.
xkcd
The son’s name is Robert’); DROP TABLE students; — What would that do exactly?,
Bem, podemos supor que, se o Pequeno Bobby Tables está sendo adicionada para a escola de banco de dados de alunos, a instrução SQL deve se parecer com algo como:
INSERT INTO students (name) VALUES ('<Student Name>');
… e quando nós inserir Bobby…
INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');
Desde Bobby nome contém o ); os VALORES argumento está fechada no meio de seu nome e o texto que se segue DROP TABLE alunos é uma nova instrução SQL que exclui toda a tabela. Finalmente o-no final comenta o SQL restante, essencialmente ignorando o resto do código original e certificando-se de que nenhum erro ocorre.,
Então, O Que Quer Dizer É A Minha Dados Nunca Serão Seguro Novamente?não! Na verdade, há um monte de passos que você pode tomar para se proteger deste tipo de ataque. Vejamos alguns:
desinfecte os dados. O primeiro passo é controlar o que o usuário pode introduzir. A melhor maneira de fazer isso é limitar os tipos de entrada permitidos para um determinado campo., Por exemplo, em um campo de número de telefone você só poderia permitir entrada numérica, ou em um campo de E-mail só permitir caracteres que podem ser encontrados em um endereço de E-mail válido. Obviamente, alguns campos exigirão personagens que poderiam ser usados em um ataque, então este método não é imbatível.
configurar a comunicação de erros. Muitas vezes, o padrão de relatórios de erros em Sistemas de gerenciamento de banco de dados tem informações de depuração de desenvolvedores nele. Isto pode devolver informações úteis ao atacante, como nomes de tabelas ou nomes de colunas., Certifique-se de que você não está mostrando este tipo de informação para usuários externos, pois isso poderia tornar a vida de um potencial atacante muito mais fácil.
utilize parâmetros ligados. Os parâmetros de encadernação permitem-lhe armazenar os dados do utilizador numa variável e introduzi-los numa declaração SQL que foi criada com substituições. Uma vez que a instrução SQL e a variável são enviadas para o servidor separadamente, os parâmetros ligados são bons em proteger contra injeção. Toma aquele pequeno Bobby T!, Um exemplo de parâmetros dependentes em um método de atualização em Ruby teria esta aparência:
def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end
É loucura pensar que algo tão simples e bem entendido ainda é responsável por muitos dos grandes violações de dados., Mesmo em casos de alto perfil como os hacks de registro de eleitores mencionados acima e a recente quebra Equifax (que não foi devido à injeção de SQL, mas a uma vulnerabilidade semelhante que a empresa não conseguiu resolver), a raiz da vulnerabilidade se resume ao erro humano e à falta de atenção ao detalhe. Tomar o tempo para pensar cuidadosamente através do problema pode nos ajudar significativamente a proteger os dados do usuário de quebras comuns, especialmente injeções SQL.
Deixe uma resposta