SEG Lab 3 - Cross-Site Request Forgery Attack Lab

Conteúdos

• Modelo Relatório
• SEG Lab 1 - Web SQL Injection
• SEG Lab 2 - Cross-Site Scripting (XSS) Attack Lab
• SEG Lab 3 - Cross-Site Request Forgery Attack Lab
• SEG Lab 4 - Packet Sniffing and Spoofing Lab
• SEG Lab 5 - ARP Cache Poisoning Attack Lab
• SEG Lab 6 - ICMP Redirect Attack Lab
• SEG Lab 7 - TCP Attacks

Nome da Atividade: SEG Lab 3 - Cross-Site Request Forgery Attack Lab

Nome e Matrícula: Lucas Lima do Nascimento - 12111ECP024

3.1. Task 1. Observing HTTP Request

Algumas requisições que ocorrem no site ao atualizar o perfil de um usuário e carregar a página

Olhando essas requisições mais de perto, podemos ver o cabeçalho e o corpo da requisição

3.2. a) Task 2: CSRF Attack using GET Request

Analisando a requisição feita pelo botão de adicionar amigo, temos:

Ou seja, uma requisição GET para essa rota (removendo os tokens de segurança) faria a adição da Alice como amiga. Como nesse caso, gostaríamos que, quando Alice entrar na página, ela nos adicione como amigo, devemos substituir o GUID 56 pelo nosso, que pode ser descoberto ao editar o perfil do nosso usuário.

Dessa forma, o código da página fica:

Para validar que o comportamento está correto, entrei na conta da Alice, para simular o que aconteceria caso ela entrasse no link.

Ao clicar na página do atacante, o esperado não aconteceu. Provavelmente por que eu uso a versão mais recente do Firefox, como dito na documentação.

Ainda é possível testar a execução da ideia, jogando a URL alvo no navegador (que também fará um GET request) para testar se isso funciona mesmo.

Somos recebidos com uma página em branco, o que indica que o servidor aceitou a requisição

E ao recarregar o perfil de Samy, notamos que a adição ocorreu.

3.3. a) Task 3: CSRF Attack using POST Request

Observando novamente o POST feito pela edição de perfil, podemos notar os valores necessários para construir o formulário.

Ao acessar a URL, recebemos um redirecionamento imediato, e o perfil é devidamente atualizado:

Pergunta 1) Boby pode tentar enviar uma mensagem para Alice. O seu GUID aparecerá na URL e o do alvo, no código da página. ;)

Pergunta 2) Para lançar o ataque de edição de perfil, precisamos do nome e do GUID do alvo. Se essas informações forem possíveis de se obter de outra forma é possível lançar o ataque. Caso elas sejam restritas ao domínio do site, como é o caso de cookies, ou local storage, não é possível.

4.1. a) Task 4: Enabling Elgg’s Countermeasure

Dessa forma, valores de tokens, cookies e localStorage, são acessíveis somente de dentro da URL, fazendo com que atacantes externos não consigam lançar os ataques.

Perfil antes do ataque:

A página:

O perfil depois do ataque:

4.2. a) Task 5: Experimenting with the SameSite Cookie Method

Ao acessar, obtemos essa página web:

Clicando no Link A, obtemos:

Em um same-site request, obtemos o acesso à todos os cookies (nas fotos, ações A, B e C, respectivamente):

Já clicando no Link B, obtemos:

Em um cross-site request, não recebemos todos os cookies, sempre recebemos o cookie-normal, mas os cookies com política lax e strict variam de acordo com a requisição.

Requests GET, é possível acessar os cookies-lax, POST não. No caso dos cookies-strict, nem requisições GET nem POST retornaram seu valor (nas fotos, requisições A, B e C, respectivamente).

Essa política de cookies, pode nos ajudar a definir se uma requisição vem ou não do mesmo site, com base na possibilidade de acesso desses valores, facilitando a implementação de detecção e bloqueio à ataques CSRF.

Essa ideia poderia ser usada no site Elgg, adicionando um cookie do tipo strict ao site nas validações das operações CRUD, fazendo com que requisições POST e GET fossem somente possíveis dentro da URL correta.