Trabalho 1 — Desenvolvimento de API REST Segura com CI/CD e Análise de Vulnerabilidade CVE Real

API REST segura em Python/Flask, CI/CD via GitHub Actions (SAST + SCA + testes automatizados), e uma análise completa de uma CVE real reproduzida em um ambiente Docker (Kibana LFI, CVE-2018-17246).

Nome: Guhaotian Número HDU: 23320209

1. Projeto e equipe

Repositório: https://github.com/ght657/work1-secure-api (público)
Stack: Python 3.9 / Flask 3.1.3, PyJWT (tokens HS256), hash de senha bcrypt, SQLite via SQLAlchemy 2, pytest.
A API expõe três endpoints:
- POST /auth/login — emite um JWT assinado após verificar o hash da senha.
- GET /api/data — protegido por JWT (token Bearer); retorna registros do usuário atual.
- GET /api/users/search?q= — endpoint de leitura protegido com consulta SQL com parâmetros vinculados.
Endpoint de escrita extra POST /api/posts (protegido por JWT) demonstra a proteção contra XSS armazenado / escape de saída.

2. Pipeline CI/CD

Arquivo de workflow: .github/workflows/ci.yml, acionado a cada push para main.

Job	Ferramentas	O que faz	Evidência
`test`	pytest 8	executa a suíte de 11 testes	`evidence/07_pytest_run.png`
`sast`	Bandit 1.8.0	análise estática de `app/`, `tests/` (relatório JSON enviado como artefato)	`evidence/08_bandit_report.png`
`sca`	pip-audit 2.8.0	auditoria de dependências (relatório JSON enviado como artefato)	`evidence/09_pip_audit_report.png`

O pipeline falha se qualquer teste falhar ou se qualquer achado de SAST/SCA permanecer, então um pipeline vermelho significa que uma correção deve ser enviada antes do merge.

3. Evidências — SAST, SCA, testes

3.1 Testes automatizados

11 testes, todos passando (pytest -q):

tests/test_api.py::test_login_success_issues_token PASSED
tests/test_api.py::test_login_wrong_password_rejected PASSED
tests/test_api.py::test_login_unknown_user_same_error_as_wrong_password PASSED
tests/test_api.py::test_passwords_stored_as_bcrypt_hashes PASSED
tests/test_api.py::test_data_endpoint_denied_without_token PASSED
tests/test_api.py::test_data_endpoint_denied_with_invalid_token PASSED
tests/test_api.py::test_data_endpoint_works_with_valid_token PASSED
tests/test_api.py::test_create_post_requires_token PASSED
tests/test_api.py::test_sqli_payload_treated_as_data PASSED
tests/test_api.py::test_sqli_union_payload_does_not_dump_table PASSED
tests/test_api.py::test_xss_payload_is_escaped_in_response PASSED

11 passed in 2.20s

3.2 SAST — Bandit

O código da aplicação é nosso, portanto uma primeira execução naturalmente não contém ruído de terceiros. Resultado: 0 problemas:

Run started:...
Test results:
	No issues identified.
Code scanned:
	Total lines of code: 228
	Total lines skipped (#nosec): 0
	Total potential issues skipped due to specifically being disabled (e.g., #nosec BXXX): 0

3.3 SCA — pip-audit (auditoria de dependências)

O pip-audit lista todas as dependências com CVEs conhecidas; a execução inicial encontrou:

Found 19 known vulnerabilities in 3 packages
Name          Version ID                Fix Versions
------------- ------- ----------------- ------------
flask         3.0.3   PYSEC-2026-2151    3.1.3
pyjwt         2.9.0   PYSEC-2026-120     2.12.0
pyjwt         2.9.0   PYSEC-2025-183      ...
pyjwt         2.9.0   ...                up to 2.15.0
python-dotenv 1.0.1   PYSEC-2026-2270    1.2.2

19 entradas no total (Flask, PyJWT ×17, python-dotenv). Atualizei para as versões corrigidas: Flask 3.1.3, PyJWT 2.15.0 e removi python-dotenv (apenas auxiliar de configuração opcional — a versão corrigida 1.2.2 exige Python ≥ 3.10, enquanto o venv de auditoria é 3.9). Após a correção:

No known vulnerabilities found

(evidence/08b_bandit_after_fix.png, evidence/09b_pip_audit_after_fix.png)

4. Teste de vulnerabilidades — segurança da API

A API foi testada contra os ataques clássicos com curl. Capturas de tela em evidence/:

POST /auth/login com username: "admin'--" retorna 401 Invalid credentials — a consulta usa uma query parametrizada do ORM contra as credenciais com hash, o payload injetado permanece como dado e nunca se torna SQL.

4.2 Tentativa de injeção SQL na busca

GET /api/users/search?q=%' OR '1'='1 → a string é vinculada como parâmetro a SELECT ... WHERE username LIKE ? (curingas escapados), então não corresponde a nada e a API retorna uma lista vazia — sem erro e sem despejo da tabela inteira.

4.3 Tentativa de XSS (conteúdo armazenado)

POST /api/posts com title: "<script>alert('xss')</script>"; o servidor armazena a string bruta mas a escapa na saída (markupsafe.escape + jsonify), então o payload retornado é <script>alert('xss')</script> — um navegador exibe o texto, não o executa. (A reprodução com renderização no navegador é mostrada em evidence/06_xss_readback.png.)

4.4 Tratamento de JWT

Sem token → 401 {"error": "Missing or malformed Authorization header"} (evidence/03_data_denied.png)
Token válido → 200 + dados protegidos (evidence/04_data_with_token.png)
Token com payload adulterado → 401 (verificação de assinatura com HS256)
Token expirado → 401 (expiração de 60 minutos)
O JWT é retornado na resposta e usado via Authorization: Bearer <token> (evidence/10_jwt_structure.png mostra a estrutura de 3 partes).

4.5 Hashing

As senhas são armazenadas como hashes bcrypt (12 rounds) e nunca são retornadas por nenhum endpoint (teste test_passwords_stored_as_bcrypt_hashes).

5. Análise de CVE — CVE-2018-17246 (Kibana 5.6.12 / 6.4.2 — inclusão de arquivo local + execução de código)

5.1 Visão geral da vulnerabilidade

Produto / versão: Kibana 5.6.12 (vulnerável), 5.6.13 (corrigido); 6.4.2 / 6.4.3.
Tipo: Path traversal / leitura arbitrária de arquivos sem autenticação através da Console API, que escala para execução remota de código ao carregar um arquivo JavaScript local.
Impacto: leitura não autenticada de qualquer arquivo legível pelo processo do Kibana (por exemplo, /etc/passwd) e — como a rota vulnerável requer o arquivo como um módulo JS — se um caminho gravável for acessível (por exemplo, através de outra falha ou de um arquivo temporário gerado), JS controlado pelo atacante pode ser executado pelo processo do Kibana.
Causa: GET /api/console/api_server?apis=../../../../../../etc/passwd — o parâmetro apis é passado para require() após apenas uma verificação simples de caminho, permitindo que sequências .. escapem do diretório api do lado do servidor e leiam/executem arquivos arbitrários.

5.2 Reproduzindo a CVE (Docker local)

Uso a imagem pública do vulhub (já publicada, verificada como vulnerável):

vulhub/kibana:5.6.12 + vulhub/elasticsearch:5.6.16 — veja CVE-2018-17246/docker-compose.yml (pasta com o mesmo nome neste repositório).

cd CVE-2018-17246
docker compose up -d          # kibana 5.6.12 + elasticsearch 5.6.16, UI on :5601

Passo 1 — acionar o LFI (a Console API aceita um caminho apis que é resolvido como um arquivo):

curl -i "http://localhost:5601/api/console/api_server?sense_version=%40%40SENSE_VERSION&apis=../../../../../../../../../../../etc/passwd"

A resposta é 500 (o ficheiro não é um módulo JS válido) mas o conteúdo do ficheiro aparece no log do servidor — o Kibana lê o ficheiro e tenta fazer require() dele:

docker compose logs kibana | grep -i "passwd\|root:x"

Passo 2 — escalar para execução de código. Um arquivo JS local é carregado como módulo pela mesma rota: /tmp/vulhub.js contendo um pequeno "webshell" que executa um comando de shell quando sua função exportada é invocada pela Console API:

Mais Populares

work1-secure-api