API7:2019 Security Misconfiguration

Agentes Ameaça/Vetores Ataque	Falha Segurança	Impactos
Específico da API : Abuso 3	Prevalência 3 : Deteção 3	Técnico 2 : Específico Negócio
Os atacantes vão regra geral tentar encontrar falhas, endpoints comuns ou ficheiros e diretórios desprotegidos para ganhar acesso não autorizado ou conhecimento do sistema.	Falhas nas configurações de segurança podem acontecer em qualquer camada da API, desde o nível de rede ao aplicacional. Existem ferramentas automáticas para detetar e abusar destas falhas, tais como serviços desnecessários que se encontram em execução ou configurações antigas.	Estas falhas podem não só expor dados sensíveis dos utilizadores, mas também detalhes do sistema que permitam comprometer o servidor.

A API é vulnerável?

A API é vulnerável se:

As configurações para proteger o sistema estão em falta em qualquer das partes constituintes da API, ou se existem serviços na nuvem indevidamente configurados.
As últimas atualizações de segurança não foram aplicadas ou os sistemas estão desatualizados.
Existem funcionalidades ativas que não estão em uso (e.g., verbos HTTP).
A segurança do canal de comunicação não está assegurada: Transport Layer Security (TLS) em falta ou indevidamente configurado.
Diretivas de segurança não são enviadas aos clientes (e.g., cabeçalhos HTTP de segurança).
Não existe um política de Partilha de Recursos entre Origens (CORS) ou esta está indevidamente configurada.
As mensagens de erro incluem stack traces ou outra informação sensível.

Exemplos de Cenários de Ataque

Cenário #1

Um atacante encontra o ficheiro .bash_history na diretoria raiz do servidor, o qual contém os comandos usados pela equipa de DevOps para aceder à API:

$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='

O atacante pôde assim identificar novos endpoints da API, destinados exclusivamente ao uso pela equipa de DevOps e que não estavam documentados.

Cenário #2

Tendo em vista um serviço específico, um atacante usa um conhecido motor de busca de dispositivos diretamente acessíveis através da internet. O atacante encontrou um host a correr um conhecido sistema de gestão de base de dados, à escuta na porta padrão. Como o host estava a utilizar a configuração padrão, a qual tem o mecanismo de autenticação desativado por omissão, o atacante teve acesso a milhões de registo com informação pessoal (PII), preferências e dados de autenticação dos utilizadores.

Cenário #3

Inspecionando o tráfego de rede duma aplicação móvel, um atacante percebe que nem todo o tráfego usa um protocolo seguro (e.g., TLS), em particular aquele associado às imagens de perfil de utilizador. Como as interações do utilizador na aplicação são binárias, apesar do tráfego da API ser enviado de forma segura, o atacante identifica um padrão no tamanho das respostas da API, o qual usa para mapear as preferências do utilizador em relação ao conteúdo visualizado (e.g., imagens de perfil).

Como Prevenir

O ciclo de vida da API deve incluir:

Um processo de proteção reprodutível que possa ser implantado de forma fácil e rápida com vista a um ambiente de execução devidamente protegido.
Um processo de revisão e atualização de todas as camadas da API. A revisão deve incluir: ficheiros de orquestração, componentes da API e serviços na nuvem (e.g., permissões dos buckets S3).
Um canal de comunicação seguro para todas as interações da API no acesso a recursos estáticos (e.g., imagens).
Um processo automatizado para verificar de forma continua as configurações e definições em todos os ambientes (produção, staging, testes, desenvolvimento).

E ainda:

Para prevenir que stack traces sejam incluídas nas mensagens de erro ou outra informação sensível seja fornecida aos atacantes, quando aplicável, defina schemas e verifique que todas as respostas da API estão em conformidade.
Assegure que a API só é acessível através do verbos HTTP especificados. Todos os demais verbos HTTP que não são utilizados deverão estar desativados (e.g., HEAD).
As APIs destinadas a acessos por clientes a correr em navegadores (e.g., WebApps) devem implementar uma política de Partilha de Recursos Entre Origens (CORS) adequada.