Autor: Eduardo R. B. Marques, DCC/FCUP
Neste projecto consideramos a deteção e correção de vulnerabilidades sobre uma aplicação Web, a Java Vulnerable Lab (JVL), uma aplicação desenvolvida pela Cyber Security and Privacy Foundation, com funcionalidade organizado em "servlets" Java / Java Server Pages (JSP).
Pretende-se que analise e modifique uma versão da JVL disponibilizada na forma de um projecto Maven recorrendo a:
Análise estática de código num ambiente SonarQube, empregando os analisadores FindSecBugs e o sub-conjunto de regras segurança do SonarJava.
"Pen-testing" usando o Zed Attack Proxy e o sqlmap.
Deverão ter em conta as seguintes condicionantes para avaliação:
Realização: individual ou em grupo de 2 alunos.
Valorização: peso de 4/20 valores na nota final.
Entrega: até 13 de Novembro de 2019 (inclusive) deve enviar um email ao docente (edrdo@dcc.fc.up.pt) com os seguintes anexos:
Considere os vários grupos de funcionalidades da JVL para análise, por exemplo:
Além de Forum (obrigatória), selecione outras 3 funcionalidades para análise. Para cada uma das 4 funcionalidades, considere todas as vulnerabilidades no código associado do tipo XSS (reflectido ou persistente), SQLi, ou relacionadas com cookies:
1. Use os relatórios de análise estática, ZAP e (para SQLi) sqlmap para encontrar evidências de vulnerabilidades.
2. Considere como as vulnerabilidades podem ser exploradas, ilustrando para XSS e SQLi possíveis pedidos maliciosos feitos pelo ZAP, sqlmap, ou um "script" customizado por si se achar necessário;
3. Acerte o código para eliminar as vulnerabilidades e valide se as mesmas deixam de ser reportadas pela análise estática e "pen-testing" (veja nota sobre XSS e análise estática no fim deste documento);
4. Apresente no relatório do projecto a informação relevante aos pontos anteriores (1-3), i.e. forneça detalhe (1) sobre a evidência de vulnerabilidades, (2) como estas podem exploradas, e (3) como acertou o código.
Para o exemplo Change password, acessível em Vulnerabilities / A8: CSRF e ainda outra funcionalidade da JVL à sua escolha que envolva um formulário:
Explique como se poderia materializar um ataque de CSRF. Pode por exemplo ilustrar o ataque recorrendo a uma página HTML maliciosa.
Implemente no código um esquema de "anti-CSRF tokens". Pode considerar por ex. um esquema de "synchronization token" ou "double submit", discutidos na aula.
Apresente no relatório do projecto a informação relevante aos pontos anteriores (1-2), i.e. forneça detalhe (1) sobre como conduzir uma ataque CSRF e (2) como implementou o esquema de "anti-CSRF" tokens.
Além das vulnerabilidas relacionadas com XSS, CSRF, SQLi, ou uso de "cookies", os relatórios do SonarQube e/ou ZAP deverão indicar outras vulnerabilidades.
Para 3 vulnerabilidades de tipos distintos, e tendo em conta um exemplo no código da JVL por cada um dos tipos:
Analise de forma geral qual o risco de segurança, e se possível exemplifique um ataque que a explora.
Acerte o código para eliminar ou mitigar a vulnerabilidade.
Apresente no relatório do projecto a informação relevante aos pontos anteriores (1-2).
A análise estática poderá reportar alguns avisos relativos a XSS que poderão ser ignorados, em particular o valor de input err usado para funcionamento interno e ainda a dados básicos relativos à sessão HTTP guardados no servidor, desde que estes não relevem informação sensível).
Regra geral, deverá no entanto assumir como potencialmente maliciosos na perspectiva de XSS dados obtidos via:
Quando considerar necessário um passo de sanitisação de dados no código, pode empregar métodos da classe org.apache.commons.text.StringEscapeUtils. Estes métodos permitem "escaping" de caracteres especiais em vários formatos, em particular de HTML. Após a incorporação de código de sanitisação, a análise estática poderá no entanto continuar ser "cega" à mesma e continuar a assinalar a vulnerabilidade (como falso positivo), mas não em princípio "pen-testing" com ZAP se a vulnerabilidade tiver sido removida.
O mapeamento entre URLs de accesso à JVL e classes de servlets implementadas em Java ou JSP é descrito pelo ficheiro src/main/webapp/WEB-INF/web.xml (veja secções <servlet-mapping> e <servlet>).
Tutoriais Oracle:
Deverá usar "prepared statements" para eliminar possibilidade de injeção de SQL. Para além das referências/exemplos dados nos relatórios SonarQube, poderá ajudar consultar: