cada pull request que engade ou modifica un punto final cambia a superficie de ataque da API. A maioría das ferramentas de seguridade da API non o notan ata que ese punto final está activo e xa recibe tráfico. Para entón, a corrección xa non é un cambio dunha soa liña nunha revisión de código, senón unha conversa de resposta a incidentes.
A seguridade das API é a práctica de atopar e pechar os riscos na forma en que unha aplicación expón os seus puntos finais: quen pode chamalos, que datos devolven e se fan o que di a documentación que fan.
A maior parte das ferramentas creadas para este problema proban a API en tempo de execución, desde fóra, do mesmo xeito que o faría un atacante. Esa estratexia funciona, pero só funciona despois de que se despregue a API. Xíxeno toma o camiño anterior: le o teu código fonte e a túa especificación da API antes de que unha soa solicitude chegue ao punto final.
As catro maneiras de probar unha API e o que responde cada unha delas
A maioría dos programas maduros executan máis dun destes:
- Proba estática analiza o código fonte e as especificacións da API antes da súa implementación. Responde á pregunta "que acabamos de expoñer?". Este é o enfoque no que se centra este artigo.
- Probas dinámicas (DAST) envía tráfico real a unha API en execución e observa como responde. Responde "que é realmente alcanzable e explotable agora mesmo?"
- Fuzzing lanza entradas incorrectas ou inesperadas nos extremos para detectar fallos superficiais e fallos en casos límite. Responde a "que interrupcións na entrada non anticipamos?"
- Probas de penetración manuais engade o xuízo humano para atopar fallos lóxicos que as ferramentas automatizadas pasan por alto. Responde a "que encadearía un atacante intelixente?"
Ningún destes substitúe os demais. Responden a diferentes preguntas en diferentes puntos do ciclo de vida, e a lagoa que teñen a maioría dos programas é a primeira.
Por que a maioría das ferramentas de seguridade das API ven o risco demasiado tarde
As probas de seguranza da API en tempo de execución envían o tráfico a unha aplicación en directo e observan como responde. É unha capa lexítima e necesaria. Tamén é, por construción, un indicador de atraso: un punto final ten que existir, estar despregado e ser accesible antes de que un escáner en tempo de execución poida dicir algo ao respecto. Todo o que atope xa estivo exposto durante o tempo que tardou en executarse a análise.
Hai unha segunda lagoa debaixo dese problema de tempo. As ferramentas de tempo de execución só poden probar o que saben que existe. Se un punto final nunca foi documentado ou a especificación de OpenAPI quedou desactualizada no momento en que alguén enviou unha nova ruta, un escáner de tempo de execución non ten forma de saber que está aí. Proba o mapa, non o territorio.
As probas de seguranza da API estática pechan ambas as dúas lagoas movendo a comprobación a onde se define o punto final: o teu código e a túa especificación da API, antes da implementación. O mesmo pull request que introduce un punto final é o pull request que amosa o seu risco.
Que significa realmente a seguridade da API estática
Xygeni constrúe o teu inventario de API a partir de dúas fontes: o código fonte da túa aplicación e as especificacións da túa API, incluíndo OpenAPI e Swagger.
Un inventario só de especificacións mostra os puntos finais que alguén se lembrou de documentar. Un inventario só de código mostra o que existe pero non necesariamente como se pretendía que se usase. Ler ambos ofréceche unha imaxe completa: os puntos finais que os teus equipos documentaron e os que ninguén fixo.
Ese inventario é a base sobre a que se constrúe todo o demais:
- Total de API descubertas e activos en risco medidos en relación cunha liña base
- Puntos finais desglosados polo método HTTP
- Problemas agrupados por servizo
- Cada punto final co seu método, ruta, servizo, módulo, estado de autenticación e puntuación de risco
Os teus líderes de enxeñaría ven a forma da superficie da túa API sen abrir nin un só ticket.
Todos os puntos finais que atopou Xygeni, co seu método, estado de autenticación e puntuación de risco, foron construídos a partir de código e especificación.
Production note Recortar o panel Triaxe de IA desde calquera captura de pantalla de seguridade da API.
Mapeado ao Top 10 de seguridade da API de OWASP
Os achados falan do marco que xa empregan os seus equipos de seguridade e os seus auditores. Xygeni detecta riscos na seguridade da API de OWASP. Os 10 mellores (2023):
Unha categoría está ausente deliberadamente. A API6, Acceso sen restricións a fluxos empresariais sensibles, require comprender o que se supón que debe permitir un proceso empresarial, e ningún analizador estático detecta iso de forma crible. Calquera provedor que afirme o contrario está a venderche unha caixa de verificación. Esa queda co teu modelo de ameazas e os teus probadores de penetración.
Non todos os achados son iguais: sensibilidade dos datos e combinacións tóxicas
Unha lista plana de achados trata un punto final de comprobación de estado non autenticado do mesmo xeito que un punto final non autenticado que devolve rexistros de clientes. Non son o mesmo problema, e un modelo de priorización que os puntúa de xeito idéntico adestra os teus equipos para ignorar a lista.
Xygeni clasifica os datos que manexa cada punto final, sinalando PII, PCI e PHI nos parámetros de solicitude e nas respostas, e emparella iso co estado de autenticación do punto final.
Tamén correlaciona os achados que chegan ao mesmo punto final e aumenta a gravidade cando se agravan. Unha filtración de información persoal identificable nunha resposta é un achado grave por si mesma. A mesma filtración nun punto final que non require autenticación é fundamental e a plataforma puntúaa dese xeito en lugar de deixar a conexión para que alguén a note manualmente.
Puntos finais zombis e orfos: a deriva entre o código e a especificación
Dado que Xygeni le o teu código e a túa especificación da API xuntos, detecta onde discrepan. Esa desviación aparece como tres patróns recoñecibles:
- Puntos finais non documentados. Viven no código e nunca se engadiron á especificación.
- Puntos finais zombis. Están marcados como obsoletos ou retirados e aínda son accesibles.
- Puntos finais orfos. Ninguén no equipo actual os posúe.
Ningún destes aparece nun inventario só de especificacións, porque a especificación é exactamente o que lles falta.
Probas sobre as que podes actuar, non unha solicitude para investigar
Cada achado apunta ao xestor exacto responsable: o ficheiro, a clase, o método e a liña específica que introduciu o fallo, co código infractor renderizado ao seu carón. Cada un tamén leva a súa gravidade, a súa categoría OWASP API Security Top 10, o seu CWE, o estado de autenticación do punto final e a clasificación de sensibilidade dos datos implicados.
Un achado que só nomea un punto final fai que un desenvolvedor percorra a base de código antes mesmo de poder comezar a arranxar nada. Un achado que nomea a liña lévao á solución inmediatamente.
Os resultados expórtanse como JSON, CSV, Markdown e SARIF 2.1.0, polo que chegan ao tferramentas coas que xa traballan os teus equipos.
O controlador, a liña e o código que introduciron a exposición. Non é un ticket para investigar.
Por que isto vive nunha plataforma, non noutra consola
Xygeni executa a seguridade da API xunto con SAST, SCA, Seguridade Secreta, IaC DAST dentro dunha única plataforma, correlacionada a través de ASPM, en vez de envialo como unha ferramenta separada coa súa propia login e o seu propio atraso.
Iso é importante porque os resultados estáticos e os resultados en tempo de execución responden a preguntas diferentes sobre o mesmo punto final e son máis útiles xuntos que por separado. Os resultados estáticos indican que un punto final é arriscado antes de que se envíe. Os resultados DAST confirman o que é realmente alcanzable e explotable unha vez que se está a executar.
Dividido iso en dúas consolas, o risco correlacionado convértese en dous atrasos non relacionados. Ninguén os reconcilia e o punto final que non está documentado nin autenticado non se atopa en ningunha das dúas colas.
Consulta a túa superficie de ataque API real. A seguridade da API está dispoñible como Enterprise complemento para a plataforma Xygeni e execútase unha análise nos teus propios repositorios dentro da túa propia infraestrutura.
FAQ
Pode dicir que puntos finais xestionan datos confidenciais?
Si. Xygeni sinala PII, PCI e PHI nos parámetros e respostas dos puntos finais e usa esa clasificación para clasificar os achados por exposición real.
Pode funcionar en todos os pull request?
Si. A análise incremental só analiza os extremos que cambiaron e o manifesto que produce pode centrar unha análise DAST posterior neses mesmos extremos, de xeito que as probas estáticas e en tempo de execución se manteñan aliñadas co que realmente se moveu.
O meu código sae do meu entorno?
Non. As análises execútanse na túa propia infraestrutura. Só se cargan os resultados, que se protexen en tránsito e en repouso.
Como consigo a seguridade da API?
A seguridade da API está dispoñible como Enterprise complemento. Solicita unha proba de conformidade e o alcance será elaborado contigo.
