Dicas para validar falsos positivos em SAST
Hoje, resolvi trazer algumas dicas para quem está iniciando na área de AppSec/DevSecOps. Era um assunto que eu realmente queria muito escrever e resolvi escrever alguns trechos de códigos pro artigo👩💻💜
Algo muito comum da nossa rotina é analisar código de alguma ferramenta proveniente de Teste Estático de Segurança (SAST). Existem várias ferramentas de SAST como Snyk, Checkmarx, Fortify e AppScan, por exemplo. Entre todas elas, existe a fase para validação de falso positivo, justamente porque não existe ferramenta com 100% de veracidade para vulnerabilidade. No entanto, quanto mais a ferramenta tiver flexibilidade para criar suas próprias regras com o uso de regex (expressão regular), isso aumentará a veracidade de encontrar realmente uma vulnerabilidade no código
Vamos começar! ✨
# SQL Injection
## 1
Nesse primeiro código, não temos uma vulnerabilidade. Podemos perceber que estamos parametrizando as variáveis que são do tipo String, utilizando o método setParameter(). Assim, garantimos exatamente a string passada, onde não poderemos passar um payload como ' or 1=1 (onde possui caractere especial)
## 2
Nesse segundo exemplo, além de parametrizar utilizando o parâmetro "codigo", também vemos a utilização do tipo long (variável do tipo número). Dessa maneira, já vemos que nesse campo não teria mesmo como um payload ser aceito
### 3
Código vulnerável, por poder adicionar um payload nos parâmetros USER e Password
# Parameter Tempering
Aqui, podemos ver que não há vulnerabilidade, justamente por não ser do tipo String e sim, long {id}.
Caso fosse string, deveríamos utilizar algum tipo de escape, como Encode.forHtml(variavel) ou regex , como " /^[A-Za-z0–9]+(?:[ _-][A-Za-z0–9]+)*$/"
# Hardcoded Password
As vezes, as ferramentas de SAST, apenas por encontrar a palavra "password" no código, já entende que o código contém uma senha hardcoded.
Nesse exemplo acima, podemos ver que a palavra password é apenas para declarar uma variável de ambiente (env) — que é o jeito certo de não expor senha em código.
# XSS
Aqui, podemos ver que não há vulnerabilidade, justamente por não ser do tipo String e sim, long {id}.
# CSRF
Aqui nesse código, vale comentarmos duas ideias. A primeira, é verificar a sessão quando for se autenticar (fazer o login) na aplicação. Isso deve ocorrer para evitar que alguma informação do sistema não possa ser acessado sem se autenticar.
A segunda situação, utilizar alguns headers na aplicação para evitar algumas vulnerabilidades . Nesse exemplo, csrf().disable() torna a aplicação vulnerável a CSRF. Portanto, devemos remover a opção disable.
Outro ponto, sobre cabeçalhos, sempre usar para evitar algumas vulnerabilidades como XSS, forçar uso de HSTS e ClickJacking:
http.headers().xssProtection().and().contentSecurityPolicy(“script-src ‘self’”).contentTypeOptions().httpStrictTransportSecurity().frameOptions()
e adicionar no arquivo pom.xml (caso seja uma aplicação Java e que utilize SpringBoot)
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId> <version>5.3.3.RELEASE</version>
</dependency>
# File Transversal
Aqui, podemos ver a forma de evitar a vulnerabilidade de file transversal. Devemos sempre criar uma white list (permitindo apenas o que esperamos de diretório) para não deixar que o usuário possa encontrar a vulnerabilidade e acessar arquivos do servidor
Deixo aqui três links que podem ajudar ainda mais pessoas a iniciar a tarefa de validação e entendimento de código 😊
Para saber sobre as vulnerabilidades aqui citadas, recomendo esse link
Espero que gostem 💜
