Batman added

This commit is contained in:
jelly Tomas
2026-05-31 13:05:19 +01:00
parent 9b38b6385b
commit 5059041ec7
3 changed files with 26 additions and 1 deletions

Binary file not shown.

Binary file not shown.

View File

@@ -21,10 +21,13 @@
\newpage
\section{Introduction}
% FAZER EM ENGLISH???
% 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}
@@ -36,11 +39,21 @@ Vão ser realizadas duas etapas de testes: primeiro, sem WAF (\textit{Web Applic
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}
% 10.60.0.0 - rede externa
% 20.60.0.0 - rede interna
\subsection{Servers}
% 10.60.0.1 - router
% 20.60.0.2 - client
@@ -57,6 +70,14 @@ Juicebox no port 3000
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, selecionámos os cinco alertas principais com base no maior nível de risco e grau de confiança reportados pela ferramenta.
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 selecionar os cinco alertas principais com base no nível de risco e grau de confiança reportado pela ferramenta.
\begin{itemize}
\item \textbf{Sql Injection Vulnerability in product search}
\item \textbf{}
\item \textbf{}
\item \textbf{}
\item \textbf{}
\end{itemize}
Adicionalmente, realizámos testes de infraestrutura e mapeamento de vetores utilizando ferramentas especializadas:
\begin{codeblock}{bash}
@@ -72,6 +93,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}
@@ -188,6 +210,9 @@ sqlmap -u "http://10.60.0.1:3000/rest/products/search?q=apple" -p q --dbms=sqlit
| sqlite_sequence |
+-----------------------+
\end{codeblock}
\subsubsection{Testing for SQL Injection}
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}