Um cheque perdido que pode custar caro: Requests.get e formulário de solicitação Flask
Imagine o seguinte: um desenvolvedor júnior está trabalhando sob pressão para lançar um recurso. Ele abre um aplicativo Flask, adiciona uma nova rota, pega um parâmetro de consulta e segue em frente.
# Demonstrative example only — NOT executable, not exploitable
from flask import Flask, request
@app.route("/items")
def get_items():
# Type casting avoids unsafe string injection
item_id = request.args.get("id", type=int)
# Safe usage: forces integer input, prevents injection
À primeira vista, este uso de solicitação do Flask parece bom. Mas omita tipo=int e você abre a porta para ataques de injeção. Esses são os tipos de riscos que passam despercebidos nas revisões de código porque "são apenas uma forma de obter valor".
Onde o risco se esconde FSolicitação lask e FFormulário de solicitação lask
Ambos pedido de frasco e frasco.solicitação.formulário são pontos de entrada não confiáveis. Todo valor que eles retornam vem diretamente do cliente e deve ser tratado como potencialmente hostil.
Deixar de validar ou higienizar esses dados pode levar a problemas críticos de segurança, incluindo:
- injeção SQL
- Scripts entre sites (XSS)
- Injeção de modelo
- Injeção de comando shell
Esses riscos não se aplicam apenas a bancos de dados ou renderização front-end; os invasores também podem explorar entradas usadas em modelos ou passadas para subprocessos.
Padrões de pseudocódigo seguros:
python
# ⚠️ Educational example only — not functional
env_target = input("Enter deployment environment: ")
simulate_deploy(env_target) # Simulated for demonstration
Preventivo CI/CD execução:
# 1. Query parameter — Safe with casting
user_id = request.args.get("id", type=int) # Enforces integer type
# 2. Form parameter — Safe with casting
username = request.form.get("username", type=str) # Enforces string type
# 3. Template rendering safeguard
template_data = {"name": request.args.get("name", type=str)} # Avoids untrusted HTML injection
# 4. Shell command safe handling
filename = request.args.get("file", type=str)
# Validate filename against known safe values before use in subprocess (not shown)
Mesmo que a sintaxe pareça segura, usar valores brutos ou não verificados em modelos ou comandos do sistema pode se tornar um sério vetor de injeção.
Fluxo de Injeção Prático (Simulação Segura)
Veja como uma falha de injeção normalmente se desenrola, usando um cenário fictício e seguro:
- Um usuário envia um parâmetro de consulta criado para o aplicativo.
- O aplicativo lê o valor usando solicitação.args.get() sem validação.
- Esse valor é concatenado diretamente em uma consulta SQL, uma string de modelo ou um comando de shell.
- O sistema executa essa lógica, sem saber do conteúdo injetado.
Pseudocódigo (inseguro, apenas ilustrativo):
# Insecure example — do not run in production
user_id = request.args.get("id") # Missing type casting, no validation
query = f"SELECT * FROM users WHERE id = {user_id}" # Risk of injection
Rastreamento de log fictício:
[INFO] Incoming request: /user?id=unexpected_input
[DEBUG] Parsed user_id: unexpected_input
[DEBUG] Constructed SQL: SELECT * FROM users WHERE id = unexpected_input
Embora este exemplo use marcadores de posição, ele reflete como pequenos descuidos no tratamento de entradas podem levar a vulnerabilidades críticas.
Testes automatizados podem não detectar isso porque geralmente testam tipos de entrada válidos, não malformados ou maliciosos.
Riscos ocultos em dependências usando Solicitação de frasco e Formulário de solicitação de frasco
Seu código pode estar limpo, mas pacotes de terceiros ainda podem quebrá-lo.
Alguns plugins ou bibliotecas do Flask chamam internamente a solicitação do Flask ou o formulário de solicitação do Flask sem validação.
Exemplo com pacotes fictícios:
python
# Insecure example — do not run in production
return AutoFormHandler.process() # May use request.form.get() without validation
python
# Insecure example — do not run in production
query = build_query(request.args) # May use request.args.get() without casting
In CI/CD, atualizações automatizadas de dependências podem introduzir silenciosamente chamadas requests.get inseguras ou padrões de tratamento de entrada vulneráveis.
Quão inseguro Solicitação de frasco Deslizes de uso após revisões de código
Em ambientes de ritmo acelerado, erros pequenos, mas perigosos, muitas vezes passam despercebidos, especialmente quando a mudança parece inofensiva.
Exemplo pull request diferença:
# Insecure example — do not run in production
- user_id = request.args.get("id")
+ user_id = request.args.get("id") # Still missing type casting
Comentário do revisor:
“Parece bom, está apenas obtendo um parâmetro.”
Esse tipo de supervisão é comum devido a:
- Viés cognitivo: os revisores podem assumir que request.args.get() é seguro por padrão.
- Pressão do tempo: as verificações de segurança ficam em segundo plano quando os prazos se aproximam.
- Diferencialidade familiar: a mudança parece pequena, então não passa por uma análise mais aprofundada.
Sem regras claras ou aplicação automatizada, esses riscos sutis passam despercebidos na produção.
Prevenção que funciona
Para mitigar os riscos de injeção, combine validação de entrada, varredura automatizada e cobertura de teste.
Validação de entrada com transmissão e lista de permissões:
user_id = request.args.get("id", type=int)
if user_id not in [1, 2, 3]:
abort(400, "Invalid ID")
A conversão força o valor para um tipo seguro, enquanto a lista de permissões garante que apenas valores conhecidos e bons sejam adotados.
Teste de segurança de aplicativos estáticos (SAST) em CI/CD:
name: Run SAST scan
run: sast-tool --scan src/ --fail-on "request.args.get without type"
Esta etapa ajuda a detectar não validados solicitação.args.get() or request.form.get() chamadas antes que elas cheguem à produção.
Testes unitários para impor a higienização:
def test_invalid_type(client):
response = client.get("/items?id=abc")
assert response.status_code == 400
These tests ensure the app rejects malformed or malicious input consistently.
Integrating Into DevSecOps Pipelines
Middleware enforcement:
@app.before_request
Esses testes garantem que o aplicativo rejeite entradas maliciosas ou malformadas de forma consistente.
Integração ao DevSecOps Pipelines
Aplicação de middleware:
@app.antes_da_solicitação
def sanitize_input():
if "id" in request.args and not request.args.get("id", type=int):
abort(400, "Invalid ID")
Pre-commit hook:
bash
if grep -R "request.args.get(" . | grep -v "type="; then
echo "Unsafe request.args.get detected — please add type casting."
exit 1
fi
Verificando seu código e dependências de terceiros ajuda a detectar solicitações inseguras.get, solicitações de flask e uso de formulários de solicitações de flask antes que cheguem à produção.
Este problema vai além do Flask
O tratamento inseguro de entradas não é exclusivo do Flask; ele existe em todas as estruturas da web. Felizmente, a solução é consistente: valide as entradas com antecedência e rigor.
Django (pseudocódigo seguro):
# Enforces integer type and applies whitelist
user_id = int(request.GET.get("id", "0"))
if user_id not in [1, 2, 3]:
return HttpResponseBadRequest()
FastAPI (seguro por design usando dicas de tipo):
from fastapi import Query
@app.get("/items")
def read_items(id: int = Query(..., ge=1, le=3)):
return {"id": id}
Ambos os exemplos impõem o tipo e o intervalo de entrada, garantindo que os dados recebidos sejam confiáveis antes de atingirem a lógica sensível.
Seja Flask, Django ou FastAPI, cada parâmetro de solicitação é um possível ponto de injeção se não for validado corretamente.
Usando Xygeni para detecção em DevSecOps
Em um ambiente DevSecOps, revisões manuais não são suficientes. Xygeni automatiza a detecção de solicitações de frasco inseguras, formulários de solicitação de frasco e uso de requests.get.
Aplicações práticas de DevSecOps:
- Varreduras estáticas: Sinaliza qualquer solicitação.args.get() sem type =, e chamadas de formulário de solicitação de frasco sem validação.
- Análise de dependência: Monitora bibliotecas em busca de padrões inseguros que podem surgir por meio de chamadas indiretas.
- Bloqueando fusões inseguras: CI/CD falha se o novo código introduzir solicitações arriscadas.get ou acesso de formulário não validado.
- Aplicação da linha de base: Rastreia alterações para evitar que chamadas seguras se tornem inseguras.
A automatização dessas verificações reduz o risco de erro humano e mantém a segurança contínua sem atrasar a entrega.
Então, valide, higienize, automatize
Aqui está o resultado final: requests.get, flask request e flask request form são todos não confiável por padrão. Eles entregarão alegremente dados maliciosos, a menos que você tome alguma atitude.
Suas três regras:
- Validar entradas usando transmissão e listas de permissões.
- Sanitize antes que os dados toquem operações sensíveis.
- Automatize verifica em seu pipeline para interromper código inseguro antes da implantação.
Um único manipulador de requisição Flask inseguro, um campo de formulário de requisição Flask não verificado ou uma chamada requests.get desprotegida podem comprometer sua aplicação. Trate cada parâmetro como potencialmente hostil e deixe seu DevSecOps pipeline aplique as regras sempre.
