kys8

relatorio/relatorio.tex

@@ -409,11 +409,11 @@ SecRule ARGS "(\"role\".*:.*\"admin\")|exec|cat|more|ls|dir|/etc/passwd" \
     "id:950006,phase:2,deny,status:403,msg:'Command Injection Detected',log"
 
 # path traversal
-SecRule ARGS "(\./|\.\./)|ftp|metrics|api-docs" \
+SecRule ARGS "\%00|\%2500|(\./|\.\./)|ftp|metrics|api-docs" \
     "id:950007,phase:2,deny,status:403,msg:'Path Traversal Attempt',log"
 
 # exposed stuff
-SecRule REQUEST_URI "ftp|metrics|api-docs" \
+SecRule REQUEST_URI "\%00|\%2500|ftp|metrics|api-docs" \
     "id:950008,phase:2,deny,status:500,msg:'Attempt to access ftp, metrics, api-docs',log"
 
 # rate limiting on login endpoint (max 5 requests per 30s per IP)
@@ -450,8 +450,9 @@ A vulnerabilidade de escalonamento de permissões (injeção do campo
 pela regra id:950006}, que deteta a sequência
 \texttt{"role".*:.*"admin"} nos argumentos do pedido e devolve
 \texttt{403 Forbidden}, impedindo a criação de contas com perfil de
-administrador. A enumeração de contas via mensagens de erro da aplicação
-permanece sem mitigação ao nível da WAF.
+administrador. 
+
+A enumeração de contas via mensagens de erro da aplicação \textbf{permanece sem mitigação} ao nível da WAF.
 
 \subsection{Authentication Testing}
 
@@ -459,26 +460,23 @@ As regras id:950009--950011 implementam um mecanismo de \textit{rate limiting} s
 endpoint de autenticação (\texttt{/rest/user/login}). Para cada endereço IP, é mantido
 um contador de pedidos com janela deslizante de 30 segundos: ao ultrapassar 5 tentativas
 nessa janela, o servidor devolve \texttt{429 Too Many Requests}, bloqueando eficazmente
-ataques de \textit{brute force} por dicionário. O bloqueio de contas após múltiplas
-tentativas falhadas permanece fora do âmbito da WAF, exigindo lógica aplicacional.
+ataques de \textit{brute force} por dicionário.
+
+O bloqueio de contas após múltiplas tentativas falhadas permanece fora do âmbito da WAF,
+exigindo lógica aplicacional.
 
 \subsection{Authorization Testing}
 
-O ataque de \textit{Null Byte} (\texttt{\%2500.pdf}) utilizado para
-contornar a validação de extensões de ficheiro no diretório
-\texttt{/ftp} não é diretamente mitigado pelas regras configuradas,
-pois o payload não contém nenhum dos padrões definidos (e.g.,
-\texttt{../}, \texttt{ftp} como argumento). A regra id:950007 teria de
-ser estendida para incluir sequências de \textit{null byte} codificadas
-(\texttt{\%00}, \texttt{\%2500}) para cobrir este vetor de ataque.
+A regra id:950007 e id:950008 bloqueiam o uso de \textit{null byte}
+codificadas para cobrir este vetor de ataque.
 
 \subsection{Session Management Testing}
 
 A configuração da WAF não tem capacidade de alterar os atributos dos
-cookies definidos pela aplicação. A flag \texttt{HttpOnly} do cookie
+cookies definidos pela aplicação. Logo, a flag \texttt{HttpOnly} do cookie
 \texttt{token} continua ausente, uma vez que esta é uma propriedade
-definida pela camada aplicacional do \textit{JuiceShop}. Ainda assim,
-a mitigação do XSS (id:950003), descrita na subsecção seguinte, reduz
+definida pelo \textit{JuiceShop}. Ainda assim, a mitigação do XSS
+pela regra id:950003, descrita na subsecção seguinte, reduz
 indiretamente o risco de roubo de sessão ao bloquear os vetores que
 permitiriam a sua exploração.
 
@@ -487,36 +485,41 @@ permitiriam a sua exploração.
 A regra de SQL Injection (id:950001) bloqueia com sucesso pedidos ao
 endpoint de pesquisa de produtos que contenham caracteres como
 \texttt{'}, \texttt{"}, \texttt{;} ou a sequência \texttt{--},
-devolvendo \texttt{403 Forbidden}. O payload utilizado pelo
-\textit{sqlmap} é interceptado nesta fase, impedindo a extração de dados
-da base de dados. A regra de XSS/injeção HTML (id:950003) bloqueia
-igualmente os payloads com tags
+devolvendo \texttt{403 Forbidden}.
+
+O payload utilizado pelo \textit{sqlmap} ou por outros fuzzers 
+com \textit{SQL injections} são interceptado nesta fase.
+
+A regra de XSS/injeção HTML (id:950003) bloqueia igualmente os payloads com tags
 \texttt{<img src="x" onerror="...">} e \texttt{<h1>}, neutralizando
-ambos os vetores de \textit{Reflected XSS} identificados na primeira
-etapa.
+ambos estes vetores de ataque.
 
 \subsection{Testing for Error Handling}
 
-A WAF atua sobre os pedidos antes de estes chegarem à aplicação, mas
-não filtra as respostas do servidor, uma vez que a diretiva
-\texttt{SecResponseBodyAccess} se encontra configurada como
-\texttt{Off}. Por consequência, a exposição do \textit{stack trace} do
-\textit{Express.js} em rotas inexistentes (e.g., \texttt{/ftp/teste})
-não é mitigada. Para suprimir respostas de erro detalhadas seria
-necessário ativar a inspeção do corpo da resposta e definir regras sobre
-o seu conteúdo, ou configurar páginas de erro personalizadas no Apache.
+A exposição do \textit{stack trace} do \textit{Express.js} em rotas
+inexistentes (e.g., \texttt{/ftp/teste}) aind não é mitigada. Para
+suprimir estas respostas de erro detalhadas era necessário ativar 
+a inspeção do corpo da resposta e definir regras sobre o seu
+conteúdo, ou configurar páginas de erro personalizadas no Apache.
 
 \subsection{Client Side Testing}
 
-O payload de exfiltração do token JWT via XSS
+O payload de exfiltração do token JWT via XSS 
 (\texttt{<img src="x" onerror="alert(localStorage.getItem('token'))">})
 é bloqueado pela regra id:950003, uma vez que contém a expressão
-\texttt{<.*>} nos argumentos do pedido de pesquisa. Desta forma, a
-cadeia de ataque identificada na primeira etapa --- que combinava a
-falha de XSS com o armazenamento inseguro do token --- é eficazmente
-neutralizada pela WAF ao nível da injeção inicial, impedindo a execução
-do código malicioso no contexto do navegador da vítima.
+\texttt{<.*>}. 
 
 \section{Conclusions}
 
+Foi feita uma análise extensa dos possiveis vetores de ataque da aplicação
+e com isso desenvolvemos uma \textbf{WAF} que cobriu uma maioria dos
+ataques. Contudo, as vulnerabilidades estruturais da aplicação, como a ausência de flags \texttt{HttpOnly} em cookies,
+a lógica de enumeração de utilizadores e a exposição de \textit{stack traces}, competem diretamente
+ao desenvolvimento seguro do código e à configuração do web server. 
+
+Em suma, com poucas regras simples foi possible bloquear a maioria das ameaças de 
+injeção de código malicioso, no entanto, para cobrir uma maior superficie
+de ataques seria necessário mudar a lógica interna da aplicação.
+
+
 \end{document}