Elke pull request wat 'n eindpunt byvoeg of verander, verander jou API-aanvaloppervlak. Die meeste API-sekuriteitsinstrumente merk dit nie op totdat daardie eindpunt aktief is en reeds verkeer ontvang nie. Teen daardie tyd is die oplossing nie meer 'n eenreëlverandering in 'n kodehersiening nie, maar 'n insidentresponsgesprek.
API-sekuriteit is die praktyk om die risiko's te vind en te sluit in hoe 'n toepassing sy eindpunte blootstel: wie hulle kan aanroep, watter data hulle terugstuur, en of hulle doen wat die dokumentasie sê hulle doen.
Die meeste van die gereedskap wat vir hierdie probleem gebou is, toets die API tydens looptyd, van buite af, op dieselfde manier as wat 'n aanvaller sou doen. Daardie benadering werk, maar dit werk eers nadat die API ontplooi is. Xygeni neem die vorige pad: dit lees jou bronkode en jou API-spesifikasie voordat 'n enkele versoek ooit die eindpunt bereik.
Die vier maniere om 'n API te toets, en wat elkeen beantwoord
Die meeste volwasse programme bied meer as een van hierdie aan:
- Statiese toetsing ontleed bronkode en API-spesifikasies voor ontplooiing. Dit beantwoord "wat het ons sopas blootgestel?" Dit is die benadering waarop hierdie artikel fokus.
- Dinamiese toetsing (DAST) stuur werklike verkeer na 'n lopende API en neem waar hoe dit reageer. Dit beantwoord "wat is eintlik tans bereikbaar en benutbaar?"
- Fuzzing gooi misvormde of onverwagte invoer by eindpunte na oppervlakineenstortings en randgeval-mislukkings. Dit beantwoord "watter breek onder invoer wat ons nie verwag het nie?"
- Handmatige penetrasietoetsing voeg menslike oordeel by om logiese foute te vind wat outomatiese gereedskap mis. Dit beantwoord "wat sou 'n slim aanvaller aanmekaar heg?"
Nie een van hierdie vervang die ander nie. Hulle beantwoord verskillende vrae op verskillende punte in die lewensiklus, en die gaping wat die meeste programme het, is die eerste een.
Waarom die meeste API-sekuriteitsinstrumente die risiko te laat sien
Looptyd-API-sekuriteitstoetsing stuur verkeer na 'n lewendige toepassing en kyk hoe dit reageer. Dit is 'n wettige en noodsaaklike laag. Dit is ook, per konstruksie, 'n agterstandsaanwyser: 'n eindpunt moet bestaan, ontplooi word en bereikbaar wees voordat 'n looptyd-skandeerder enigiets daaroor kan sê. Wat dit ook al vind, was reeds blootgestel vir hoe lank dit die skandering ook al geneem het om te loop.
Daar is 'n tweede gaping onder daardie tydsberekeningsprobleem. Looptyd-gereedskap kan slegs toets wat hulle weet bestaan. As 'n eindpunt nooit gedokumenteer is nie, of die OpenAPI-spesifikasie verouderd geraak het die oomblik toe iemand 'n nuwe roete gestuur het, het 'n looptyd-skandeerder geen manier om te weet dat dit daar is nie. Dit toets die kaart, nie die gebied nie.
Statiese API-sekuriteitstoetsing sluit beide gapings deur die kontrole te skuif na waar die eindpunt gedefinieer is: jou kode en jou API-spesifikasie, voor ontplooiing. Dieselfde pull request wat 'n eindpunt bekendstel, is die pull request wat sy risiko na vore bring.
Wat statiese API-sekuriteit eintlik beteken
Xygeni bou jou API-inventaris uit twee bronne: jou toepassing se bronkode en jou API-spesifikasies, insluitend OpenAPI en Swagger.
’n Spesifikasie-inventaris wys die eindpunte wat iemand onthou het om te dokumenteer. ’n Kode-inventaris wys wat bestaan, maar nie noodwendig hoe dit bedoel was om gebruik te word nie. Deur beide te lees, kry jy die volledige prentjie: die eindpunte wat jou spanne gedokumenteer het, en die wat niemand gedoen het nie.
Daardie voorraad is die fondament waarop alles anders bou:
- Totale API's wat ontdek is, en bates in gevaar gemeet teen 'n basislyn
- Eindpunte afgebreek volgens HTTP-metode
- Probleme gegroepeer volgens diens
- Elke eindpunt met sy metode, pad, diens, module, verifikasiestatus en risikotelling
Jou ingenieursleiers sien die vorm van jou API-oppervlak sonder om 'n enkele kaartjie oop te maak.
Elke eindpunt wat Xygeni gevind het, met sy metode, verifikasiestatus en risikotelling, gebou uit kode en spesifikasie saam.
Production note Sny die KI-triagepaneel vanaf enige API-sekuriteitskermkiekie.
Gekarteer na die OWASP API Sekuriteit Top 10
Bevindinge spreek die raamwerk wat jou sekuriteitspanne en jou ouditeure reeds gebruik. Xygeni bespeur risiko oor die OWASP API-sekuriteit. Top 10 (2023):
Een kategorie is doelbewus afwesig. API6, Onbeperkte Toegang tot Sensitiewe Besigheidsvloei, vereis begrip van wat 'n besigheidsproses veronderstel is om toe te laat, en geen statiese ontleder bespeur dit geloofwaardig nie. Enige verskaffer wat anders beweer, verkoop jou 'n blokkie. Daardie een bly by jou bedreigingsmodellering en jou penetrasietoetsers.
Nie elke bevinding is gelyk nie: Datasensitiwiteit en toksiese kombinasies
'n Plat lys van bevindinge behandel 'n ongeverifieerde gesondheidstoets-eindpunt dieselfde as 'n ongeverifieerde eindpunt wat kliëntrekords terugstuur. Dit is nie dieselfde probleem nie, en 'n prioritiseringsmodel wat hulle identies punte gee, lei jou spanne op om die lys te ignoreer.
Xygeni klassifiseer die data wat elke eindpunt hanteer, merk PII, PCI en PHI in versoekparameters en in reaksies, en koppel dit met die eindpunt se verifikasiestatus.
Dit korreleer ook bevindinge wat op dieselfde eindpunt land en verhoog die erns wanneer hulle saamgestel word. 'n PII-lek in 'n reaksie is op sigself 'n ernstige bevinding. Dieselfde lek op 'n eindpunt wat geen verifikasie vereis nie, is krities, en die platform gradeer dit so in plaas daarvan om die verbinding vir iemand handmatig te laat raaksien.
Zombie- en wees-eindpunte: Die drywing tussen kode en spesifikasie
Omdat Xygeni jou kode en jou API-spesifikasie langs mekaar lees, sien dit waar hulle verskil. Daardie afwyking verskyn as drie herkenbare patrone:
- Ongedokumenteerde eindpunte. Hulle leef in kode en is nooit by die spesifikasie gevoeg nie.
- Zombie-eindpunte. Hulle is gemerk as afgekeur of afgetree, en hulle is steeds bereikbaar.
- Weeslike eindpunte. Niemand in die huidige span besit hulle nie.
Nie een hiervan verskyn in 'n spesifikasie-enigste inventaris nie, want die spesifikasie is presies wat hulle ontbreek.
Bewyse waarop jy kan optree, nie 'n kaartjie om te ondersoek nie
Elke bevinding dui op die presiese hanteerder wat verantwoordelik is: die lêer, die klas, die metode en die spesifieke lyn wat die fout veroorsaak het, met die aanstootlike kode wat daarmee saam weergegee word. Elkeen dra ook sy erns, sy OWASP API Security Top 10-kategorie, sy CWE, die eindpunt se verifikasiestatus en die sensitiwiteitsklassifikasie van die betrokke data.
'n Bevinding wat net 'n eindpunt benoem, stuur 'n ontwikkelaar deur die kodebasis voordat hulle selfs enigiets kan begin regstel. 'n Bevinding wat die lyn benoem, plaas hulle onmiddellik by die regstelling.
Bevindinge word uitgevoer as JSON, CSV, Markdown en SARIF 2.1.0, sodat hulle in die t beland.Oeke waarin jou spanne reeds werk.
Die hanteerder, die lyn en die kode wat die blootstelling veroorsaak het. Nie 'n kaartjie om te ondersoek nie.
Waarom dit in een platform leef, nie in 'n ander konsole nie
Xygeni bestuur API-sekuriteit saam met SAST, SCA, Geheime Sekuriteit, IaC en Dast binne 'n enkele platform, gekorreleer deur ASPM, in plaas daarvan om dit as 'n aparte instrument met sy eie te verskeep login en sy eie agterstand.
Dit maak saak, want statiese bevindinge en looptydbevindinge beantwoord verskillende vrae oor dieselfde eindpunt, en hulle is nuttiger saam as afsonderlik. Statiese seine sê vir jou dat 'n eindpunt riskant is voordat dit gestuur word. DAST bevestig wat eintlik bereikbaar en benutbaar is sodra dit loop.
Verdeel dit oor twee konsoles en gekorreleerde risiko word twee onverwante agterstande. Niemand versoen hulle nie, en die eindpunt wat beide ongedokumenteerd en ongeverifieerd is, sit in geen van die toue nie.
Sien jou werklike API-aanvaloppervlak. API-sekuriteit is beskikbaar as 'n Enterprise byvoeging tot die Xygeni-platform, en 'n skandering loop teen jou eie bewaarplekke binne jou eie infrastruktuur.
FAQ
Kan dit sê watter eindpunte sensitiewe data hanteer?
Ja. Xygeni merk PII, PCI en PHI in eindpuntparameters en -response, en gebruik daardie klassifikasie om bevindinge volgens werklike blootstelling te rangskik.
Kan dit op elkeen loop pull request?
Ja. Inkrementele skandering analiseer slegs die eindpunte wat verander het, en die manifest wat dit produseer, kan 'n daaropvolgende DAST-skandering op dieselfde eindpunte fokus, sodat statiese en looptydtoetsing in lyn bly met wat werklik beweeg het.
Verlaat my kode my omgewing?
Nee. Skanderings loop in jou eie infrastruktuur. Slegs resultate word opgelaai, beskerm tydens vervoer en in rus.
Hoe kry ek API-sekuriteit?
API-sekuriteit is beskikbaar as 'n Enterprise byvoeging. Versoek 'n PoC en dit sal saam met jou ondersoek word.
