Introdução
A fatura de uma loja registra as compras do cliente, o preço e seu endereço de cobrança. Clientes devem ler suas próprias faturas ou aquelas explicitamente compartilhadas com eles. Conhecer um ID não concede permissão para lê-lo.
Você tem autorização para testar o Invoice Desk sintético como Alex. Comece pelo acesso normal, compare uma fatura compartilhada com uma privada e salve a resposta privada para demonstrar a falha na fronteira de propriedade. O laboratório termina na validação; você não corrigirá o servidor. Apenas os objetos de treinamento fornecidos estão no escopo.
Estabelecer seu acesso normal
Nesta etapa, entre como Alex e obtenha sua própria fatura antes de testar outra conta.
Selecione a aba Invoice Desk na interface do laboratório para começar esta etapa.
Mude para a aba Invoice Desk. O diagrama mostra um cliente, que envia requisições, e um servidor de API, que responde. API é a interface de requisições da aplicação. API: ready vem de uma consulta real de saúde. A tabela descreve as regras esperadas:
| ID da fatura | Proprietário | Compartilhada com | Alex pode ler? |
|---|---|---|---|
inv-104 |
alex |
Ninguém | Sim: proprietário |
inv-208 |
morgan |
Ninguém | Não: privada |
inv-315 |
riley |
alex |
Sim: compartilhamento explícito |
No portal, informe usuário alex e senha shop-alex-42, depois selecione Sign in. Espere Signed in as alex. Digite inv-104 em Invoice ID e selecione View invoice. O campo owner deve ser alex.
Mude para a aba Client Terminal. É um espaço de cliente isolado em /home/student/project, não o servidor. invoice-api:8000 identifica o servidor na rede de treinamento, não um alvo público. curl envia requisições HTTP pelo terminal. HTTP é o protocolo de requisição/resposta usado aqui; GET solicita a leitura de um recurso. O caminho depois do endereço identifica esse recurso. -i inclui o status e os cabeçalhos da resposta.
Sem uma sessão, espere 401 Unauthorized, que exige login:
Mude para a aba Client Terminal antes de executar o comando a seguir.
curl -i http://invoice-api:8000/api/invoices/inv-104
Entrar no navegador não autentica o curl. Uma sessão é um registro no servidor de quem entrou; um cookie aleatório relaciona as próximas requisições a esse registro. O comando seguinte envia um objeto JSON, um formato de campos nomeados. -H define um cabeçalho que indica JSON, -d envia as credenciais e seleciona POST, e -c salva o cookie recebido em session.txt. Aspas simples mantêm espaços e aspas duplas juntos como um único argumento do shell.
curl -sS -c session.txt -H 'Content-Type: application/json' -d '{"username":"alex","password":"shop-alex-42"}' http://invoice-api:8000/api/login
-sS oculta o progresso, mas mostra erros de conexão. account deve ser alex. -b envia o cookie salvo. Confira a identidade da sessão:
curl -sS -b session.txt http://invoice-api:8000/api/me
Solicite sua fatura:
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-104
Leia invoice_id, owner, item e total_usd: Alex comprou Desk lamp por 38.00. A lista vazia shared_with, [], significa que ninguém mais recebeu acesso. Esse é o comportamento normal. A verificação usa a resposta real do servidor a Alex, solicitada pelo terminal ou pelo portal.
Se receber 401 após o login, repita o comando de login neste terminal e tente novamente com -b session.txt. Um erro de conexão é diferente: nenhuma resposta HTTP chegou; confira o endereço e API: ready.
Solicitar outra fatura
Nesta etapa, compare compartilhamento explícito com uma fatura privada mantendo a mesma identidade autenticada.
Selecione a aba Client Terminal na interface do laboratório para começar esta etapa.
Autenticação responde “Quem é você?”. Autorização responde “Esta pessoa pode ler esta fatura?”. Um login bem-sucedido estabelece apenas a primeira resposta. Primeiro baixe a fatura legitimamente compartilhada. Um download continua sendo GET; /download seleciona uma resposta destinada a ser salva, com os mesmos campos JSON.
Mude para a aba Client Terminal antes de executar o comando a seguir.
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-315/download
O proprietário é riley, mas shared_with contém alex. Esse acesso é permitido. Um proprietário diferente, sozinho, não demonstra falha.
Preveja o caso privado: inv-208 pertence a Morgan e não é compartilhada com ninguém, portanto Alex deveria receber uma negação, normalmente 403 Forbidden. Um serviço também pode usar 404 Not Found para ocultar a existência de um objeto privado. Aqui 404 também identifica um ID desconhecido. 200 OK significa que a requisição teve sucesso; o corpo mostra o que foi exposto.
-v exibe a requisição realmente enviada e os cabeçalhos recebidos. Também mostra o cookie da sessão de treinamento; não compartilhe essa saída fora do laboratório. Execute:
curl -v -b session.txt http://invoice-api:8000/api/invoices/inv-208
Localize GET /api/invoices/inv-208 e HTTP/1.0 200 OK. O corpo mostra proprietário morgan, lista de compartilhamento vazia, Studio microphone e endereço 82 Cedar Lane. O servidor entregou um objeto privado a Alex. Você mudou o caminho do objeto, não a identidade da sessão. IDs previsíveis facilitaram o teste; a ausência da verificação de permissões causou a exposição.
Mude para a aba Invoice Desk para repetir as duas requisições: Download invoice para inv-315 e View invoice para inv-208. O cliente web salva downloads no mesmo espaço de trabalho. A verificação exige o download compartilhado permitido e a visualização privada, não um arquivo explicativo.
Verificar a exposição
Nesta etapa, preserve o download privado real e relacione os dados expostos ao impacto no negócio.
Selecione a aba Client Terminal na interface do laboratório para começar esta etapa.
Use /download para a fatura privada. -o grava os bytes da resposta em um arquivo em vez de mostrá-los. Salve a resposta completa como private-invoice.json no espaço atual do cliente:
Mude para a aba Client Terminal antes de executar o comando a seguir.
curl -sS -b session.txt -o private-invoice.json http://invoice-api:8000/api/invoices/inv-208/download
cat exibe um arquivo para leitura:
cat private-invoice.json
Espere a mesma fatura de Morgan, com invoice_id inv-208, proprietário morgan, total 129.00 e endereço de cobrança. Se salvou um erro 401 ou a fatura compartilhada, faça login novamente se necessário e baixe a privada designada; -o substitui o arquivo.
Como alternativa, mude para a aba Invoice Desk. Conectado como Alex, informe inv-208 e selecione Download invoice. Esse cliente web encaminha a requisição real da API e salva a resposta inalterada em /home/student/project/private-invoice.json, que você pode ler após voltar à aba Client Terminal. Os dois métodos satisfazem o mesmo resultado.
Execute a verificação. Ela compara os bytes salvos com a fatura designada e confirma o registro do download no servidor sob a sessão de Alex. Uma afirmação copiada, fatura inventada, fatura compartilhada permitida ou arquivo sem download de cliente correspondente não demonstram o resultado.
O impacto prático é a divulgação de compras e endereço de outro cliente. O servidor deve verificar a propriedade ou o compartilhamento explícito para cada objeto solicitado, inclusive downloads. Ocultar links ou tornar IDs difíceis de adivinhar não substitui essa verificação. É o problema de autorização de objetos descrito pelo OWASP BOLA. Seu teste autorizado terminou; a correção do servidor fica para uma tarefa separada.
Resumo
Você estabeleceu uma sessão de cliente, leu sua fatura, distinguiu compartilhamento explícito de acesso privado e salvou uma resposta real entre contas. Verificou os dados expostos e a identidade que os recebeu, sem acesso ao servidor ou credenciais da vítima.
