Diário de Bordo – Júlio César Costa

Disciplina: Gerência de Configuração e Evolução de Software

Equipe: OWASP Red Team

Comunidade/Projeto de Software Livre: Pencil Labs / EJ-Application

Sprint 1 – 10-09-2025 - 23/09/2025

Resumo da Sprint

Estudo inicial de ataques mais frequentes e vulnerabilidades mais comuns de SQL Injection, XSS e CSRF em aplicações definidas pelo OWASP, familiarização e configuração do ambiente de ataque (Kali Linux).

Atividades Realizadas

Data	Atividade	Tipo (Código/Doc/Discussão/Outro)	Link/Referência	Status
15/09	Estudo sobre SQL Injection	Estudo	SQL Injection SQL Injection Prevention	Concluído
15/09	Estudo sobre CSRF	Estudo	CSRF Clickjacking	Concluído
18/09	Estudo sobre XSS e Clickjacking	Estudo	XSS	Concluído
18/09	Estudo sobre IDOR	Estudo	IDOR	Concluído
20/09	Preparação do ambiente de pentest (Kali Linux)	Outro	-	Concluído

Estudos

SQL Injection

Nos meus estudos sobre SQL injection identifiquei que acontece geralmente quando algum input do usuário é processado no backend sem o devido tratamento e passado diretamente para a query SQL que pode ou não retornar algum valor (Blind SQL Injection), quando a resposta não é retornado ao usuário o atacante tem outras formas de saber se o SQL Injection funcionou por meio de comandos SQL timers (sleep) ou operações que demorem muito tempo, ele irá usar um contador de tempo e caso demore o ataque foi bem sucedido, o objetivo final dos atacantes com SQL Injection é exfiltrar os dados sigilosos das empresas para vender por meio de moedas não rastreáveis como Bitcoin, alguns outros atacantes também tem como objetivo a destruição dos dados e inviabilizar a empresa atacada de operar caso ela não tenha backups.

Para se proteger deste tipo de ataque é necessário o devido tratamento dos inputs que serão mandados para um comando SQL, na verdade, sempre realizar o tratamento de inputs de usuários em toda circunstancia, para evitar possíveis problemas futuros. Nos meus estudos identifiquei quatro técnicas de defesa:

Consultas Parametrizadas: Basicamente toda a query do usuário seria tratada como uma string e os inputs seriam passados como parâmetros para funções API de bancos de dados.
(CUIDADO) Stored Procedures: Similar as consultas parametrizadas, com a diferença que o banco de dados armazena o procedimento parametrizado e a aplicação só chama este procedimento, o perigo está em que para executar este procedimento geralmente é requerido um nível de acesso alto no banco de dados, então se a aplicação for hackeada o atacante poderá ter acesso a praticamente toda a base de dados.
Allow-list input validation: Esta técnica é só recomendada para quando o desenvolvedor está usando parâmetros fornecidos pelos usuários para decidir diretamente a tabela a ser consultada, o que não é seguro e deve-se futuramente reescrever o código, funciona basicamente como um switch case com os valores de tabela ou coluna permitidos e um caso default quando não for um valor válido.
(INSEGURA) Escaping All User Supplied Input: O tratamento dos inputs dos usuários pode ser convertido para um formato tipo HTML, mas isso não é garantido de prevenir ataques e deve ser usado técnicas como consultas parametrizadas.

CSRF (Cross Site Request Forgery)

Ocorre quando um site faz ações em outro site aproveitando-se dos cookies salvos no navegador do usuário, por exemplo o website pode criar um form ou botão que manda um POST request para um website de banco (imaginando que o usuário está logado neste website) para enviar dinheiro para a conta dele.

Para se defender desse tipo de ataque existem três práticas bem conhecidas:

CSRF Tokens: Quando o servidor manda a página para o usuário, ele envia um valor aleatório para o usuaŕio que pode mudar frequentemente, toda vez que o usuário mandar uma requisição ele irá mandar também este token e a aplicação irá verificar este token antes de realizar qualquer ação.
Fetch Metadata: São uma coleção de headers HTTP que informam melhor sobre o contexto da requisição, por exemplo o header Sec-Fetch-Site informa ao servidor se a requisição tem a mesma origem, mesmo site, cross-site ou iniciada diretamente pelo usuário.
Evitando Requests Simples: Se o website usa fetch() ou XMLHttpRequest ele pode se proteger ao costumizar as requisições HTTP usando headers próprios ou diferentes tipo de conteúdo como JSON.

XSS (Cross-site Scripting)

Consiste em fazer o site executar código malicioso como se fosse um código do próprio website (same-origin), acontece quando a aplicação aceita um input do usuário e incluí este input na página sem tratamento. O atacante pode colocar o código Javascript em um parametro de alguma requisição GET, se o site usar este input para construção da página, sem fazer o devido tratamento, o atacante poderá usar este script para exfiltrar informações, persistir código malicioso na aplicação ou se passar por um usuário legitimo.

Para se defender de XSS, existem duas defesas principais:

Tratamento de inputs e codificação de output
CSP (Content Security Policy): Com o CSP é possível especificar de onde a página pode carregar conteúdos JavaScript, imagens e CSS. É possível usar Content-Security-Policy: default-src 'self'; img-src: 'self' para apenas permitir scripts e imagens de same-origin que o documento.

IDOR

Este tipo de ataque acontece quando uma aplicação web não possuí um controle de acesso adequado em que usuários não podem ver dados de outros usuários, por exemplo, uma aplicação pode verificar se o usuário está autenticado, mas não verifica se ele tem autorização para acessar o objeto.

Para se proteger contra IDOR é necessário que seja feito uma verificação de autorização para cada objeto que o usuário tentar acesso e também evitar de colocar informações especificas do usuário na URL como email, nome e IDs, em vez disso é possível usar UUIDs.

Maiores Dificuldades

Não houve dificuldades

Aprendizados

Maior aprofundamento dos conteúdos de cibersegurança e familiarização com o Kali Linux que foi bem rápida, pois já tenho familiaridade com sistemas Linux e distros derivadas do Debian

Plano Pessoal para a Próxima Sprint

[ ] Pesquisar e usar ferramentas de SQL Injection na aplicação local (Docker) da EJ