Protecção, Detecção e Resposta

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Classificar as oito ocorrências da ficha segundo a categoria de falha aplicacional a que pertencem — controlo de acesso, injecção, configuração, autenticação, exposição de dados — justificando cada classificação.
• Escrever, para as duas ocorrências que vão ser testadas, o caso de teste correspondente no formato do guia de testes da OWASP: objectivo, pré-condição, passos, resultado esperado e evidência a recolher.
• Executar, na aplicação vulnerável instalada em máquina virtual isolada, dois testes autorizados de controlo de acesso e registar a evidência observada.
• Redigir um achado de relatório com descrição, impacto, passos de reprodução, evidência e recomendação, sem afirmar que a aplicação é segura.

Explicação

Boa parte das falhas graves que aparecem em aplicações web não é exótica: é controlo de acesso mal feito. O padrão repete-se — a aplicação esconde o botão na interface, mas o pedido continua a funcionar se for feito directamente; ou usa o identificador que vem do cliente para decidir que registo mostrar, sem verificar se aquele utilizador tem direito àquele registo. A regra é: a autorização verifica-se no servidor, a cada pedido, a partir da identidade da sessão e das regras de acesso definidas pela instituição, e nunca a partir de algo que o cliente possa alterar. Atenção a um erro frequente na formulação da regra: ter direito ao registo não é o mesmo que ser o seu titular. Há acessos legitimamente concedidos por perfil ou por âmbito — o funcionário do balcão que trata do processo, a chefia da unidade, a auditoria interna dentro do seu mandato. O que o servidor tem de verificar é se aquela sessão tem, naquele momento, uma permissão aplicável àquele registo; quem pode ver o quê é uma decisão escrita de quem gere o serviço, e não uma regra técnica universal.

A segunda família é a injecção. Acontece quando dados enviados pelo utilizador são misturados com uma instrução — uma consulta à base de dados, um comando do sistema, uma página devolvida ao navegador — e o sistema passa a executar parte dos dados como se fossem instrução. A defesa que funciona é estrutural: separar instrução de dados, com consultas parametrizadas, e codificar a saída conforme o contexto onde ela vai aparecer. Validar entradas por lista de valores permitidos ajuda, mas não substitui a separação.

A terceira família é configuração: páginas de administração acessíveis, mensagens de erro que revelam a estrutura interna, listagem de directórios ligada, credenciais por omissão que ficaram, componentes desactualizados com falhas conhecidas. É a família mais barata de corrigir e das mais frequentes.

O guia de testes de segurança de aplicações web da OWASP dá estrutura ao trabalho. Não é uma norma obrigatória nem uma lei: é um guia comunitário aberto que organiza o que testar por categorias e ajuda a não esquecer áreas inteiras. A utilidade prática está em dois pontos: transforma «vamos ver se está seguro» numa lista de casos de teste concretos, e dá um formato de registo que torna o achado reproduzível por outra pessoa.

Um achado bem escrito tem sempre cinco partes: o que se encontrou, qual o impacto para o serviço e para os dados, como se reproduz passo a passo, que evidência foi recolhida, e o que se recomenda. O que não deve ter é a conclusão «a aplicação é segura». O que se escreve no fim é o que foi testado, o que ficou por testar e em que condições — é nisso que se distingue um relatório profissional de uma opinião.

Caso fictício: o portal de marcação de Muteva e o número de processo

No portal de marcação, depois de entrar, o cidadão vê os seus pedidos através de um endereço que termina em «/pedido/4821». Um funcionário reparou que, mudando o número para 4820, aparecia o pedido de outra pessoa, com nome, contacto e motivo.

A empresa que desenvolveu a aplicação respondeu que «o ecrã só mostra os pedidos do utilizador» — e mostra mesmo, na lista. O problema está na página de detalhe, que aceita qualquer número e devolve o registo correspondente sem verificar de quem é.

Este é o caso clássico de referência directa insegura a objectos. É uma falha de controlo de acesso, não de interface, e corrige-se no servidor: antes de devolver o registo, a aplicação tem de verificar se a sessão tem permissão para aquele pedido concreto. No portal de Muteva, a regra escrita pela direcção é que o cidadão vê os seus próprios pedidos e que os funcionários do balcão vêem os pedidos da sua unidade; a verificação no servidor aplica essa regra, em vez de aceitar o número recebido do cliente como se bastasse. Noutro serviço, com outras regras de perfil e âmbito, a verificação é a mesma ideia com outro critério.

Anexo A — Oito ocorrências observadas no portal de laboratório (fictícias)

Ficha de trabalho. As colunas de classificação e prioridade são preenchidas na actividade.

Anexo B — Autorização escrita para os testes do laboratório (modelo fictício)

Modelo a assinar pelo formador antes do laboratório; é também o exemplo de boa redacção.

«Autorização de teste em ambiente de formação. Alvos permitidos: exclusivamente a máquina virtual APP-LAB, endereço 10.20.4.10, na rede virtual isolada da sala. Alvos expressamente excluídos: qualquer sistema da instituição anfitriã, qualquer endereço fora da rede virtual e qualquer serviço na internet.

Janela: durante a sessão desta lição, das 09h00 às 11h00 do dia da formação. Técnicas proibidas: negação de serviço, alteração ou destruição de dados fora da aplicação de laboratório, e qualquer acção sobre máquinas de outros participantes.

Critério de paragem imediata: qualquer efeito observado fora de APP-LAB. Contacto de emergência: o formador da sessão, presente na sala. Registo: cada par regista na folha de laboratório a hora, o teste executado e o resultado observado.»

Anexo C — Aplicação didáctica APP-LAB, código completo (app_lab.py)

Aplicação de formação DELIBERADAMENTE VULNERÁVEL, escrita para este curso. Usa apenas a biblioteca padrão do Python 3 (requer Python 3.8 ou superior; a equipa autora executou-a em Python 3.13) e não instala nem descarrega nada. Guardar como app_lab.py na máquina virtual isolada e arrancar com «python3 app_lab.py»; fica a escutar em 127.0.0.1:8080, apenas dentro da própria máquina. Contas: utilizador1/lab1 e utilizador2/lab2. Pedidos fictícios: 4821 pertence a utilizador1 e 4820 pertence a utilizador2. NUNCA colocar esta aplicação em rede da instituição, na internet ou na plataforma de formação.

#!/usr/bin/env python3
# app_lab.py - aplicacao didactica DELIBERADAMENTE VULNERAVEL.
# Uso exclusivo em maquina virtual isolada, sem ligacao a redes reais.
# Biblioteca padrao apenas. Nao instala nada. Arranque: python3 app_lab.py
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import parse_qs
import uuid

CONTAS = {'utilizador1': 'lab1', 'utilizador2': 'lab2'}

PEDIDOS = {
    '4820': {'dono': 'utilizador2', 'nome': 'Ana Cumbe (ficticio)',
             'contacto': '84 000 0002', 'motivo': 'Segunda via de certidao'},
    '4821': {'dono': 'utilizador1', 'nome': 'Bento Mate (ficticio)',
             'contacto': '84 000 0001', 'motivo': 'Marcacao de atendimento'},
}

SESSOES = {}

PAGINA_ENTRAR = ('<h1>Portal de laboratorio</h1>'
                 '<form method=post action=/entrar>'
                 'Utilizador: <input name=u> Senha: <input name=p type=password>'
                 '<button>Entrar</button></form>')


class App(BaseHTTPRequestHandler):
    def sessao(self):
        for parte in self.headers.get('Cookie', '').split(';'):
            if parte.strip().startswith('sid='):
                return SESSOES.get(parte.strip()[4:])
        return None

    def responder(self, codigo, corpo, cookie=None):
        dados = corpo.encode('utf-8')
        self.send_response(codigo)
        self.send_header('Content-Type', 'text/html; charset=utf-8')
        self.send_header('Content-Length', str(len(dados)))
        if cookie:
            self.send_header('Set-Cookie', cookie)
        self.end_headers()
        self.wfile.write(dados)

    def do_GET(self):
        utilizador = self.sessao()
        if self.path == '/':
            if not utilizador:
                return self.responder(200, PAGINA_ENTRAR)
            meus = [n for n, p in PEDIDOS.items() if p['dono'] == utilizador]
            itens = ''.join('<li><a href=/pedido/' + n + '>Pedido ' + n + '</a></li>' for n in meus)
            return self.responder(200, '<h1>Os meus pedidos</h1><ul>' + itens + '</ul>')
        if self.path.startswith('/pedido/'):
            numero = self.path[len('/pedido/'):]
            pedido = PEDIDOS.get(numero)
            if not pedido:
                return self.responder(404, '<p>Pedido nao encontrado.</p>')
            # FALHA DIDACTICA O-01: devolve o pedido sem verificar a sessao.
            return self.responder(200, '<h1>Pedido ' + numero + '</h1><p>Nome: ' + pedido['nome']
                                  + '</p><p>Contacto: ' + pedido['contacto']
                                  + '</p><p>Motivo: ' + pedido['motivo'] + '</p>')
        if self.path == '/admin':
            # FALHA DIDACTICA O-03: painel de administracao sem autenticacao.
            linhas = ''.join('<li>' + n + ' - ' + p['dono'] + ' - ' + p['nome'] + '</li>'
                             for n, p in PEDIDOS.items())
            return self.responder(200, '<h1>Administracao</h1><ul>' + linhas + '</ul>')
        return self.responder(404, '<p>Nao encontrado.</p>')

    def do_POST(self):
        if self.path != '/entrar':
            return self.responder(404, '<p>Nao encontrado.</p>')
        tamanho = int(self.headers.get('Content-Length', '0'))
        campos = parse_qs(self.rfile.read(tamanho).decode('utf-8'))
        u = campos.get('u', [''])[0]
        p = campos.get('p', [''])[0]
        if CONTAS.get(u) != p:
            return self.responder(401, '<p>Credenciais invalidas.</p>')
        sid = uuid.uuid4().hex
        SESSOES[sid] = u
        return self.responder(200, '<p>Sessao iniciada. <a href=/>Continuar</a></p>',
                              cookie='sid=' + sid + '; Path=/')


if __name__ == '__main__':
    print('APP-LAB a escutar em http://127.0.0.1:8080 (ambiente isolado)')
    HTTPServer(('127.0.0.1', 8080), App).serve_forever()

Anexo D — Pedidos e respostas completos dos dois testes (material da alternativa offline)

Registo integral dos pedidos e das respostas obtidos nesta aplicação, para trabalhar no papel quando não houver ambiente. O identificador de sessão mostrado é de uma execução de exemplo e muda a cada arranque. Trabalhar sobre este registo é análise documental: não conta como laboratório executado.

A. Iniciar sessao como utilizador1
POST /entrar HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 20

u=utilizador1&p=lab1

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 47
Set-Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4; Path=/

<p>Sessao iniciada. <a href=/>Continuar</a></p>

B. Teste O-01, primeira parte: o proprio pedido (resultado esperado, legitimo)
GET /pedido/4821 HTTP/1.1
Host: 127.0.0.1:8080
Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 120

<h1>Pedido 4821</h1><p>Nome: Bento Mate (ficticio)</p><p>Contacto: 84 000 0001</p><p>Motivo: Marcacao de atendimento</p>

C. Teste O-01, segunda parte: pedido de outra conta com a MESMA sessao (falha de autorizacao)
GET /pedido/4820 HTTP/1.1
Host: 127.0.0.1:8080
Cookie: sid=f19214ad60fa44c7b56af3e9ce1915c4

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 119

<h1>Pedido 4820</h1><p>Nome: Ana Cumbe (ficticio)</p><p>Contacto: 84 000 0002</p><p>Motivo: Segunda via de certidao</p>

D. Teste O-01, terceira parte: o mesmo pedido SEM qualquer sessao
GET /pedido/4820 HTTP/1.1
Host: 127.0.0.1:8080

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 119

<h1>Pedido 4820</h1><p>Nome: Ana Cumbe (ficticio)</p><p>Contacto: 84 000 0002</p><p>Motivo: Segunda via de certidao</p>

E. Teste O-03: painel de administracao sem sessao
GET /admin HTTP/1.1
Host: 127.0.0.1:8080

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 132

<h1>Administracao</h1><ul><li>4820 - utilizador2 - Ana Cumbe (ficticio)</li><li>4821 - utilizador1 - Bento Mate (ficticio)</li></ul>

Trabalho prático

Trabalho em pares, com os anexos A e B em papel, antes de tocar no ambiente, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 60 minutos, 35 são do exercício em papel e 25 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Classifiquem as oito ocorrências do anexo A por categoria — controlo de acesso, injecção, configuração, autenticação ou exposição de dados — e atribuam prioridade de 1 a 3, justificando a prioridade pelo que um atacante consegue a partir daquilo. Onde a ocorrência for apenas indício de uma categoria, escrevam «indício» e digam que teste confirmaria.

Passo 2 (10 minutos). Para O-01 e O-03, escrevam o caso de teste no formato do guia: objectivo do teste, pré-condição, passos numerados, resultado esperado se a falha existir, resultado esperado se estiver corrigida, e evidência a recolher. São estes os dois casos que vão executar no laboratório.

Passo 3 (10 minutos). Escrevam o achado completo de O-01 como entraria num relatório: descrição, impacto, reprodução, evidência e recomendação. A recomendação deve dizer onde se corrige, não apenas o que se corrige.

Produto esperado: Anexo A classificado e priorizado, dois casos de teste escritos no formato do guia e um achado de relatório completo para O-01.

Como o produto é apreciado

• O-01 e O-03 estão classificadas como controlo de acesso; O-05 como injecção no navegador; O-06, O-07 e O-08 como configuração; O-04 como gestão de sessão e autenticação.
• O-02 é classificada como indício de injecção na consulta à base de dados, e não como injecção confirmada: uma mensagem de erro provocada por uma plica mostra que a entrada chega ao motor da base de dados sem tratamento adequado e que a aplicação revela detalhes internos no erro, o que já é achado próprio. A confirmação exige um teste adicional, autorizado e registado, que demonstre alteração do comportamento da consulta.
• A prioridade de O-08 é alta e justificada assim: um ficheiro de configuração acessível com credenciais é exposição grave de credenciais e obriga a trocá-las. Não se conclui daí, sem verificação, que exista acesso directo à base de dados — isso depende de a base aceitar ligações a partir de onde o atacante está, de as credenciais ainda serem válidas e das permissões associadas. O achado escreve-se com esta distinção entre o que foi observado e o que ainda é hipótese.
• Os casos de teste indicam evidência concreta a recolher — captura de ecrã, pedido e resposta, hora — e não apenas «verificar se funciona».
• A recomendação de O-01 exige verificação de autorização no servidor, aplicando as regras de acesso escritas da instituição — titular, perfil ou âmbito, conforme o caso — e não esconder a ligação na interface.
• O achado não conclui que a aplicação é segura nem generaliza para além do que foi testado.

Laboratório em ambiente isolado — Dois testes autorizados de controlo de acesso em APP-LAB (app_lab.py)

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Executar, na aplicação didáctica app_lab.py do anexo C, os casos de teste de O-01 e O-03 escritos na actividade, recolher evidência e registá-la no formato do relatório.

Tempo: 25 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Material entregue com a lição

• Anexo C: código completo da aplicação app_lab.py, entregue com esta lição. Não é preciso o formador inventar nem procurar aplicação nenhuma — copia-se o código do anexo para um ficheiro com esse nome.
• Anexo C: contas (utilizador1/lab1 e utilizador2/lab2), pedidos fictícios (4821 de utilizador1 e 4820 de utilizador2) e rotas (/, /entrar, /pedido/{numero}, /admin) já coerentes entre si, sem passo de configuração adicional.
• Anexo D: pedidos e respostas completos dos dois testes, para imprimir e usar na alternativa offline.
• Anexo B: autorização de teste pronta a assinar.

Recursos e versões, preparados antes da sessão

• Uma máquina virtual «APP-LAB» com Python 3.8 ou superior já instalado (qualquer distribuição de Linux corrente serve; a equipa autora executou a aplicação em Python 3.13). A aplicação não instala pacotes e não precisa de internet.
• O ficheiro app_lab.py, criado a partir do anexo C, arrancado com «python3 app_lab.py». Escuta em 127.0.0.1:8080 e só responde dentro da própria máquina.
• Um navegador na mesma máquina virtual, com as ferramentas de programador para ver pedidos e respostas. Em alternativa, a ferramenta de linha de comandos curl, se estiver disponível.
• Rede virtual isolada, sem encaminhamento para a rede da sala nem para a internet.
• Autorização do anexo B impressa e assinada, afixada na sala durante o laboratório.
• Folha de laboratório com espaço para hora, teste, resultado e evidência.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina virtual em si — imagem, memória e instalação — não é entregue com o curso: é preparada pela instituição de acolhimento. Enquanto não existir, o laboratório fica pendente.
• Este laboratório ainda não foi executado numa sala com formandos: os 25 minutos previstos e a sequência dos passos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.
• Se a sala não tiver máquinas virtuais mas tiver Python instalado numa máquina isolada da rede, o formador decide, por escrito, se autoriza a execução nessa máquina; se não autorizar, usa-se o anexo D e regista-se o laboratório como pendente.

Preparação prévia, a cargo do formador

• Na véspera, criar app_lab.py a partir do anexo C na máquina virtual, arrancar com «python3 app_lab.py» e confirmar que a página inicial abre em http://127.0.0.1:8080.
• Confirmar a entrada com as duas contas do anexo C e que cada conta vê apenas o seu pedido na lista inicial.
• Tirar instantâneo «inicial» da máquina virtual com a aplicação já a funcionar.
• Confirmar que a rede virtual está isolada e que APP-LAB não alcança a internet nem a rede da sala.
• Imprimir o anexo D, para o caso de o ambiente falhar, e ler em voz alta a autorização do anexo B antes de qualquer teste.

Passos

1. Arrancar a aplicação com «python3 app_lab.py» e abrir http://127.0.0.1:8080 no navegador da própria máquina.
2. Entrar como «utilizador1» com a senha «lab1» e anotar o número do próprio pedido (4821).
3. Executar o caso de teste de O-01: com a mesma sessão, escrever no endereço /pedido/4820, que é o pedido de «utilizador2», e registar o que a aplicação devolve, com captura de ecrã e hora.
4. Repetir /pedido/4820 depois de fechar o navegador ou apagar o cookie de sessão, para distinguir falha de autorização de falha de autenticação, e registar o resultado.
5. Executar o caso de teste de O-03: aceder a /admin sem sessão iniciada e registar se a página abre, que informação mostra e que evidência foi recolhida.
6. Registar na folha, para cada teste, a hora de início, a acção exacta e o resultado observado, sem interpretações.
7. Não alterar nem apagar dados na aplicação: os testes desta lição são apenas de leitura e de acesso.

Verificação de sucesso

• A folha de laboratório tem, para cada um dos dois testes, hora, acção e resultado observado, com evidência anexada.
• O resultado observado em /pedido/4820 corresponde ao que está no anexo D: a aplicação devolve o pedido de outra conta. Se não corresponder, anota-se a diferença em vez de forçar a conclusão esperada.
• O par consegue reproduzir o resultado de O-01 uma segunda vez seguindo apenas os passos que escreveu — se não conseguir, os passos estão incompletos e são corrigidos.
• O teste repetido sem sessão iniciada permite dizer, com fundamento, se a falha é de autorização ou de autenticação.
• Nenhum efeito foi observado fora de APP-LAB, conforme o critério de paragem.

Reversão ao estado inicial

• Parar a aplicação com Ctrl+C: os dados vivem em memória e desaparecem ao parar, pelo que a aplicação volta ao estado inicial em cada arranque.
• Restaurar o instantâneo «inicial» da máquina virtual no fim da sessão.
• Apagar app_lab.py e as capturas de ecrã das máquinas partilhadas depois de anexadas à folha do par, para a aplicação vulnerável não ficar esquecida em nenhum computador.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Trabalhar sobre o anexo D impresso, que traz os pedidos e as respostas completos das cinco situações (entrada em sessão, pedido próprio, pedido alheio com sessão, pedido alheio sem sessão e painel /admin).
• Comparar a resposta B com a resposta C e escrever, numa frase, o que a diferença — ou a ausência de diferença — mostra sobre a verificação de autorização no servidor.
• Localizar, no código do anexo C, a linha comentada como falha didáctica O-01 e explicar que verificação falta ali.
• Escrever os passos de reprodução a partir do material impresso e verificar se outra pessoa da sala os consegue seguir sem dúvidas.
• Redigir o achado completo com a evidência impressa em vez da evidência recolhida.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• A autorização verifica-se no servidor, em cada pedido. Esconder o botão não protege nada.
• Injecção resolve-se separando instrução de dados, não confiando só em filtrar texto.
• Configuração por omissão deixada como está é das falhas mais comuns e mais baratas de corrigir.
• Testar sem autorização escrita e sem lista de alvos não é teste.
• O relatório diz o que foi testado e o que ficou por testar. Nunca diz «a aplicação é segura».

Verificação formativa

Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.

1. A empresa propõe corrigir O-01 removendo a ligação para a página de detalhe e passando a abrir o pedido por um botão da lista. Resolve?
2. No laboratório encontraram duas falhas e nenhuma outra. Podem escrever no relatório que as restantes áreas da aplicação estão seguras?

Respostas comentadas da verificação formativa

As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A empresa propõe corrigir O-01 removendo a ligação para a página de detalhe e passando a abrir o pedido por um botão da lista. Resolve?

Resposta: Não. O endereço continua a existir e continua a responder a quem o escrever directamente. A correcção tem de ser no servidor: antes de devolver o registo, verifica-se se a sessão tem permissão para aquele pedido, segundo as regras de acesso escritas — titular, perfil ou âmbito —, e devolve-se «não encontrado» quando não tem.

Comentário: Alterações de interface não são controlo de acesso. Qualquer defesa que o cliente possa contornar não é defesa.

Pergunta 2. No laboratório encontraram duas falhas e nenhuma outra. Podem escrever no relatório que as restantes áreas da aplicação estão seguras?

Resposta: Não. Podem escrever que testaram dois casos, com que método e em que janela, e que essas áreas não foram testadas. Ausência de achado no que não foi testado não é prova de segurança.

Comentário: A honestidade do âmbito é o que dá valor ao relatório. Quem lê precisa de saber o que ficou de fora para decidir o que fazer a seguir.

Referências consultadas

• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.
• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.