Owasp Notes

O documento aborda diversas vulnerabilidades de segurança em aplicações web, incluindo controle de acesso quebrado, configurações de segurança inadequadas e componentes desatualizados. Também discute a importância de logs, JWT, e as ameaças de injeção, XSS, e deserialização insegura. Além disso, fornece dicas sobre como identificar e mitigar essas vulnerabilidades.

Enviado por

Suetham Gamer

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd

0% acharam este documento útil (0 voto)

5 visualizações3 páginas

Owasp Notes

Enviado por

Suetham Gamer

Direitos autorais

Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.

Formatos disponíveis

Baixe no formato TXT, PDF, TXT ou leia on-line no Scribd

Você está na página 1/ 3

# Broken Access Control

sites possuem páginas que certos usuários não deviam ter acesso, como páginas de
admin ou de outros usuários.
- IDOR é um exemplo

> DICA: olhar os comentários dos códigos fontes SEMPRE, às vezes rola de ter uma
coisinha ou outra

> DICA: programar é uma ótima maneira de entender como a lógica de uma feature pode
ter sido implementada, e como ela pode ser explorada

# Security Misconfiguration
- contas padrão com senhas padrão
- usuário anonymous do ftp
- serviços com configurações inseguras (permissão, acesso, autenticação, etc...) ->
falta de security hardening
- mensagens de erro com muitos detalhes, ou até mesmo a aplicação retornando
mensagens de erro do back-end
- HTTP sem o uso de Secure Headers (como o CSP)
- features desnecessárias (portas abertas sem motivo, páginas, serviços, etc...)

# Vulnerable and Outdated Components

- software desatualizado e com vulnerabilidades conhecidas
- por exemplo: possui uma CVE conhecida que pode ser explorada com um exploit do
exploit-db
- essas falhas podem ser exploradas pesquisando um exploit para ela, como são
falhas conhecidas provavelmente terá um exploit público em algum lugar

# Software Integrity
- `<script src="https://code.jquery.com/jquery-3.6.1.min.js" integrity="sha256-
o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ=" crossorigin="anonymous"></script>`
- https://www.srihash.org/ -> pode-se usar esse site para gerar hash de arquivos
obtidos por um link de download, dessa forma você garante a integridade desse
arquivo
- isso serve para evitar o uso de um arquivo modificado por um atacante no servidor
do jquery

# JWT
- Header (informações do algoritmo de hash usado na assinatura)
- Payload (os dados de fato)
- Assinatura (um hash gerado por um HMAC da concatenação do header e do payload
juntamente a um secret)
O JWT é apresentado em forma de base64, com um . separando cada campo do token
- Exemplo de JWT:
- Header: {"typ":"JWT","alg":"HS256"}
- Payload: {"username":"guest","exp":1704631635}
- Assinatura: um hash gerado por uma função HMAC
- Esse JWT pode ser vulnerável. É possível alterar o valor de "alg" para "none",
dessa forma o backend da aplicação vai entender que deve armazenar o token sem
realizar a assinatura
- Dessa forma é possível alterar qualquer valor do token (como o username) e roubar
outras contas sem o backend verificar a integridade desse token

# Logs
- Deve logar:
- HTTP status codes
- endereços IP
- usernames
- páginas / endpoints de API acessados
- tempos de acesso
- Atividades suspeitas:
- várias tentativas de acesso não autorizado (pode estar tentando acessar um
painel de admin ou algo do tipo)
- requisições de regiões estranhas (descobertas pela geolocalização do IP)
- uso de ferramentas automatizadas (é fácil de perceber: a velocidade das
requisições e o valor do User-Agent)
- uso de payloads maliciosas (teste de falhas)

# SSRF
- geralmente ocorre quando a aplicação faz uso de serviços de terceiros
- um servidor pode ter uma feature que envia uma requisição para outro servidor
(serviço de terceiros)
- caso seja possível para o usuário alterar qual servidor essa feature vai enviar a
requisição, existe uma possibilidade de SSRF
- é possível fazer com que a feature faça com que o servidor envie uma requisição
para o servidor do atacante, confiando como se fosse um servidor legítimo
- dependendo das informações contidas nessa requisição é possível explorar
diferentes ataques
- enumerar redes internas
- abusar da confiança entre os servidores e conseguir acesso a serviços restritos
- interagir com outros serviços para buscar um RCE

# Injection
- acontece quando o sistema nao sanitiza o input recebido pelo usuario
- Command injection
- XSS
- SQL

# Broken Auth
- brute force
- credenciais fracas
- cookies de sessão previsíveis (como cookies que usam MD5)
- re-registrar (colocar espaço antes do nome pra quebrar a lógica do programador)

# Sensitive Data Exposure

- ler o codigo e os comentarios
- navegar pelos diretorios

# XXE (XML eXternal Entity)

- in-band > recebe resposta imediata do payload enviado
- out-of-band (blind-xxe) > o atacante tem que refletir o output do payload pra um
arquivo ou para seu proprio servidor
- `<!DOCTYPE root>` > DTD, define a estrutura, elementos e atributos do documento
XML
- !ENTITY ext SYSTEM "http://site.com" > uma xml entity é como uma variavel, o
SYSTEM é como uma variavel externa (o valor dela é carregado por um link)
- `<!DOCTYPE root [<!ENTITY ext SYSTEM 'file:///etc/passwd'>]>` > payload para
retornar o /etc/passwd

# XSS (Cross Site Scripting)

- Stored > o codigo é armazenado no banco de dados (como em mensagens)
- Reflected > o codigo é refletido na pagina (como em pesquisas com parametro na
url)
- DOM > é como um XSS refletido, mas o responsavel por essa reflexão é o client
side (codigo javascript da pagina que interage com o DOM se baseando em parametros
passados pelo cliente, como URL, query strings, http headers, etc.). É possível
executar um DOM based xss sem que o servidor possa registrar nada, como no uso de
parametros passados após o # na URL (os navegadores omitem esses parâmetros para o
servidor, pois são tratados no lado do cliente)

# Insecure Deserialization
- deserialization = decodificação (como quando voce converte binario, ou base64 pra
texto)
- a insecure deserialization seria a confiança na decodificacao de dados de uma
fonte insegura (atacante) sem nenhuma verificacao, isso é perigoso, pois esses
dados podem ter sido alterados pela fonte
- um exemplo de insecure deserialization é a confiança em cookies base64 enviados
para o servidor por parte de uma fonte insegura (atacante), que podem ter sido
editados e codificados em base64 antes do envio
- pode levar a RCE quando o servidor executa os comandos decodificados (isso pode
ocorrer quando o servidor passa esse input por uma funcao vulneravel, como o pickle
do python)

# Components With Known Vulnerabilities

- o site usa um sistema de terceiros desatualizado que contem uma vulnerabilidade
conhecida
- exploit-db e site do cve podem ajudar
- procurar versoes no codigo, sistemas de terceiros, telas de erro, etc.