0
0
O uso de interfaces de programação de aplicativos (APIs) explodiu à medida que as empresas implantam aplicativos móveis, contêineres, computação sem servidor, microsserviços e expandem sua presença na nuvem . Consequentemente, muitas APIs são desenvolvidas e implantadas muito rapidamente, levando à persistência de erros de codificação, com práticas de autenticação deficientes que estão entre as principais ofensas.
As APIs são sem estado por natureza, e qualquer lacuna ou fraqueza pode permitir que um invasor obtenha acesso não autorizado a aplicativos ou extraia dados. A autenticação de uma API exige que o desenvolvedor tenha um entendimento completo da transação – desde a interação do usuário até o resultado – portanto, exige que eles ultrapassem os limites da própria especificação da API. O protocolo de autenticação escolhido procurará verificar a identidade do cliente que está tentando se conectar antes que a autorização seja usada para permitir que a conexão com um aplicativo ocorra.
Opções de autenticação
Há várias maneiras de autenticar solicitações de API. Eles variam de HTTPS e um nome de usuário e senha a chaves de API que geram uma string exclusiva de caracteres para cada solicitação de autenticação OAuth , que faz com que os desenvolvedores usem uma estrutura de autorização bem conhecida para orquestrar automaticamente as aprovações. Há também a opção de colocar o OpenID sobre o OAuth para verificar a identidade por meio de um servidor de autorização.
Decidir qual mecanismo de autenticação usar pode ser confuso. Cada um tem os seus prós e contras. HTTPS é simples de usar, mas depende da segurança da combinação de nome de usuário/senha. As chaves fornecem um meio aleatório de acesso, tornando o OAuth a opção mais segura (ou seja, mais difícil de implantar e manter). A decisão sobre qual abordagem adotar será influenciada por vários fatores, como se a API será acessível a desenvolvedores externos ou mantida internamente.
Efeitos de falhas
É uma decisão que deve fazer parte de qualquer estratégia de “deslocamento à esquerda” durante o desenvolvimento da API, que vê a segurança receber total atenção antes que a API seja testada e lançada. Mas muitas vezes é uma área que pode ser negligenciada, e há muitos exemplos que ilustram isso acontecendo.
Por exemplo, a violação de dados do MailChimp no início deste ano viu os invasores usarem chaves de API comprometidas para obter acesso a uma conta através da qual os invasores conseguiram atingir clientes financeiros e criptográficos antes de lançar uma campanha de phishing contra os clientes desses clientes criptográficos.
A autenticação deficiente da API pode, portanto, levar a perdas significativas de dados e ameaçar a integridade da marca. Mas quais são as armadilhas mais comuns quando se trata de autenticação de API?
APIs não autenticadas
Aplicativos legados nem sempre são compatíveis com mecanismos de autenticação. Às vezes, as equipes podem implantar APIs durante a produção por conveniência, com a intenção de lidar com a autenticação em um estágio posterior. Então, talvez um membro da equipe saia ou a equipe simplesmente se esqueça de documentar o trabalho, e isso resulta na implantação de uma API não autenticada.
Quer a API seja implantada interna ou externamente, esse erro cria um risco substancial do qual a equipe pode nem estar ciente até que seja explorada. E, mesmo que seja detectado a tempo, isso levará a alguma interrupção, pois o serviço é desativado e o problema corrigido.
Tokens de autenticação sem valor nulo
As APIs que não verificam os tokens de autenticação (ou se houver um) entram em produção com bastante regularidade. O valor real do token não importa se a presença de um token puder ser confirmada na solicitação, portanto, a API aceitará praticamente qualquer token. Novamente, muitas vezes é uma coisa que a equipe de desenvolvimento pretendia consertar, mas que foi esquecida. Portanto, priorize a atribuição de valores de token.
Autenticado, mas não autorizado
É claro que, mesmo que a API seja autenticada, a autorização ainda precisa ser considerada, mas nem todas as equipes adotam essa atitude. Alguns assumem que a autenticação é suficiente. Mas se a API procurar se conectar a um usuário autenticado, mas não verificar seus privilégios de acesso, esse usuário poderá se conectar a recursos que estão fora de sua competência.
Se o mecanismo de autenticação também for mal construído e for suscetível à enumeração (pelo qual o invasor pode executar facilmente um número finito de possibilidades de login), esse problema também facilita o acesso dos invasores. É um erro que pode levar a um tempo de permanência significativo, pois é difícil de detectar, permitindo que um invasor explore sem contestação. O uso de caracteres gerados aleatoriamente pode mitigar – mas não eliminar – esse tipo de ataque.
Proliferação de tokens
Em grandes organizações com ambientes distribuídos, pode haver várias equipes, cada uma implantando seu próprio tipo de autenticação de API, resultando em uma abordagem fragmentada. Isso cria várias maneiras de acessar uma API, aumentando o risco de comprometimento ao longo do tempo e dificultando o gerenciamento dessas APIs.
Por exemplo, o cliente A pode receber token X-api no cabeçalho da solicitação para se autenticar em um aplicativo. Mas o cliente B pode ser solicitado a fornecer um token de API em um parâmetro de solicitação chamado api-key para autenticação. Um terceiro cliente pode ser solicitado pela chave api no cabeçalho de autorização. Essas várias abordagens aumentam o risco, pois significa que, se qualquer método for comprometido, toda a API se tornará suscetível a ataques. Isso também significa que é improvável que esses métodos de autenticação sejam detectados e corrigidos em atualizações futuras.
A aplicação de uma abordagem consistente usando uma especificação definida como OpenAPI/Swagger e testes antes da implantação usando testes baseados em funcionalidade podem ajudar a evitar que isso ocorra. Também é aconselhável usar o monitoramento de tempo de execução para detectar quaisquer APIs que possam estar usando mais de um mecanismo.
Lógica de autorização imprópria
Se uma API aceitar tokens produzidos em ambientes de privilégios mais baixos, ela concederá acesso a ambientes de privilégios mais altos, como produção. Um agente de ameaça pode obter um token de autenticação da preparação e reproduzi-lo no servidor de produção. Uma implementação de autorização ruim permitiria o acesso, pois o token é tecnicamente válido, embora para o ambiente errado. Isso destaca a necessidade de uma hierarquia de privilégios adequada que pode ser alcançada usando escopos de autenticação, como escopos OAuthou outros mecanismos de imposição de identidade.
Proteja para a direita enquanto muda para a esquerda
À medida que nos tornamos mais dependentes das APIs, devemos saber como evitar esses erros de autenticação.
O que esses problemas ilustram é que as equipes de segurança e desenvolvimento devem trabalhar em conjunto. Embora a adesão a padrões de API respeitados, como a especificação OpenAPI e a implementação de práticas de segurança “shift left” durante o desenvolvimento, possam ajudar a reduzir a probabilidade de ocorrência desses erros de autenticação e autorização, a grande escala de APIs sendo implantadas significa que é improvável que a empresa capture todas as instâncias.
Assim, a autenticação não é apenas um problema de desenvolvimento, mas também um problema que o negócio deve resolver de forma prática e estratégica. Uma estratégia de segurança pós-implantação pode se concentrar na visibilidade contínua do tempo de execução para criar e atualizar um inventário de todas as APIs, avaliar sua exposição ao risco e detectar e bloquear ataques por meio da proteção unificada de API (UAP).
A proteção unificada da API analisa todo o ciclo de vida da API, desde a descoberta até a catalogação, detecção de ataques, mitigação e teste. Dessa forma, garante que as APIs sejam criadas com segurança, mas também monitoradas continuamente e defendidas ativamente. Por isso, facilita uma abordagem Zero Trust, assumindo que mesmo APIs autenticadas e autorizadas são suscetíveis a ataques e monitoram e analisam transações de API e comportamento do usuário. Combine isso com a autenticação que garante que o privilégio mínimo seja aplicado, e qualquer atividade anômala pode ser detectada e o acesso não autorizado impedido.
FONTE: HELPNET SECURITY