vasco/FSI
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge

Browse Source
This commit is contained in:
vasco
2026-05-31 13:35:20 +01:00
parent 89b17901a9 5059041ec7
commit a17feb0e1b
8 changed files with 121 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
relatorio/relatorio.tex
View File

@@ -22,9 +22,14 @@
\section{Introduction}
% FAZER EM ENGLISH??? O prof é BR temos que fazer em Brazileiro
Este trabalho tem como objetivo realizar testes de penetração numa aplicação
cobaia (o \textit{Juicebox}) desenhada para aprendizagem.
Este trabalho tem como objetivo utilizar o \textbf{WSTG} (Web security testing guide) e configurar um ModSecurity reverse proxy como uma \textbf{WAF}.
Para esse fim temos uma aplicação cobaia (o \textit{Juicebox}) desenhada para aprendizagem que vamos utilizar num ambiente controlado para aprender como descobrir vulnerabilidades (aplicando o \textbf{WSTG} e recorrendo ao \textbf{OWASP ZAP}) e prevenir antes do serviço estar online (elaborando uma \textbf{WAF}).
\section{Architecture Considered for Both Stages}
Utilizámos somente duas máquinas virtuais: um servidor a correr \textit{CentOS 9}
@@ -32,21 +37,31 @@ e um cliente a correr \textit{Kali Linux}. O servidor contém o serviço \textit
que age como \textit{firewall} através do módulo \textit{ModSecurity}, e um servidor
\textit{Node.js} que aloja o \textit{Juicebox} --- a aplicação que vai servir de cobaia (\textit{dummy}).
Vão ser realizadas duas etapas de testes: primeiro, sem WAF (\textit{Web Application Firewall})
e com foco em explorar vulnerabilidades na aplicação; e, posteriormente, com uma WAF configurada para
mitigar as várias vulnerabilidades que foram encontradas na etapa anterior.
% Vão ser realizadas duas etapas de testes: primeiro, sem WAF (\textit{Web Application Firewall})
% e com foco em explorar vulnerabilidades na aplicação; e, posteriormente, com uma WAF configurada para
% mitigar as várias vulnerabilidades que foram encontradas na etapa anterior.
% Para simular utilizámos \textit{Virtual Box}, como nos outros projetos, para criar as maquinas virtuais. O cenario que foi criado tem duas máquinas virtuais (servidor e cliente), e ambas as maquinas estão ligadas há mesma rede interna. O servidor vai ser executado numa das maquinas e vai ter o sistema operativo \textit{CentOS 9}, edereço 20.60.0.1, alojar um servidor \textit{Node.js} com o \textit{Juicebox} (a aplicação cobaia) na port 3000 e contém o seviço \textit{Apache} que através do módulo \textit{ModSecurity} funcionará como \textbf{WAF}. O cliente vai ser processado na maquina com o sistema operativo \textit{Kali Linux} e vai ter o edereço 20.60.0.2.
Com o ambiente criado foram realizadas duas etapas de testes:
\begin{itemize}
\item \texttt{Primeira etapa}: Explorar vulnerabilidades na aplicação que existem sem a \textbf{WAF}
\item \texttt{Segunda etapa}:Verificar que vulnerabilidades foram mitigadas da primeira etapa com o uso de uma \textbf{WAF} configurada.
\end{itemize}
Realisticamente estas etapas podiam continuar a repetir-se, até que estivessemos satisfeitos com o resultado, mas para o fim deste projeto estas etapas serão suficientes.
\subsection{Network structure}
\begin{itemize}
\item \textbf{Client (20.60.0.0/24)} – Cliente.
\item \textbf{Server (10.60.0.0/24)} – Apache+ModSecurity e JuiceShop.
\item \textbf{Client (20.60.0.0/24)} Cliente.
\item \textbf{Server (10.60.0.0/24)} Apache+ModSecurity e JuiceShop.
\end{itemize}
\subsection{Servers}
\begin{itemize}
\item \textbf{10.60.0.1} – Servidor CentOS 9 com WAF e aplicação JuiceShop.
\item \textbf{10.60.0.1} Servidor CentOS 9 com WAF e aplicação JuiceShop.
\end{itemize}
\subsection{Services}
@@ -65,7 +80,9 @@ mitigar as várias vulnerabilidades que foram encontradas na etapa anterior.
Utilizámos a política por omissão (\textit{default policy}) para a realização do \textit{Active Scan} através do OWASP ZAP. Com esta abordagem, obtivemos múltiplos alertas automáticos. De forma a priorizar a análise, investigamos as alertas principais com base no maior nível de risco e grau de confiança reportados pela ferramenta.
Adicionalmente, realizámos testes de infraestrutura utilizando ferramentas especializadas:
Para conseguir informação inicial realizamos um \textit{Active Scan} através do \textit{OWASP ZAP}, o policy utilizado para esse scan foi \textit{Default Policy}. Foi obtido vários aletas automáticos devido a esse scan e decidimos investigar as alertas principais com base no nível de risco e grau de confiança reportado pela ferramenta.
Adicionalmente, realizámos testes de infraestrutura utilizando ferramentas especializadas:
\begin{codeblock}{bash}
sqlmap -u "http://192.168.1.1:3000/rest/products/search?q=apple" -p q --level=5 --risk=3 --banner
@@ -81,6 +98,7 @@ Paralelamente, realizámos uma descoberta de ficheiros e diretórios através de
\item \texttt{/api-docs}: Documentação e esquemas estruturais da API.
\end{itemize}
\subsection{Configuration and Deployment Management Testing}
\subsubsection*{Enumerate Infrastructure and Application Admin Interfaces}
@@ -172,6 +190,7 @@ Durante a auditoria à barra de pesquisa de produtos, validámos a existência d
O filtro falhou ao inspecionar este atributo e o navegador executou o código JavaScript com sucesso quando a imagem falhou o carregamento.
\end{enumerate}
\subsubsection{Testing for SQL Injection}
Adicionalmente, explorámos o mesmo parâmetro de pesquisa recorrendo ao \textit{sqlmap} para validar falhas de injeção SQL, conseguindo extrair com sucesso a estrutura de 22 tabelas da base de dados:
\begin{codeblock}{bash}
@@ -204,6 +223,9 @@ sqlmap -u "http://10.60.0.1:3000/rest/products/search?q=apple" -p q --dbms=sqlit
+-----------------------+
\end{codeblock}
Apesar de não ter sido detetado pelo active scan foi feito fuzzing nos detalhes de login para saber se estava vulneravel a esse tipo de ataques visto que existia essa vulnerabilidade noutros paremetros. Verificamos que de facto também estava vulneravel a SQL Injection, e que a resposta era a tabela com o
\subsection{Testing for Error Handling}
Ao tentar forçar o acesso a uma página ou ficheiro inexistente no servidor de ficheiros, como por exemplo na rota \texttt{/ftp/teste}, a aplicação falhou ao tratar a exceção de forma segura. Em vez de apresentar uma página de erro genérica (404), o servidor devolveu uma resposta detalhada expondo o \textit{stack trace} completo do ambiente \textit{Express.js}, revelando caminhos internos do sistema de ficheiros do servidor.
@@ -240,4 +262,4 @@ A execução deste vetor permitiu extrair o conteúdo do token diretamente do ar
\section{Conclusions}
\end{document}
\end{document}