Receita para o desastre: Estratégias API-first com Security-last
Há uma demanda crescente por APIs. Seja ajudando a impulsionar a economia digital habilitando aplicativos móveis ou aumentando internamente a produtividade por meio de iniciativas de automação e orquestração, as APIs estão em toda parte.
Muitas organizações adotaram o slogan digital "API em primeiro lugar!" Ou seja, a maioria (60%) dos entrevistados no relatório State of API Integration 2018 da Cloud Elements disponibiliza uma API para qualquer desenvolvedor. Está valendo a pena. Impressionantes 85% das organizações estão gerando pelo menos alguma receita com APIs e implementações relacionadas a APIs. A maior parte (59%) gera entre 11 e 50% da receita de sua organização. Mais de um em cada dez (11%) gera mais da metade de sua receita apenas com APIs. ( Valor crescente das APIs da MuleSoft )
Mas deixe-me lembrá-lo de que eles tornam suas APIs abertas a QUALQUER desenvolvedor. Não qualquer desenvolvedor bem-intencionado, mas qualquer desenvolvedor.
A natureza aberta da economia de APIs hoje é uma das razões pelas quais é lamentável que uma estratégia que prioriza as APIs seja frequentemente acompanhada por uma estratégia que prioriza a segurança.
Uma verdadeira cornucópia de incidentes de segurança relacionados a APIs envolvendo organizações de alto perfil pode ser encontrada com relativa facilidade. Sejam mencionadas pela Forbes ou descobertas pelo nosso próprio F5 Labs , essas organizações sofreram violações de segurança relacionadas a APIs que poderiam ter sido evitadas com práticas e ferramentas de segurança bem compreendidas .
Nosso próprio Ray Pompon - principal evangelista de pesquisa de ameaças do F5 Labs - observou em sua pesquisa sobre segurança de API:
"...você pode ver padrões associados aos mesmos problemas clássicos em segurança de aplicativos que sempre tivemos: invasores obtendo acesso por meio de ataques de força bruta ou credenciais roubadas. Além disso, uma vez autenticados na API, os invasores exploraram as permissões atribuídas excessivamente amplas."
De < https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents >
Os mesmos problemas clássicos. Porque, no final das contas, as APIs são mais frequentemente implementadas como URIs transportados por HTTP, carregando uma carga de dados JSON ou XML. O que não é muito diferente de um URI transportado por HTTP carregando uma carga de dados de formulário POSTados.
E não podemos esquecer que uma API é apenas uma interface para código. Código que, com base nas Estatísticas de Segurança de Aplicativos WhiteHat , tem uma média de 39 vulnerabilidades por 100 mil linhas de código (LOC). Espere, isso é para um aplicativo tradicional. Que tal 180 por 100K LOC se você implementasse a interface (API) usando uma arquitetura de microsserviços. De qualquer forma, são muitas vulnerabilidades.
Uma API carrega consigo as mesmas vulnerabilidades que sua contraparte, o aplicativo web. E isso significa que ela precisa da mesma atenção com relação à segurança que um aplicativo web.
E, no entanto, a importância atribuída à segurança da API não é comparável à dos aplicativos web hoje em dia - pelo menos não com base em evidências existenciais que expõem a abordagem sem brilho aos testes de segurança realizados. Uma pesquisa informal realizada pela SmartBear descobriu que apenas 12% dos entrevistados realizaram testes "extensivos" de segurança de API atualmente. Quase o dobro disso — 23% para ser exato — NÃO REALIZOU NENHUM TESTE DE SEGURANÇA DE API. Isso está de acordo com uma pesquisa mais formal conduzida pela SmartBear , que descobriu que 80% dos entrevistados testam suas APIs.
O que ainda deixa 20% que não o fazem.
API-first é uma ótima maneira de se envolver na economia digital e transformar negócios e operações em máquinas digitais enxutas e eficientes. Mas colocar a segurança em último lugar é uma ótima maneira de transformar isso em uma hashtag amarga e tendência no Twitter*. E ninguém quer isso.
Então, se você vai priorizar a API — e deve fazê-lo —, precisa levar consigo a segurança como um cidadão de primeira classe. Não aceite uma estratégia de segurança em último lugar para suas APIs.
Alguns passos simples para ajudar você a começar:
- Se existir, teste.
- Se houver alguma entrada do usuário, não confie nela.
- Se houver um login de usuário, proteja-o contra ataques de força bruta e de preenchimento de credenciais.
- Esteja ciente da necessidade de manter e corrigir os sistemas e serviços nos quais sua API se baseia. A vulnerabilidade deles é a vulnerabilidade da sua API.
Fique seguro lá fora.