Cada pull request que afegeix o canvia un punt final canvia la superfície d'atac de l'API. La majoria d'eines de seguretat de l'API no ho noten fins que aquest punt final està actiu i ja rep trànsit. Aleshores, la solució ja no és un canvi d'una sola línia en una revisió de codi, sinó una conversa de resposta a incidents.
La seguretat de les API és la pràctica de trobar i tancar els riscos en la manera com una aplicació exposa els seus punts finals: qui els pot cridar, quines dades retornen i si fan el que diu la documentació que fan.
La majoria de les eines creades per a aquest problema proven l'API en temps d'execució, des de l'exterior, de la mateixa manera que ho faria un atacant. Aquest enfocament funciona, però només funciona després que s'hagi implementat l'API. Xígeni pren el camí anterior: llegeix el codi font i l'especificació de l'API abans que una sola sol·licitud arribi al punt final.
Les quatre maneres de provar una API i què respon cadascuna
La majoria de programes madurs executen més d'un d'aquests:
- Prova estàtica analitza el codi font i les especificacions de l'API abans del desplegament. Respon a la pregunta "què acabem d'exposar?". Aquest és l'enfocament en què se centra aquest article.
- Proves dinàmiques (DAST) envia trànsit real a una API en execució i observa com respon. Respon "què és realment accessible i explotable ara mateix?"
- Fuzzing llança entrades mal formades o inesperades als extrems per solucionar errors i errors de casos límit. Respon a "quines interrupcions a l'entrada no preveiem?"
- Proves de penetració manuals afegeix el judici humà per trobar defectes lògics que les eines automatitzades passen per alt. Respon a "què encadenaria un atacant intel·ligent?"
Cap d'aquests substitueix els altres. Responen a preguntes diferents en diferents punts del cicle de vida, i el buit que tenen la majoria de programes és el primer.
Per què la majoria d'eines de seguretat de l'API veuen el risc massa tard
Les proves de seguretat de l'API en temps d'execució envien trànsit a una aplicació en directe i observen com respon. És una capa legítima i necessària. També és, per construcció, un indicador de retard: un punt final ha d'existir, estar desplegat i ser accessible abans que un escàner en temps d'execució pugui dir res al respecte. Tot el que trobi ja estava exposat durant el temps que va trigar a executar-se l'escaneig.
Hi ha una segona bretxa sota aquest problema de temps. Les eines d'execució només poden provar allò que saben que existeix. Si un punt final mai no s'ha documentat o l'especificació d'OpenAPI ha quedat desactualitzada en el moment en què algú ha enviat una nova ruta, un escàner d'execució no té manera de saber que hi és. Prova el mapa, no el territori.
Les proves de seguretat de l'API estàtiques tanquen ambdues mancances movent la comprovació on es defineix el punt final: el vostre codi i l'especificació de l'API, abans del desplegament. El mateix pull request que introdueix un punt final és el pull request que posa de manifest el seu risc.
Què significa realment la seguretat de l'API estàtica
Xygeni crea el vostre inventari d'API a partir de dues fonts: el codi font de la vostra aplicació i les vostres especificacions d'API, incloent-hi OpenAPI i Swagger.
Un inventari només d'especificacions mostra els punts finals que algú s'ha recordat de documentar. Un inventari només de codi mostra què existeix però no necessàriament com es pretén que s'utilitzi. Llegir tots dos us ofereix una imatge completa: els punts finals que els vostres equips van documentar i els que ningú va fer.
Aquest inventari és la base sobre la qual es construeix tot el demés:
- Total d'API descobertes i actius en risc mesurats en relació amb una línia de base
- Punts finals desglossats pel mètode HTTP
- Problemes agrupats per servei
- Cada punt final amb el seu mètode, ruta, servei, mòdul, estat d'autenticació i puntuació de risc
Els vostres responsables d'enginyeria veuen la forma de la superfície de la vostra API sense obrir ni un sol tiquet.
Cada punt final que Xygeni ha trobat, amb el seu mètode, estat d'autenticació i puntuació de risc, construït a partir de codi i especificacions conjuntament.
Production note Retalla el panell AI Triage des de qualsevol captura de pantalla de seguretat de l'API.
Assignat al Top 10 de seguretat de l'API d'OWASP
Les troballes parlen del marc de treball que ja utilitzen els vostres equips de seguretat i els vostres auditors. Xygeni detecta riscos a través de la seguretat de l'API d'OWASP. Els 10 millors (2023):
| OWASP | Risc | Què significa a la pràctica |
|---|---|---|
API1 | Autorització a nivell d'objecte trencat | Un punt final retorna o modifica dades que pertanyen a un altre usuari o inquilí. |
API2 | Punts finals no autenticats | Una ruta és accessible sense cap autenticació |
API3 | Exposició excessiva de dades | Una resposta retorna més camps dels que la persona que truca necessita o hauria de veure |
API3 | Assignació massiva | Un punt final accepta i aplica camps que mai no estava destinat a acceptar. |
API3 / API10 | Dades sensibles a les respostes | La PII, la PCI o la PHI arriben al client des d'un punt final que no l'hauria d'enviar. |
API4 | Límits de taxa que falten | Un punt final no té protecció contra l'abús o les trucades de força bruta. |
API5 | Autorització de nivell de funció trencada | Un punt final realitza una acció privilegiada sense comprovar que la persona que truca té permís per fer-ho. |
API7 | SSRF | L'API pot ser enganyada perquè faci sol·licituds en nom de l'atacant |
API8 | Configuració incorrecta de JWT | La validació, la signatura o el venciment del token estan configurats incorrectament. |
API8 | Configuració incorrecta de CORS | Les regles d'origen creuat són prou permissives per ser explotables |
API9 | Punts finals zombis i orfes | Rutes obsoletes o oblidades que encara són accessibles i rutes que no són propietat de ningú |
Una categoria està deliberadament absent. L'API6, Accés sense restriccions a fluxos empresarials sensibles, requereix entendre què se suposa que ha de permetre un procés empresarial, i cap analitzador estàtic ho detecta de manera creïble. Qualsevol proveïdor que afirmi el contrari us està venent una casella de verificació. Això es queda amb el vostre model d'amenaces i els vostres testers de penetració.
No totes les troballes són iguals: sensibilitat de les dades i combinacions tòxiques
Una llista plana de troballes tracta un punt final de comprovació d'estat no autenticat de la mateixa manera que un punt final no autenticat que retorna registres de clients. No són el mateix problema, i un model de priorització que els puntua de manera idèntica entrena els vostres equips per ignorar la llista.
Xygeni classifica les dades que gestiona cada punt final, marcant PII, PCI i PHI en els paràmetres de sol·licitud i en les respostes, i les emparella amb l'estat d'autenticació del punt final.
També correlaciona les troballes que arriben al mateix punt final i augmenta la gravetat quan es componen. Una filtració d'informació identificable en una resposta és una troballa greu per si sola. La mateixa filtració en un punt final que no requereix autenticació és crítica, i la plataforma la puntua d'aquesta manera en lloc de deixar la connexió perquè algú la noti manualment.
Punts finals zombis i orfes: la deriva entre el codi i l'especificació
Com que Xygeni llegeix el vostre codi i l'especificació de l'API alhora, veu on discrepen. Aquesta desviació es mostra com tres patrons recognoscibles:
- Punts finals no documentats. Viuen en el codi i mai no es van afegir a l'especificació.
- Punts finals de zombis. Estan marcats com a obsolets o retirats, i encara són accessibles.
- Punts finals orfes. Ningú de l'equip actual els posseeix.
Cap d'aquests apareix en un inventari només d'especificacions, perquè l'especificació és exactament el que els falta.
Proves sobre les quals podeu actuar, no una ordre d'investigació
Cada troballa apunta al controlador exacte responsable: el fitxer, la classe, el mètode i la línia específica que va introduir la falla, amb el codi infractor representat al costat. Cadascuna també porta la seva gravetat, la seva categoria OWASP API Security Top 10, el seu CWE, l'estat d'autenticació del punt final i la classificació de sensibilitat de les dades implicades.
Una troballa que només anomena un punt final fa que un desenvolupador busqui per la base de codi abans de poder començar a arreglar res. Una troballa que anomena la línia el posa a la correcció immediatament.
Les troballes s'exporten com a JSON, CSV, Markdown i SARIF 2.1.0, de manera que acaben a la teines amb què ja treballen els vostres equips.
El controlador, la línia i el codi que van introduir l'exposició. No és un tiquet per investigar.
Per què això viu en una plataforma, no en una altra consola
Xygeni executa la seguretat de l'API juntament amb SAST, SCA, Secrets de seguretat, IaC i DAST dins d'una única plataforma, correlacionada a través de ASPM, en comptes d'enviar-lo com una eina separada amb la seva pròpia login i el seu propi endarreriment.
Això és important perquè les troballes estàtiques i les troballes en temps d'execució responen a preguntes diferents sobre el mateix punt final, i són més útils junts que per separat. L'estàtic indica que un punt final és arriscat abans que s'enviï. El DAST confirma què és realment accessible i explotable un cop s'està executant.
Dividiu això entre dues consoles i el risc correlacionat es converteix en dos retards no relacionats. Ningú els reconcilia i el punt final que no està documentat ni autenticat no es troba a cap de les dues cues.
Veure la superfície d'atac real de la API. La seguretat de l'API està disponible com a Enterprise complement a la plataforma Xygeni i s'executa una exploració contra els vostres propis repositoris dins de la vostra pròpia infraestructura.
FAQ
Pot dir quins punts finals gestionen dades sensibles?
Sí. Xygeni marca PII, PCI i PHI en paràmetres i respostes de punt final, i utilitza aquesta classificació per classificar les troballes per exposició real.
Pot funcionar en tots els pull request?
Sí. L'escaneig incremental només analitza els punts finals que han canviat i el manifest que produeix pot centrar un escaneig DAST posterior en aquests mateixos punts finals, de manera que les proves estàtiques i en temps d'execució es mantenen alineades amb el que realment s'ha mogut.
El meu codi surt del meu entorn?
No. Els escanejos s'executen a la vostra pròpia infraestructura. Només es carreguen els resultats, que es protegeixen en trànsit i en repòs.
Com puc obtenir seguretat de l'API?
La seguretat de l'API està disponible com a Enterprise complement. Sol·licita una prova de constància i s'elaborarà conjuntament amb tu.







