Injeção SQL - SQL injection

Classificação de vetores de ataque de injeção de SQL em 2010
Uma classificação do vetor de ataque por injeção de SQL a partir de 2010.

A injeção de SQL é uma técnica de injeção de código usada para atacar aplicativos baseados em dados, em que instruções SQL maliciosas são inseridas em um campo de entrada para execução (por exemplo, para despejar o conteúdo do banco de dados para o invasor). A injeção de SQL deve explorar uma vulnerabilidade de segurança no software de um aplicativo, por exemplo, quando a entrada do usuário é filtrada incorretamente para caracteres de escape literais de string incorporados nas instruções SQL ou a entrada do usuário não é fortemente digitada e executada de forma inesperada. A injeção de SQL é mais conhecida como um vetor de ataque para sites, mas pode ser usada para atacar qualquer tipo de banco de dados SQL.

Os ataques de injeção de SQL permitem que os invasores falsifiquem a identidade, adulterem os dados existentes , causem problemas de repúdio, como anulação de transações ou alteração de saldos, permitem a divulgação completa de todos os dados no sistema, destroem os dados ou os tornam indisponíveis de outra forma e tornam-se administradores do servidor de banco de dados.

Em um estudo de 2012, foi observado que o aplicativo da web médio recebeu quatro campanhas de ataque por mês, e os varejistas receberam duas vezes mais ataques do que outras indústrias.

História

As primeiras discussões públicas sobre injeção de SQL começaram a aparecer por volta de 1998; por exemplo, um artigo de 1998 na Phrack Magazine .

Forma

A injeção de SQL (SQLI) foi considerada uma das 10 principais vulnerabilidades de aplicativos da web de 2007 e 2010 pelo Open Web Application Security Project . Em 2013, o SQLI foi classificado como o ataque número um entre os dez principais OWASP. Existem quatro subclasses principais de injeção de SQL:

  • Injeção SQL + autenticação insuficiente
  • Injeção de SQL + ataques DDoS
  • Injeção de SQL + sequestro de DNS
  • Injeção SQL + XSS

O Storm Worm é uma representação do SQLI composto.

Esta classificação representa o estado do SQLI, respeitando sua evolução até 2010 - mais refinamento está em andamento.

Implementações técnicas

Instruções SQL construídas incorretamente

Essa forma de injeção se baseia no fato de que as instruções SQL consistem em dados usados ​​pela instrução SQL e em comandos que controlam como a instrução SQL é executada. Por exemplo, na instrução SQL, a string ' ' são dados e o fragmento é um exemplo de um comando (o valor também são dados neste exemplo). select * from person where name = 'susan' and age = 2susanand age = 22

A injeção de SQL ocorre quando uma entrada de usuário especialmente criada é processada pelo programa receptor de uma forma que permite que a entrada saia de um contexto de dados e entre em um contexto de comando. Isso permite que o invasor altere a estrutura da instrução SQL que é executada.

Como um exemplo simples, imagine que os dados ' susan' na instrução acima foram fornecidos pela entrada do usuário. O usuário inseriu a string ' susan' (sem os apóstrofos) em um campo de entrada de texto de formulário da web e o programa usou instruções de concatenação de string para formar a instrução SQL acima a partir dos três fragmentos , a entrada do usuário de ' ' e . select * from person where name='susan' and age = 2

Agora imagine que em vez de entrar ' susan' o atacante entrou . ' or 1=1; --

O programa usará a mesma abordagem de concatenação de string com os 3 fragmentos de , a entrada do usuário de e e construirá a instrução . Muitos bancos de dados irão ignorar o texto após a string '-', pois isso denota um comentário. A estrutura do comando SQL é agora e isso selecionará todas as linhas de pessoa em vez de apenas aquelas chamadas 'susan' cuja idade é 2. O invasor conseguiu criar uma string de dados que sai do contexto de dados e entrou em um contexto de comando. select * from person where name='' or 1=1; --' and age = 2select * from person where name='' or 1=1; -- and age = 2select * from person where name='' or 1=1;

Um exemplo mais complexo é apresentado agora.

Imagine que um programa crie uma instrução SQL usando o seguinte comando de atribuição de string:

var statement = "SELECT * FROM users WHERE name = '" + userName + "'";

Este código SQL é projetado para obter os registros do nome de usuário especificado de sua tabela de usuários. No entanto, se a variável "userName" for criada de uma maneira específica por um usuário mal-intencionado, a instrução SQL pode fazer mais do que o autor do código pretendia. Por exemplo, definindo a variável "userName" como:

' OR '1'='1

ou usando comentários para bloquear o resto da consulta (existem três tipos de comentários SQL). Todas as três linhas têm um espaço no final:

' OR '1'='1' --
' OR '1'='1' {
' OR '1'='1' /* 

renderiza uma das seguintes instruções SQL pela linguagem pai:

SELECT * FROM users WHERE name = '' OR '1'='1';
SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

Se este código fosse usado no procedimento de autenticação, então este exemplo poderia ser usado para forçar a seleção de todos os campos de dados (*) de todos os usuários, em vez de um nome de usuário específico como o codificador pretendia, porque a avaliação de '1' = '1' é sempre verdadeiro.

O seguinte valor de "userName" na instrução abaixo causaria a exclusão da tabela "users", bem como a seleção de todos os dados da tabela "userinfo" (em essência revelando as informações de cada usuário), usando uma API que permite várias declarações:

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Essa entrada renderiza a instrução SQL final da seguinte maneira e especificada:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Enquanto a maioria das implementações de servidor SQL permite que várias instruções sejam executadas com uma chamada desta forma, algumas APIs SQL, como a função do PHP , mysql_query()não permitem isso por razões de segurança. Isso evita que os invasores injetem consultas totalmente separadas, mas não os impede de modificar as consultas.

Injeção cega de SQL

A injeção cega de SQL é usada quando um aplicativo da Web é vulnerável a uma injeção de SQL, mas os resultados da injeção não são visíveis para o invasor. A página com a vulnerabilidade pode não ser aquela que exibe dados, mas será exibida de forma diferente dependendo dos resultados de uma instrução lógica injetada na instrução SQL legítima chamada para essa página. Esse tipo de ataque tem sido tradicionalmente considerado demorado porque uma nova instrução precisava ser criada para cada bit recuperado e, dependendo de sua estrutura, o ataque pode consistir em muitas solicitações malsucedidas. Avanços recentes permitiram que cada solicitação recuperasse vários bits, sem solicitações malsucedidas, permitindo uma extração mais consistente e eficiente. Existem várias ferramentas que podem automatizar esses ataques, uma vez que a localização da vulnerabilidade e as informações de destino tenham sido estabelecidas.

Respostas condicionais

Um tipo de injeção cega de SQL força o banco de dados a avaliar uma instrução lógica em uma tela de aplicativo comum. Por exemplo, um site de resenhas de livros usa uma string de consulta para determinar qual resenha de livro exibir. Portanto, o URL https://books.example.com/review?id=5 faria com que o servidor executasse a consulta

SELECT * FROM bookreviews WHERE ID = '5';

a partir do qual iria preencher a página de revisão com dados da revisão com ID 5, armazenados nas revisões de livros da tabela . A consulta ocorre completamente no servidor; o usuário não sabe os nomes do banco de dados, tabela ou campos, nem conhece a string de consulta. O usuário só vê que o URL acima retorna uma resenha de livro. Um hacker pode carregar os URLs e , o que pode resultar em consultas https://books.example.com/review?id=5 OR 1=1https://books.example.com/review?id=5 AND 1=2

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

respectivamente. Se a revisão original carrega com o URL "1 = 1" e uma página em branco ou de erro é retornada do URL "1 = 2" e a página retornada não foi criada para alertar o usuário que a entrada é inválida, ou em outro palavras, foi capturado por um script de teste de entrada, o site está provavelmente vulnerável a um ataque de injeção de SQL, pois a consulta provavelmente terá passado com êxito em ambos os casos. O hacker pode prosseguir com esta string de consulta projetada para revelar o número da versão do MySQL rodando no servidor:, o que mostraria a crítica do livro em um servidor rodando MySQL 4 e uma página em branco ou de erro caso contrário. O hacker pode continuar a usar o código dentro de strings de consulta para atingir seu objetivo diretamente ou para obter mais informações do servidor na esperança de descobrir outra via de ataque. https://books.example.com/review?id=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4

Injeção SQL de segunda ordem

A injeção SQL de segunda ordem ocorre quando os valores enviados contêm comandos maliciosos que são armazenados em vez de executados imediatamente. Em alguns casos, o aplicativo pode codificar corretamente uma instrução SQL e armazená-la como um SQL válido. Então, outra parte desse aplicativo sem controles para proteger contra injeção de SQL pode executar essa instrução SQL armazenada. Este ataque requer mais conhecimento de como os valores enviados são usados ​​posteriormente. Os scanners de segurança de aplicativos da web automatizados não detectariam facilmente esse tipo de injeção de SQL e podem precisar ser instruídos manualmente sobre onde verificar se há evidências de que está sendo tentada.

Mitigação

Uma injeção de SQL é um ataque bem conhecido e facilmente evitado por medidas simples. Depois de um aparente ataque de injeção de SQL no TalkTalk em 2015, a BBC relatou que os especialistas em segurança ficaram surpresos com o fato de uma empresa tão grande estar vulnerável a ele.

Mapeadores Relacionais de Objeto

Os desenvolvedores podem usar estruturas ORM como o Hibernate para criar consultas de banco de dados de maneira segura e amigável ao desenvolvedor. Uma vez que as consultas de banco de dados não são mais construídas como strings, não há perigo de uma vulnerabilidade de injeção.

Firewalls de aplicativos da web

Embora os produtos WAF, como o ModSecurity CRS, não possam impedir que vulnerabilidades de injeção de SQL se infiltrem em uma base de código, eles podem tornar a descoberta e a exploração significativamente mais desafiadoras para um invasor.

Detecção

A filtragem de injeção de SQL funciona de maneira semelhante aos filtros de spam de e-mails. Os firewalls de banco de dados detectam injeções de SQL com base no número de consultas inválidas do host, a presença de blocos OR e UNION dentro da solicitação ou outras características.

Declarações parametrizadas

Com a maioria das plataformas de desenvolvimento, instruções parametrizadas que funcionam com parâmetros podem ser usadas (às vezes chamadas de marcadores ou variáveis ​​de ligação ) em vez de incorporar a entrada do usuário na instrução. Um marcador de posição só pode armazenar um valor do tipo fornecido e não um fragmento SQL arbitrário. Portanto, a injeção de SQL seria simplesmente tratada como um valor de parâmetro estranho (e provavelmente inválido). Em muitos casos, a instrução SQL é fixa e cada parâmetro é um escalar , não uma tabela . A entrada do usuário é então atribuída (associada) a um parâmetro.

Colocado facilmente, o uso de consultas parametrizadas pode impedir definitivamente a injeção de SQL. Isso significa principalmente que suas variáveis ​​não são strings de consulta que aceitariam entradas SQL arbitrárias; no entanto, alguns parâmetros de determinados tipos são definitivamente necessários. Consultas parametrizadas exigem que o desenvolvedor defina todo o código. Portanto, sem consultas parametrizadas, qualquer pessoa poderia colocar qualquer tipo de código SQL no campo e ter o banco de dados apagado. Mas se os parâmetros fossem definidos como '@username', então a pessoa só seria capaz de inserir um nome de usuário sem qualquer tipo de código.

Aplicação no nível de codificação

O uso de bibliotecas de mapeamento relacional de objeto evita a necessidade de escrever código SQL. A biblioteca ORM em vigor irá gerar instruções SQL parametrizadas a partir do código orientado a objetos.

Fugindo

Uma maneira popular, embora sujeita a erros e, em última análise, condenada ao fracasso, de evitar injeções é tentar escapar de todos os caracteres que têm um significado especial no SQL. O manual para um SQL DBMS explica quais caracteres têm um significado especial, o que permite criar uma lista negra abrangente de caracteres que precisam de tradução. Por exemplo, cada ocorrência de aspas simples ( ') em um parâmetro deve ser substituída por duas aspas simples ( '') para formar um literal de string SQL válido. Por exemplo, em PHP , é comum escapar parâmetros usando a função mysqli_real_escape_string();antes de enviar a consulta SQL:

$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($username),
                  $mysqli->real_escape_string($password));
$mysqli->query($query);

Esta função prepends barras invertidas para os seguintes caracteres: \x00, \n, \r, \, ', "e \x1a. Esta função é normalmente usada para tornar os dados seguros antes de enviar uma consulta ao MySQL .
PHP tem funções semelhantes para outros sistemas de banco de dados, como pg_escape_string () para PostgreSQL . A função addslashes(string $str)funciona para caracteres de escape e é usada especialmente para consultas em bancos de dados que não possuem funções de escape no PHP. Ele retorna uma string com barras invertidas antes dos caracteres que precisam ser escapados em consultas de banco de dados, etc. Esses caracteres são aspas simples ('), aspas duplas ("), barra invertida (\) e NUL (o byte NULL).
Passando rotineiramente strings escapadas para SQL está sujeito a erros porque é fácil esquecer de escapar de uma determinada string. Criar uma camada transparente para proteger a entrada pode reduzir essa tendência a erros, se não eliminá-la totalmente.

Verificação de padrão

Parâmetros de string inteiros, flutuantes ou booleanos podem ser verificados se seu valor é uma representação válida para o tipo fornecido. As strings que devem seguir algum padrão estrito (data, UUID, alfanumérico apenas, etc.) podem ser verificadas se corresponderem a esse padrão.

Permissões de banco de dados

Limitar as permissões no login do banco de dados usado pelo aplicativo da web para apenas o que é necessário pode ajudar a reduzir a eficácia de quaisquer ataques de injeção de SQL que exploram quaisquer bugs no aplicativo da web.

Por exemplo, no Microsoft SQL Server , um logon de banco de dados pode ser impedido de selecionar algumas das tabelas do sistema, o que limitaria as explorações que tentam inserir JavaScript em todas as colunas de texto no banco de dados.

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Exemplos

  • Em fevereiro de 2002, Jeremiah Jacks descobriu que o Guess.com era vulnerável a um ataque de injeção de SQL, permitindo que qualquer pessoa capaz de construir um URL criado de maneira adequada extraísse mais de 200.000 nomes, números de cartão de crédito e datas de vencimento no banco de dados de clientes do site.
  • Em 1o de novembro de 2005, um hacker adolescente usou injeção de SQL para invadir o site de uma revista de segurança da informação taiwanesa do grupo Tech Target e roubar informações dos clientes.
  • Em 13 de janeiro de 2006, criminosos de informática russos invadiram um site do governo de Rhode Island e supostamente roubaram dados de cartão de crédito de indivíduos que fizeram negócios online com agências estatais.
  • Em 29 de março de 2006, um hacker descobriu uma falha de injeção SQL em um funcionário do governo indiano de turismo local.
  • Em 29 de junho de 2007, um criminoso de computador desfigurou o site da Microsoft no Reino Unido usando injeção de SQL. O site The Register citou um porta-voz da Microsoft reconhecendo o problema.
  • Em 19 de setembro de 2007 e 26 de janeiro de 2009, o grupo de hackers turco "m0sted" usou injeção de SQL para explorar o SQL Server da Microsoft para hackear servidores da Web pertencentes à McAlester Army Ammunition Plant e ao US Army Corps of Engineers, respectivamente.
  • Em janeiro de 2008, dezenas de milhares de PCs foram infectados por um ataque de injeção automática de SQL que explorou uma vulnerabilidade no código do aplicativo que usa o Microsoft SQL Server como armazenamento de banco de dados.
  • Em julho de 2008, o site da Kaspersky na Malásia foi invadido pelo grupo de hackers "m0sted" usando injeção de SQL.
  • Em 13 de abril de 2008, o Registro de Criminosos Sexuais e Violentos de Oklahoma fechou seu site para " manutenção de rotina " depois de ser informado de que 10.597 números da Previdência Social pertencentes a criminosos sexuais haviam sido baixados por meio de um ataque de injeção de SQL
  • Em maio de 2008, um farm de servidores na China usou consultas automatizadas ao mecanismo de busca do Google para identificar sites de servidores SQL que eram vulneráveis ​​ao ataque de uma ferramenta automatizada de injeção de SQL.
  • Em 2008, pelo menos de abril a agosto, uma série de ataques começou a explorar as vulnerabilidades de injeção de SQL do servidor web IIS da Microsoft e do servidor de banco de dados SQL Server . O ataque não exige adivinhar o nome de uma tabela ou coluna e corrompe todas as colunas de texto em todas as tabelas em uma única solicitação. Uma string HTML que faz referência a um arquivo JavaScript de malware é anexada a cada valor. Quando esse valor de banco de dados é posteriormente exibido para um visitante do site, o script tenta várias abordagens para obter controle sobre o sistema de um visitante. O número de páginas da web exploradas é estimado em 500.000.
  • Em 17 de agosto de 2009, o Departamento de Justiça dos Estados Unidos acusou um cidadão americano, Albert Gonzalez , e dois russos não identificados pelo roubo de 130 milhões de números de cartão de crédito usando um ataque de injeção de SQL. No alegado "o maior caso de roubo de identidade da história americana", o homem roubou cartões de várias vítimas corporativas após pesquisar seus sistemas de processamento de pagamento . Entre as empresas atingidas estavam a processadora de cartão de crédito Heartland Payment Systems , a rede de lojas de conveniência 7-Eleven e a rede de supermercados Hannaford Brothers .
  • Em dezembro de 2009, um invasor violou um banco de dados de texto simples RockYou contendo os nomes de usuário e senhas não criptografados de cerca de 32 milhões de usuários usando um ataque de injeção de SQL.
  • Em julho de 2010, um pesquisador de segurança sul-americano que atende pelo apelido de "Ch Russo" obteve informações confidenciais do usuário do popular site do BitTorrent The Pirate Bay . Ele obteve acesso ao painel de controle administrativo do site e explorou uma vulnerabilidade de injeção de SQL que lhe permitiu coletar informações de contas de usuários, incluindo endereços IP , hashes de senha MD5 e registros de quais torrents os usuários individuais enviaram.
  • De 24 a 26 de julho de 2010, invasores do Japão e da China usaram uma injeção de SQL para obter acesso aos dados de cartão de crédito dos clientes da Neo Beat, uma empresa com sede em Osaka que administra um grande site de supermercado online. O ataque também afetou sete parceiros de negócios, incluindo cadeias de supermercados Izumiya Co, Maruetsu Inc e Ryukyu Jusco Co. O roubo de dados afetou 12.191 clientes. Em 14 de agosto de 2010, foi relatado que houve mais de 300 casos de informações de cartão de crédito sendo usadas por terceiros para comprar bens e serviços na China.
  • Em 19 de setembro durante a eleição geral sueca 2010 um eleitor tentou uma injeção de código por comandos de escrita SQL mão como parte de um write-in voto.
  • Em 8 de novembro de 2010, o site da Marinha Real Britânica foi comprometido por um hacker romeno chamado TinKode usando injeção de SQL.
  • Em 5 de fevereiro de 2011, a HBGary , uma empresa de segurança de tecnologia, foi invadida pelo LulzSec usando uma injeção de SQL em seu site baseado em CMS
  • Em 27 de março de 2011, www.mysql.com, a página inicial oficial do MySQL , foi comprometido por um hacker usando injeção cega de SQL
  • Em 11 de abril de 2011, a Barracuda Networks foi comprometida usando uma falha de injeção de SQL. Endereços de e -mail e nomes de usuários de funcionários estão entre as informações obtidas.
  • Durante um período de 4 horas em 27 de abril de 2011, um ataque de injeção automática de SQL ocorreu no site Broadband Reports que foi capaz de extrair 8% dos pares de nome de usuário / senha: 8.000 contas aleatórias das 9.000 contas ativas e 90.000 contas antigas ou inativas.
  • Em 1º de junho de 2011, " hacktivistas " do grupo LulzSec foram acusados ​​de usar SQLI para roubar cupons , baixar chaves e senhas que eram armazenadas em texto simples no site da Sony , acessando informações pessoais de um milhão de usuários.
  • Em junho de 2011, o PBS foi hackeado pelo LulzSec, provavelmente por meio do uso de injeção de SQL; o processo completo usado por hackers para executar injeções de SQL foi descrito neste blog da Imperva .
  • Em maio de 2012, o site do Wurm Online , um jogo online multijogador massivo , foi fechado por injeção de SQL enquanto o site estava sendo atualizado.
  • Em julho de 2012 , foi relatado que um grupo de hackers roubou 450.000 credenciais de login do Yahoo! . Os logins foram armazenados em texto simples e supostamente retirados de um subdomínio do Yahoo , Yahoo! Vozes . O grupo violou a segurança do Yahoo usando uma " técnica de injeção SQL baseada em união ".
  • Em 1 de outubro de 2012, um grupo de hackers chamado "Team GhostShell" publicou os registros pessoais de alunos, professores, funcionários e ex-alunos de 53 universidades, incluindo Harvard , Princeton , Stanford , Cornell , Johns Hopkins e a Universidade de Zurique no pastebin. com . Os hackers alegaram que estavam tentando "aumentar a conscientização sobre as mudanças feitas na educação de hoje", lamentando as mudanças nas leis de educação na Europa e os aumentos nas mensalidades nos Estados Unidos .
  • Em fevereiro de 2013, um grupo de hackers das Maldivas invadiu o site "ONU-Maldivas" usando SQL Injection.
  • Em 27 de junho de 2013, o grupo de hackers " RedHack " violou o Site de Administração de Istambul. Eles alegaram que conseguiram liquidar as dívidas das pessoas com água, gás, Internet, eletricidade e companhias telefônicas. Além disso, eles publicaram o nome de usuário e a senha do administrador para que outros cidadãos pudessem fazer login e liquidar suas dívidas de manhã cedo. Eles anunciaram a notícia no Twitter.
  • Em 4 de novembro de 2013, o grupo hacktivista "RaptorSwag" supostamente comprometeu 71 bancos de dados do governo chinês usando um ataque de injeção de SQL na Câmara de Comércio Internacional da China. Os dados vazados foram postados publicamente em cooperação com o Anonymous .
  • Em 2 de fevereiro de 2014, a AVS TV teve 40.000 contas vazadas por um grupo de hackers chamado @deletesec
  • Em 21 de fevereiro de 2014, o Fórum de Governança da Internet das Nações Unidas teve 3.215 detalhes de contas vazados.
  • Em 21 de fevereiro de 2014, hackers de um grupo chamado @deletesec hackearam a Spirol International depois de supostamente ameaçar prender os hackers por relatar a vulnerabilidade de segurança. 70.000 detalhes do usuário foram expostos durante este conflito.
  • Em 7 de março de 2014, funcionários da Universidade Johns Hopkins anunciaram publicamente que seus servidores de engenharia biomédica foram vítimas de um ataque de injeção de SQL realizado por um hacker Anonymous chamado "Hooky" e alinhado com o grupo hacktivista "RaptorSwag". Os hackers comprometeram dados pessoais de 878 alunos e funcionários, postando um comunicado à imprensa e os dados vazados na internet.
  • Em agosto de 2014, a empresa de segurança de computador Hold Security , sediada em Milwaukee , revelou que descobriu um roubo de informações confidenciais de cerca de 420.000 sites por meio de injeções de SQL. O New York Times confirmou essa descoberta ao contratar um especialista em segurança para verificar a reclamação.
  • Em outubro de 2015, um ataque de injeção de SQL foi usado para roubar os dados pessoais de 156.959 clientes dos servidores da empresa britânica de telecomunicações TalkTalk , explorando uma vulnerabilidade em um portal da web legado.
  • Em agosto de 2020, um ataque de injeção de SQL foi usado para acessar informações sobre os interesses românticos de muitos alunos de Stanford , como resultado de padrões inseguros de sanitização de dados por parte da Link, uma start-up fundada no campus pelo estudante Ishan Gandhi.
  • No início de 2021, 70 gigabytes de dados foram exfiltrados do site de extrema direita Gab por meio de um ataque de injeção de SQL. A vulnerabilidade foi introduzida na base de código do Gab por Fosco Marotto, CTO do Gab . Um segundo ataque contra Gab foi lançado na semana seguinte usando tokens OAuth2 roubados durante o primeiro ataque.

Na cultura popular

  • O login não autorizado em sites por meio de injeção de SQL forma a base de uma das subtramas do romance de 2012 de JK Rowling , The Casual Vacancy .
  • Um cartoon xkcd de 2007 envolveu um personagem Robert '); DROP TABLE students; - nomeado para realizar uma injeção SQL. Como resultado desse desenho, a injeção de SQL às vezes é chamada informalmente de "Tabelas de Bobby".
  • Em 2014, um indivíduo na Polônia renomeou legalmente sua empresa para Dariusz Jakubowski x '; Usuários DROP TABLE; SELECT '1 em uma tentativa de interromper a operação de bots de coleta de spammers .
  • O jogo Hacknet 2015 tem um programa de hacking chamado SQL_MemCorrupt. É descrito como injetar uma entrada de tabela que causa um erro de corrupção em um banco de dados SQL e, em seguida, consultar essa tabela, causando um travamento do banco de dados SQL e um dump de memória.
  • No episódio de 2019 Star Trek: Discovery If Memory Serves, o comandante Airiam descobriu que uma sonda que atacou um armazenamento de dados em uma das naves da nave havia feito uma série de injeções de SQL, mas que ela não conseguiu encontrar nenhum arquivo comprometido.

Veja também

Referências

links externos