Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — FUNDATEC 2026

Consultas parametrizadas e prevenção de SQL Injection no mysqli

Gabarito: letra A — corretas apenas as assertivas I e II. A consulta parametrizada com mysqli_prepare e mysqli_stmt_bind_param separa a estrutura do SQL dos dados, impedindo que valores maliciosos alterem a instrução; o segundo argumento "ss" define os tipos dos parâmetros como string. As assertivas III e IV estão incorretas: a vinculação pode ocorrer antes da atribuição das variáveis (desde que existam), e a parametrização NÃO é funcionalmente equivalente à concatenação — é justamente essa diferença que bloqueia a injeção de SQL.

A injeção de SQL (SQLi) é uma vulnerabilidade de segurança web que permite a um invasor interferir nas consultas que uma aplicação faz ao seu banco de dados. Isso pode permitir que o invasor visualize dados que normalmente não poderia acessar, incluindo informações de outros usuários, ou quaisquer outros dados que a aplicação possa acessar. Em muitos casos, um invasor pode modificar ou deletar esses dados, causando alterações persistentes no conteúdo ou comportamento da aplicação.

As vulnerabilidades que permitem SQLi incluem: dados fornecidos não são validados, filtrados ou higienizados; consultas dinâmicas ou chamadas não parametrizadas sem escape; dados hostis são usados em parâmetros de mapeamento relacional objeto para extrair registros; e dados hostis são usados diretamente ou concatenados. A prevenção central é manter os dados separados de comandos e consultas, usando consultas parametrizadas — exatamente o que o código do enunciado faz.

A extensão mysqli (MySQL Improved) oferece suporte a prepared statements (declarações preparadas). O fluxo é: mysqli_prepare envia o template da consulta ao servidor, que o pré-compila; mysqli_stmt_bind_param vincula as variáveis aos placeholders (?), declarando seus tipos; mysqli_stmt_execute executa a consulta com os valores já vinculados. Como a estrutura SQL já foi definida e compilada antes de os dados chegarem, qualquer tentativa de injeção é tratada como dado, não como comando.

A pegadinha da questão está na assertiva IV: muitos candidatos acham que parametrizar é só "outra sintaxe" para concatenar. Não é. Na concatenação, os valores são embutidos diretamente na string SQL antes da execução, permitindo que um valor como ' OR '1'='1 altere a estrutura da consulta. Na parametrização, os valores são enviados separadamente e o servidor os trata como dados puros — a estrutura já foi fixada na pré-compilação. Essa é a diferença funcional que torna a parametrização segura.

Guarde a fronteira entre pré-compilação da estrutura e vinculação posterior dos dados: é exatamente nela que as assertivas I e IV se separam — a primeira descreve corretamente o mecanismo, a quarta nega a diferença essencial.

Item I — ✅ Correto

A assertiva descreve com precisão o funcionamento de mysqli_prepare: ela pré-compila a instrução SQL no servidor antes da vinculação dos parâmetros, separando estrutura e dados. Isso impede que valores maliciosos alterem a instrução, pois a estrutura já foi fixada. É o mecanismo central de prevenção de SQL Injection.

Item II — ✅ Correto

O segundo argumento "ss" de mysqli_stmt_bind_param indica que ambos os parâmetros são do tipo string. A função usa um caractere por parâmetro: s para string, i para inteiro, d para double, b para blob. Se os parâmetros fossem inteiros, o correto seria "ii". A assertiva está tecnicamente correta.

Item III — ❌ Incorreto

A assertiva afirma que as variáveis devem ser obrigatoriamente inicializadas antes da chamada de mysqli_stmt_bind_param. Na prática, a vinculação é feita por referência: a função associa as variáveis aos placeholders, e os valores são lidos no momento da execução (mysqli_stmt_execute). Portanto, as variáveis podem ser atribuídas após a vinculação, desde que existam e tenham valor antes da execução. O código do enunciado ilustra exatamente isso: mysqli_stmt_bind_param é chamado antes das atribuições de $curso e $situacao, e o código funciona. A palavra "obrigatoriamente" torna a assertiva falsa.

Item IV — ❌ Incorreto

A assertiva afirma que a consulta parametrizada é funcionalmente equivalente a concatenar os valores na string SQL, diferenciando-se apenas pela sintaxe. Isso é falso: a diferença é funcional e de segurança. Na concatenação, os valores são embutidos na string antes da execução, permitindo que dados maliciosos alterem a estrutura da consulta (SQL Injection). Na parametrização, a estrutura é pré-compilada e os valores são enviados separadamente, tratados como dados puros. Não é apenas sintaxe — é um mecanismo de segurança distinto.

Gabarito: letra A — corretas apenas as assertivas I e II.