Segurança da aplicação web

O email recebido no login é texto controlado pelo cliente. Se a aplicação o concatenar numa consulta, esse texto pode passar a ser sintaxe SQL. A defesa depende de onde a entrada é interpretada. Nos pedidos sobre bilhetes, é preciso verificar também quem pede e se pode operar sobre aquele objeto. A validação no navegador pode ser contornada.

SQL injection: separar código de valores

Construir SQL por concatenação permite que um valor passe a ser sintaxe:

// Vulnerável: a entrada faz parte do texto da instrução.
$sql = "SELECT id FROM utilizadores WHERE email = '" . $email . "'";

Usa parâmetros preparados:

$stmt = $pdo->prepare('SELECT id FROM utilizadores WHERE email = :email');
$stmt->execute(['email' => $email]);

O valor é tratado como dado. Um apóstrofo deixa de fechar uma string do SQL. Parametrizar um valor não parametriza identificadores como nomes de colunas ou palavras-chave. Se a pessoa escolher a ordenação, mapeia a opção para uma lista de colunas autorizadas, sem concatenar o texto recebido.

O ORM ajuda quando usa parâmetros corretamente. Uma expressão raw construída com entrada continua vulnerável. Limita também os privilégios da conta da aplicação: uma leitura não precisa de permissões para alterar o esquema.

XSS: o contexto decide a codificação

Cross-site scripting faz o navegador interpretar dados controlados pelo atacante como código da página. Pode ser refletido na resposta, guardado e mostrado mais tarde, ou criado no cliente ao inserir dados de forma insegura no DOM.

Para texto dentro de HTML, em PHP:

echo htmlspecialchars($comentario, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');

No Blade, {{ $comentario }} escapa HTML e {!! $comentario !!} imprime sem essa proteção. No DOM, prefere textContent para texto, porque innerHTML interpreta HTML e só deve receber conteúdo tratado para esse propósito.

A codificação depende do destino. Escapar texto HTML não torna segura uma interpolação dentro de JavaScript, CSS ou um URL. Num URL também tens de verificar o esquema, para não aceitar javascript:. Quando a funcionalidade permite HTML formatado, usa uma biblioteca de sanitização mantida com uma lista restrita de elementos e atributos, em vez de remover apenas <script>.

Uma política CSP pode reduzir certos ataques, mas não substitui codificação por contexto e sanitização. HttpOnly protege a leitura direta do cookie; um script injetado pode ainda agir com a sessão da vítima.

CSRF: a sessão é enviada automaticamente

Em cross-site request forgery, uma página de outra pessoa induz um pedido ao sistema usando credenciais que o navegador envia, como cookies. O atacante não precisa de conhecer o identificador da sessão nem de ler a resposta para causar uma alteração.

Uma compra baseada em sessão deve usar um token imprevisível associado ao contexto autorizado e validado pelo servidor. No Laravel, formulários protegidos pelo middleware adequado incluem @csrf. O token só é útil se for verificado; não deve ser colocado num URL que aparece em históricos e registos.

SameSite e verificação de origem são defesas complementares, não substitutos do token. O valor Lax continua a enviar o cookie em navegações de topo com método seguro: se alguma operação de escrita estiver acessível por GET, essa proteção não a impede, por isso nenhuma alteração de estado pode depender só do método do pedido. Além disso, a comparação é feita ao nível do domínio registável, não da origem completa: dois subdomínios diferentes do mesmo domínio contam como mesmo site. Um método POST sozinho não protege, e CORS não impede todos os envios de formulários. XSS pode contornar muitas defesas CSRF porque executa código na origem legítima.

Autenticado não significa autorizado

O comprador 7 pode estar autenticado e pedir GET /bilhetes/900, pertencente ao comprador 8. A aplicação tem de testar a relação entre a identidade e o recurso. Esconder o link ou usar um identificador difícil de adivinhar não cria essa permissão.

// Excerto Laravel com Illuminate\Support\Facades\Gate importado.
$bilhete = Bilhete::findOrFail($id);
Gate::authorize('view', $bilhete);

Aplica o controlo em todos os caminhos, incluindo API, downloads e operações em lote. Recusa por defeito e concede apenas as permissões necessárias. O papel «comprador» pode dar acesso à funcionalidade, mas a pertença do bilhete decide que objeto pode consultar.

Receber utilizador_id=8 no formulário não autoriza criar uma compra para 8. Usa a identidade autenticada quando a operação é «comprar para mim». $fillable controla preenchimento em massa de atributos, não verifica quem pode operar sobre cada objeto.

Palavras-passe e fixação de sessão

Guarda palavras-passe com um algoritmo de hash próprio para palavras-passe, como Argon2id ou bcrypt, através de uma API mantida. SHA-256 simples é demasiado rápido para este objetivo. Hash não tem uma chave de desencriptação; cifragem permite recuperar o original com uma chave. Uma palavra-passe não precisa de ser recuperada para verificar o login.

Em PHP, password_hash gera o hash com os parâmetros e salt necessários; password_verify verifica-o. O hash guardado já contém a informação que a API precisa. Não compares um novo hash gerado ao texto do anterior, porque os salts podem diferir.

Após autenticar, regenera o identificador da sessão para impedir session fixation. Uma mensagem de login genérica evita revelar qual parte das credenciais existe. Limitação de tentativas, recuperação com tokens de uso único e expiração completam a proteção.

<?php
$texto = '<img src=x onerror="alert(1)">';
echo htmlspecialchars($texto, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') . "\n";
$hash = password_hash('exemplo_que_nao_e_segredo', PASSWORD_DEFAULT);
echo password_verify('exemplo_que_nao_e_segredo', $hash) ? "certa\n" : "recusada\n";
echo password_verify('outra', $hash) ? "certa\n" : "recusada\n";

O bloco isola duas APIs: codificação de texto para HTML e verificação de palavra-passe. Não implementa login, CSRF ou políticas de acesso, por isso não introduzas palavras-passe pessoais nestes exemplos.

Identificar a defesa numa pergunta

São mecanismos diferentes: uma consulta parametrizada não impede alguém de consultar um objeto para o qual não tem autorização, e um token CSRF não impede XSS.

Um pedido ao bilhete alheio, camada a camada

O comprador 7 pede GET /bilhetes/900, mas o bilhete pertence ao comprador 8. Encontrar a linha com SQL seguro não concede permissão para a devolver.

Codificar o título impediria HTML ativo, mas não tornaria lícito mostrar os dados ao comprador 7.

A autorização testa a identidade 7 contra o proprietário 8 e recusa a leitura antes de gerar a representação. Para este pedido de leitura, um token CSRF não substitui a decisão sobre o objeto. Numa escrita, um token válido também não concede permissões; pode ser obtido e enviado por uma pessoa autenticada que tenta operar sobre um bilhete alheio.