blog

Jul 07, 2023

API7:2019 Configuração incorreta de segurança: o quê, exemplos de exploits e métodos de prevenção

Home » Calendário editorial » Segurança da API » API7:2019 Erro de configuração de segurança:

Página inicial » Calendário editorial » Segurança de API » API7:2019 Configuração incorreta de segurança: o que, exploits de amostra e métodos de prevenção

Erros de configuração de segurança são riscos de segurança muito comuns, não apenas em aplicativos da Web, mas também em APIs. Eles têm consistentemente feito parte das 10 principais vulnerabilidades de aplicativos da Web da OWASP. Eles faziam parte do OWASP Top 10 API Security Risks original publicado em 2019 e agora chegaram à lista atualizada de 2023.

A configuração incorreta de segurança mantém sua 7ª posição emOWASP Top 10 API 2023RCdevido à sua ampla prevalência, facilidade de exploração e fácil detecção.

O que exatamente são configurações incorretas de segurança? O que os causa e como mitigá-los? Continue lendo para descobrir.

Erros de configuração de segurança são os erros e descuidos cometidos durante a configuração, implementação ou manutenção de uma API que podem levar a vulnerabilidades de segurança. Isso acontece quando os desenvolvedores/equipes de TI não seguem as práticas recomendadas de segurança na implementação e configuração de APIs.

As configurações incorretas de segurança podem ocorrer devido à falha dos desenvolvedores e das equipes de segurança de TI em proteger a superfície de ataque com configurações adequadas de forma adequada.

Significa simplesmente que as configurações essenciais de segurança da API não foram implementadas ou foram implementadas incorretamente, deixando lacunas e pontos fracos perigosos na API. Os agentes de ameaças podem explorar essas lacunas para orquestrar ataques maciços e violações de dados.

Essas configurações incorretas podem ocorrer em diferentes níveis da pilha de API, incluindo servidor de API, gateway de API, aplicativo cliente, infraestrutura que suporta a API, nível de rede, nível de sistema, nível de aplicativo e assim por diante. Quase não existe diferença em como essas configurações incorretas afetam aplicativos da web e APIs.

// API insegura Endpointapp.get('/api/user/:id', (req, res) => {const userId = req.params.id;// Busca dados do usuário do banco de dados sem autenticação ou autorizaçãoUser.findById( userId, (err, user) => {if (err) {return res.status(500).json({ error: 'Internal Server Error' });}if (!user) {return res.status(404) .json({ error: 'User not found' });}// Return the user datares.json(user);});});Neste exemplo, o endpoint da API /api/user/:id é projetado para recuperar dados do usuário com base no id fornecido. No entanto, não há verificações de autenticação ou autorização em vigor.

O código busca diretamente o usuário no banco de dados sem verificar a identidade do usuário ou garantir que ele tenha as permissões necessárias.

Um invasor que explora essa configuração incorreta pode simplesmente enviar uma solicitação GET para /api/user/:id com qualquer parâmetro id e recuperar os dados do usuário sem autenticação ou autorização adequada. Isso expõe informações confidenciais do usuário a indivíduos não autorizados.

A configuração incorreta do sistema é uma vulnerabilidade que pode ser explorada, seja em APIs, aplicativos da Web, redes, contêineres ou plataformas de desenvolvimento. Se você deixar as APIs configuradas de forma imprópria, inadequada ou insegura, você deixará a API aberta a uma ampla gama de riscos de segurança.

As vulnerabilidades de configuração incorreta de segurança vêm em todas as formas e tamanhos, com níveis variados de risco. Aqui estão alguns exemplos do que pode levar a essas configurações incorretas.

Confira a lista completa de configurações incorretas de API em nossoLista de verificação de teste de caneta da API.

Aqui estão cinco exemplos de cenários de ataque de configuração incorreta de API e suas possíveis implicações:

A violação do Capital One de 2019 é um exemplo da vida real de exploração de configurações incorretas de segurança por invasores. No caso da Capital One, os invasores descobriram que um WAF de código aberto estava sendo usado para proteger os aplicativos e APIs da empresa. Este WAF não foi devidamente configurado e ajustado adequadamente às necessidades e ao contexto do ambiente AWS da empresa. Como resultado, não seguiu os princípios de confiança zero e privilégio mínimo.

Sendo excessivamente permissivos, os invasores poderiam facilmente ignorar o WAF. Os invasores criaram um script de injeção para direcionar o serviço de metadados da nuvem AWS de back-end. O WAF não pôde inspecionar o conteúdo da mensagem ou filtrá-la e permitiu que a solicitação de injeção fosse processada pelo back-end. Agora, o invasor pode coletar metadados que não deveria ter acessado.