SQL Injection

Até aqui, quem escrevia o SQL era você. Num site ou num aplicativo, quem escreve é um programa, e muitas vezes ele junta um pedaço fixo de SQL com o que a pessoa digitou num formulário. Se essa junção for feita do jeito ingênuo, quem digita pode escrever SQL no lugar do dado e mudar a consulta: ver a tabela inteira de clientes, entrar sem senha, ler os salários dos funcionários. Esse problema se chama SQL Injection ("injeção de SQL") e é uma das falhas mais antigas e mais comuns da web. Nesta aula você vai ver o problema acontecer de verdade, no editor e num programa Python da Ana, para aprender a se proteger dele.

Os exemplos em SQL rodam no editor do guia, contra o banco da Loja Aurora. Cada Rodar parte do banco limpo, então você pode testar à vontade: nada se perde. Os programas em Python rodaram de verdade na máquina da Ana, no banco ~/loja.db.

A ideia: o bilhete preenchido pelo cliente

Imagine que, na Loja Aurora, o atendente usa um bloco de bilhetes já impressos para pedir uma ficha ao arquivo:

Buscar no arquivo a ficha do cliente com este email: ____________

Alguém preenche a linha em branco e o arquivista faz exatamente o que está escrito no bilhete, sem pensar. Um cliente honesto escreve o próprio email. Um espertinho escreve:

Buscar no arquivo a ficha do cliente com este email: ninguém; e, já que veio aqui, traga TODAS as fichas

O arquivista lê o bilhete inteiro como uma ordem só e traz o arquivo todo. O problema não é o arquivista, que só obedece. O problema é que o dado (o que foi escrito na linha) e a ordem (o texto impresso) foram parar no mesmo papel, sem nada que separe um do outro. No SQL Injection é igual: o banco obedece ao texto que recebe, e o programa deixou o visitante escrever um pedaço desse texto.

1. Como um programa monta uma consulta

A Ana fez um programinha em Python que procura um cliente pelo email. Ele pergunta o email, cola o que foi digitado no meio do SQL e manda para o banco:

import sqlite3

con = sqlite3.connect("loja.db")
email = input("Email do cliente: ")

sql = "SELECT nome, email FROM clientes WHERE email = '" + email + "'"
print("SQL montado:", sql)

linhas = con.execute(sql).fetchall()
for linha in linhas:
    print(linha)
print(len(linhas), "linha(s)")

input("Email do cliente: ")

Mostra a pergunta e espera a pessoa digitar. O que ela digitar vai para a variável email.

"…WHERE email = '" + email + "'"

A linha frágil. Ela junta (com o +) três pedaços de texto: o começo do SQL até a aspa que abre, o que a pessoa digitou e a aspa que fecha.

print("SQL montado:", sql)

Mostra o SQL que vai para o banco. Programas de verdade não fazem isso; está aqui só para você ver a montagem.

con.execute(sql)

Manda o texto pronto para o SQLite rodar. O banco não sabe que parte veio da Ana e que parte veio do visitante: para ele, é tudo SQL.

Com um email normal, tudo funciona:

$ python3 busca.py
Email do cliente: ana.beatriz@exemplo.com.br      « a Ana digita o email e aperta Enter
SQL montado: SELECT nome, email FROM clientes WHERE email = 'ana.beatriz@exemplo.com.br'
('Ana Beatriz Sousa', 'ana.beatriz@exemplo.com.br')
1 linha(s)

É a mesma consulta que você escreveria no editor:

SELECT nome, email FROM clientes WHERE email = 'ana.beatriz@exemplo.com.br';

2. Quando o texto digitado vira SQL: ' OR '1'='1

Agora alguém digita, no lugar do email, este texto: ' OR '1'='1. O programa cola tudo do mesmo jeito, sem desconfiar:

$ python3 busca.py
Email do cliente: ' OR '1'='1
SQL montado: SELECT nome, email FROM clientes WHERE email = '' OR '1'='1'
('José Ribamar Silva', 'jose.ribamar@exemplo.com.br')
('Maria Clara Mendes', 'maria.clara@exemplo.com.br')
('Ana Beatriz Sousa', 'ana.beatriz@exemplo.com.br')
('Carlos Eduardo Lima', 'carlos.lima@exemplo.com.br')
('Conceição Prado', 'conceicao.prado@exemplo.com.br')
('Rafael Monteiro', 'rafael.monteiro@exemplo.com.br')
('Luís Otávio Brito', None)
('Fernanda Carvalho', 'fernanda.carvalho@exemplo.com.br')
('Antônio Carlos Neves', 'antonio.neves@exemplo.com.br')
('Juliana Paes Barbosa', 'juliana.barbosa@exemplo.com.br')
('Marcos Vinícius Rocha', 'marcos.rocha@exemplo.com.br')
('Patrícia Gusmão', 'patricia.gusmao@exemplo.com.br')
('Tiago Fontes', 'tiago.fontes@exemplo.com.br')
('Camila Duarte', 'camila.duarte@exemplo.com.br')
('Roberto Falcão', None)
('Larissa Macêdo', 'larissa.macedo@exemplo.com.br')
('Gustavo Henrique Prado', 'gustavo.prado@exemplo.com.br')
('Ana Carvalho Lima', 'ana.carvalho@exemplo.com.br')
('Bruno Cavalcante', 'bruno.cavalcante@exemplo.com.br')
('Vitória Régia Campos', 'vitoria.campos@exemplo.com.br')
('Sebastião Moura', 'sebastiao.moura@exemplo.com.br')
('Débora Cristina Alves', 'debora.alves@exemplo.com.br')
('Henrique Sales', None)
('Isabela Franco', 'isabela.franco@exemplo.com.br')
('Otávio Bezerra', 'otavio.bezerra@exemplo.com.br')
('Mirela Pontes', 'mirela.pontes@exemplo.com.br')
('Paulo Sérgio Andrade', 'paulo.andrade@exemplo.com.br')
('Tainá Soares', 'taina.soares@exemplo.com.br')
('Elias Furtado', 'elias.furtado@exemplo.com.br')
('Rosângela Dias', 'rosangela.dias@exemplo.com.br')
30 linha(s)          « os 30 clientes da loja, com o email de todos

O programa devia mostrar um cliente e mostrou os 30. Rode a consulta montada no editor e veja a tabela inteira aparecer:

SELECT nome, email FROM clientes WHERE email = '' OR '1'='1';

O que mudou está nas aspas. Olhe o SQL montado com o que o visitante digitou marcado entre colchetes:

SELECT nome, email FROM clientes WHERE email = '[' OR '1'='1]'
                                                ↑  └── digitado ──┘↑
                                       aspa do programa      aspa do programa

email = ''

A primeira aspa que a pessoa digitou fecha o texto que o programa tinha aberto. Para o banco, o email procurado é o texto vazio.

OR '1'='1'

Depois do texto vazio sobra isto, que o banco agora lê como SQL, não como dado: "ou então, quando '1' for igual a '1'". E '1' é sempre igual a '1'.

a última aspa

A aspa que o programa colou no fim casa com a última aspa digitada, então o SQL fica bem-formado e o banco não reclama.

Como a condição OR '1'='1' é verdadeira em toda linha, o WHERE deixa passar a tabela inteira. Foi o "traga todas as fichas" do bilhete. Repare: quem digitou nem precisava saber um email de verdade.

SELECT nome, email FROM clientes WHERE email = '' OR '1'='1';

SELECT nome, email FROM clientes WHERE email = 'ana.beatriz@exemplo.com.br';

3. Entrar sem senha, com um comentário

O estrago cresce quando a consulta decide quem entra num sistema. Imagine uma tabela de logins (vamos criá-la aqui só para a demonstração) e um programa que confere login e senha montando o SQL por colagem:

SELECT login FROM usuarios
WHERE login = 'DIGITADO' AND senha = 'DIGITADO';

Se vier uma linha, o programa deixa entrar. Veja o que acontece quando o invasor digita, no campo do login, caio'-- e deixa a senha em branco. As duas aspas e os dois tracinhos fazem o serviço:

CREATE TABLE usuarios (login TEXT, senha TEXT);
INSERT INTO usuarios VALUES ('ana', 'girassol42'), ('caio', 'teresina2024');

SELECT login FROM usuarios
WHERE login = 'caio'--' AND senha = 'qualquer';

login = 'caio'

A aspa digitada depois de caio fecha o texto. O banco entende: login igual a caio.

--

Em SQL, -- começa um comentário: daí até o fim da linha, o banco ignora tudo (veja a aula Comentários). Some a parte AND senha = '…'.

o resto da linha

Fica dentro do comentário, então a checagem da senha nunca acontece. A consulta devolve a linha do caio, e o programa deixa entrar sem conferir a senha.

Rodou e devolveu a linha caio: para o programa, login aprovado. O invasor entrou na conta de alguém só sabendo (ou chutando) o nome de login.

4. Ler outra tabela com UNION

Lembra do UNION (aula UNION), que empilha o resultado de duas consultas? Se a consulta frágil mostra uma lista na tela, quem ataca pode pendurar um SELECT de outra tabela no fim e fazer esses dados aparecerem no lugar da lista.

A loja tem uma busca de produtos pelo nome. O invasor digita um texto que fecha o LIKE, acrescenta um UNION SELECT dos salários dos funcionários e comenta o resto. Como os salários não são para o público, isso é um vazamento:

SELECT nome, preco FROM produtos WHERE nome LIKE '%zzz' UNION SELECT nome, salario FROM funcionarios --%';

LIKE '%zzz'

Nenhum produto casa com %zzz, então a primeira consulta vem vazia. O invasor fez de propósito: ele quer só a segunda metade.

UNION SELECT nome, salario FROM funcionarios

Empilha os salários. Para o UNION funcionar, as duas consultas precisam do mesmo número de colunas; por isso o invasor escolheu duas (nome e salario), casando com nome, preco.

--%'

O -- comenta o pedaço %' que o programa ia colar no fim, para o SQL não ficar quebrado.

No lugar dos produtos, apareceu a folha de pagamento. Em sistemas reais, esse mesmo truque já serviu para ler tabelas de senhas e de cartões. O invasor costuma descobrir quantas colunas usar testando aos poucos; os detalhes não importam aqui — o que importa é a causa, sempre a mesma: texto digitado virou SQL.

5. "Mas a minha biblioteca só roda um comando" — e os dois tracinhos

Você pode ter ouvido que o perigo do SQL Injection é alguém mandar um segundo comando junto, separado por ;, como um DELETE ou um DROP TABLE grudado na consulta. Isso existe, mas muitas bibliotecas recusam dois comandos numa chamada só. O sqlite3 do Python é uma delas. Quando a Ana manda, pela colagem, um texto com ; no meio, o próprio Python barra:

$ echo "'; DELETE FROM clientes; --" | python3 busca.py
Email do cliente: SQL montado: SELECT nome, email FROM clientes WHERE email = ''; DELETE FROM clientes; --'
Traceback (most recent call last):
  File "/home/ana/busca.py", line 9, in <module>
    linhas = con.execute(sql).fetchall()
             ~~~~~~~~~~~^^^^^
sqlite3.ProgrammingError: You can only execute one statement at a time.

A mensagem diz, em inglês: "você só pode executar um comando por vez". O método execute() do Python compila e roda só o primeiro comando do texto. Isso é parecido com o que a biblioteca C do SQLite faz por baixo: a documentação oficial da função sqlite3_prepare_v2 diz que ela "só compila o primeiro comando" do texto e deixa o resto de lado.

E por que o -- dos ataques some com o resto da linha? Porque, como você viu na aula Comentários, -- começa um comentário até o fim da linha. O invasor usa isso para "cortar fora" o pedaço de SQL que o programa ia colar depois do dado dele.

6. A defesa de verdade: parâmetros

A causa de tudo é sempre a mesma: o dado e o SQL andaram juntos no mesmo texto. A solução é separá-los. Em vez de colar o valor dentro do SQL, você deixa um espaço reservado (um ?) e entrega o valor por fora, numa lista à parte. O banco monta a consulta primeiro e só depois encaixa o valor, tratando-o sempre como dado, nunca como comando. Isso se chama consulta com parâmetros (ou prepared statement), e tem aula só para ela: Consultas com Parâmetros.

Veja o mesmo programa da Ana, agora com ? no lugar da colagem:

import sqlite3

con = sqlite3.connect("loja.db")
email = input("Email do cliente: ")

sql = "SELECT nome, email FROM clientes WHERE email = ?"
print("SQL enviado:", sql)

linhas = con.execute(sql, (email,)).fetchall()
for linha in linhas:
    print(linha)
print(len(linhas), "linha(s)")

WHERE email = ?

O ? é o espaço reservado. O SQL agora é fixo: não muda com o que a pessoa digita. Repare que não há aspa nenhuma em volta do ?.

con.execute(sql, (email,))

O valor vai no segundo argumento, numa lista à parte. O banco recebe a consulta e o valor por caminhos separados e encaixa o valor como dado.

Agora o ataque não cola mais. O mesmo ' OR '1'='1 de antes é tratado como um email literal — e, como nenhum cliente tem esse email esquisito, a busca volta vazia:

$ echo "ana.beatriz@exemplo.com.br" | python3 busca_segura.py
Email do cliente: SQL enviado: SELECT nome, email FROM clientes WHERE email = ?
('Ana Beatriz Sousa', 'ana.beatriz@exemplo.com.br')
1 linha(s)
$ echo "' OR '1'='1" | python3 busca_segura.py
Email do cliente: SQL enviado: SELECT nome, email FROM clientes WHERE email = ?
0 linha(s)          « o texto do ataque virou um email comum: ninguém tem esse email
$ echo "'; DELETE FROM clientes; --" | python3 busca_segura.py
Email do cliente: SQL enviado: SELECT nome, email FROM clientes WHERE email = ?
0 linha(s)          « idem: procurou por um "email" bem esquisito, não achou

Repare que o SQL enviado é sempre o mesmo, …email = ?. O que a pessoa digita nunca mais vira comando. Essa é a regra de ouro: todo valor que vem de fora entra por parâmetro.

7. O sinal de alarme honesto: o apóstrofo no nome

Você não precisa de um invasor para descobrir que o seu código cola texto. Basta um cliente de verdade com apóstrofo no nome. A Loja Aurora tem um fornecedor assim: Loja D'Água. Procure por ele com a busca que cola texto:

SELECT id, nome FROM fornecedores WHERE nome = 'Loja D'Água';

O banco respondeu com um erro (near "Água": syntax error — "erro de sintaxe perto de Água"). O apóstrofo de D'Água fechou o texto cedo demais, exatamente como a aspa do ataque, e o Água' que sobrou virou SQL sem sentido. Veja o que o banco recebeu:

WHERE nome = 'Loja D'Água'
                   ↑ a aspa aqui fechou o texto; sobrou  Água'

Esse erro é um presente: ele avisa, com um cliente honesto, que o seu programa cola texto — e o que hoje é um erro chato, amanhã é a porta do ataque. Com parâmetros, o problema simplesmente não existe: o nome com apóstrofo é guardado e procurado certinho, porque o banco o trata como dado. A aula Consultas com Parâmetros mostra isso rodando. (E, quando você precisa escrever a aspa dentro do SQL à mão, ela é dobrada: 'Loja D''Água', como na aula WHERE.)

8. As defesas, em ordem

Parâmetros resolvem quase tudo. As outras defesas são reforços, para os casos em que um valor não pode entrar por parâmetro.

Quando dá errado (no editor)

SELECT id, nome FROM fornecedores WHERE nome = 'Loja D''Água';

SELECT nome FROM clientes WHERE email = "ana.beatriz@exemplo.com.br";

Referência rápida

Exercícios

Missão final: transforme o ataque numa busca honesta

SELECT id, nome FROM fornecedores WHERE nome = '' OR '1'='1';

SELECT id, nome FROM fornecedores WHERE nome = 'Loja D''Água';

Resumo

• SQL Injection acontece quando um programa cola o texto digitado por alguém dentro do SQL: o dado pode virar comando e mudar a consulta.
• ' OR '1'='1 fecha o texto e acrescenta uma condição sempre verdadeira, devolvendo a tabela inteira. Um '-- comenta o resto e pula a checagem de senha. Um UNION SELECT injetado lê outra tabela.
• "A minha biblioteca só roda um comando" não é defesa: os piores ataques usam um comando só.
• A defesa de verdade é parâmetro (?, :nome): o valor vai por fora e é sempre tratado como dado. Para nome de coluna, use uma lista de permitidos. Em bancos com servidor, dê poucas permissões ao usuário.
• Um cliente honesto com apóstrofo no nome (Loja D'Água) já quebra o código que cola texto — é o aviso de que falta parâmetro.
• A aula Consultas com Parâmetros mostra os parâmetros em detalhe.