API-sikkerhet

API-sikkerhet har vært et runtime-problem. Det trenger det ikke å være.

Hver pull request som legger til eller endrer et endepunkt, endrer API-angrepsflaten din. De fleste API-sikkerhetsverktøy legger ikke merke til det før endepunktet er aktivt og allerede tar trafikk. Da er ikke løsningen lenger en endring på én linje i en kodegjennomgang, det er en hendelsesresponssamtale.

API-sikkerhet er praksisen med å finne og lukke risikoene i hvordan en applikasjon eksponerer endepunktene sine: hvem som kan kalle dem, hvilke data de returnerer, og om de gjør det dokumentasjonen sier de gjør.

Mesteparten av verktøyene som er bygget for dette problemet tester API-et under kjøring, fra utsiden, på samme måte som en angriper ville gjort. Den tilnærmingen fungerer, men den fungerer bare etter at API-et er distribuert. Xygeni tar den tidligere banen: den leser kildekoden din og API-spesifikasjonen din før en enkelt forespørsel i det hele tatt treffer endepunktet.

De fire måtene å teste et API på, og hva hver enkelt svarer på

De fleste modne programmer kjører mer enn én av disse:

  • Statisk testing analyserer kildekode og API-spesifikasjoner før utrulling. Den svarer på «hva avslørte vi nettopp?» Dette er tilnærmingen denne artikkelen fokuserer på.
  • Dynamisk testing (DAST) sender reell trafikk til et kjørende API og observerer hvordan det reagerer. Den svarer på «hva er faktisk tilgjengelig og utnyttbart akkurat nå?» 
  • fuzzing kaster misdannede eller uventede input ved endepunkter til overflatekrasj og kantfeil. Den svarer på «hvilke brudd under input vi ikke forventet?»
  • Manuell penetrasjonstesting legger til menneskelig vurdering for å finne logiske feil som automatiserte verktøy overser. Den svarer på «hva ville en smart angriper kjedet sammen?»

Ingen av disse erstatter de andre. De svarer på forskjellige spørsmål på forskjellige punkter i livssyklusen, og gapet de fleste programmer har er det første.

Hvorfor de fleste API-sikkerhetsverktøy ser risikoen for sent

Sikkerhetstesting av kjøretids-API sender trafikk til en aktiv applikasjon og observerer hvordan den reagerer. Det er et legitimt og nødvendig lag. Det er også, per definition, en forsinkelsesindikator: et endepunkt må eksistere, distribueres og være tilgjengelig før en kjøretidsskanner kan si noe om det. Uansett hva den finner, var det allerede eksponert uansett hvor lang tid det tok å kjøre skanningen.

Det er et annet gap under dette tidsproblemet. Runtime-verktøy kan bare teste det de vet eksisterer. Hvis et endepunkt aldri ble dokumentert, eller OpenAPI-spesifikasjonen ble utdatert i det øyeblikket noen sendte en ny rute, har en runtime-skanner ingen måte å vite at den er der. Den tester kartet, ikke territoriet.

Statisk API-sikkerhetstesting lukker begge hullene ved å flytte sjekken til der endepunktet er definert: koden din og API-spesifikasjonen din, før utrulling. Det samme pull request som introduserer et endepunkt er pull request som avdekker risikoen.

Hva statisk API-sikkerhet egentlig betyr

Xygeni bygger API-inventaret ditt fra to kilder: applikasjonens kildekode og API-spesifikasjonene dine, inkludert OpenAPI og Swagger.

En spesifikasjonsbasert oversikt viser endepunktene noen husket å dokumentere. En kodebasert oversikt viser hva som finnes, men ikke nødvendigvis hvordan det var ment å brukes. Å lese begge deler gir deg det komplette bildet: endepunktene teamene dine dokumenterte, og de ingen gjorde.

Det varelageret er fundamentet alt annet bygger på:

  • Totalt antall oppdagede API-er og risikoutsatte eiendeler målt mot en grunnlinje
  • Endepunkter fordelt etter HTTP-metode
  • Problemer gruppert etter tjeneste
  • Hvert endepunkt med metode, sti, tjeneste, modul, autentiseringsstatus og risikoscore

Ingeniørlederne dine ser formen på API-overflaten din uten å åpne en eneste sak.

Hvert endepunkt Xygeni fant, med metode, autentiseringsstatus og risikoscore, bygget fra kode og spesifikasjon sammen.

Production note Beskjær AI-triage-panelet fra et hvilket som helst API-sikkerhetsskjermbilde.

Kartlagt til OWASP API-sikkerhetstopp 10

Funnene beskriver rammeverket sikkerhetsteamene og revisorene dine allerede bruker. Xygeni oppdager risiko på tvers av OWASP API-sikkerhet. Topp 10 (2023):

OWASP Risiko Hva det betyr i praksis
API1 Autorisasjon på brutt objektnivå Et endepunkt returnerer eller endrer data som tilhører en annen bruker eller leietaker
API2 Uautoriserte endepunkter En rute er tilgjengelig uten noen form for autentisering i det hele tatt
API3 Overdreven dataeksponering Et svar returnerer flere felt enn den som ringer trenger eller burde se
API3 Masseoppdrag Et endepunkt godtar og bruker felt det aldri var ment å godta
API3 / API10 Sensitive data i svar PII, PCI eller PHI når klienten fra et endepunkt som ikke skal sende den
API4 Manglende rategrenser Et endepunkt har ingen beskyttelse mot misbruk eller brute-force-kall
API5 Brudd på funksjonsnivåautorisasjon Et endepunkt utfører en privilegert handling uten å sjekke at innringeren har tillatelse til det
API7 SSRF API-et kan bli lurt til å sende forespørsler på angriperens vegne
API8 JWT-feilkonfigurasjon Validering, signering eller utløp av token er feil konfigurert
API8 Feilkonfigurasjon av CORS Kryssende opprinnelsesregler er tillatte nok til å kunne utnyttes
API9 Zombie- og foreldreløse endepunkter Utdaterte eller glemte ruter som fortsatt er tilgjengelige, og ruter som ingen eier

Én kategori er bevisst fraværende. API6, ubegrenset tilgang til sensitive forretningsflyter, krever forståelse av hva en forretningsprosess skal tillate, og ingen statisk analysator oppdager dette på en troverdig måte. Enhver leverandør som hevder noe annet selger deg en avkrysningsboks. Den kategorien forblir hos trusselmodelleringen og penetrasjonstesterne dine.

Ikke alle funn er like: Datasensitivitet og giftige kombinasjoner

En flat liste over funn behandler et uautorisert endepunkt for helsesjekk på samme måte som et uautorisert endepunkt som returnerer kundeposter. Dette er ikke det samme problemet, og en prioriteringsmodell som gir dem identiske poengsummer, trener teamene dine til å ignorere listen.

Xygeni klassifiserer dataene hvert endepunkt håndterer, flagger PII, PCI og PHI i forespørselsparametere og i svar, og kobler dette med endepunktets autentiseringsstatus.

Den korrelerer også funn som lander på samme endepunkt og øker alvorlighetsgraden når de forsterkes. En PII-lekkasje i et svar er et alvorlig funn i seg selv. Den samme lekkasjen på et endepunkt som ikke krever autentisering er kritisk, og plattformen vurderer den på den måten i stedet for å la noen legge merke til forbindelsen manuelt.

Zombie- og foreldreløse endepunkter: Avviket mellom kode og spesifikasjon

Fordi Xygeni leser koden din og API-spesifikasjonen din side om side, ser den hvor de er uenige. Denne avvikelsen vises som tre gjenkjennelige mønstre:

  • Udokumenterte endepunkter. De lever i koden og ble aldri lagt til i spesifikasjonen.
  • Zombie-endepunkter. De er merket som utdaterte eller pensjonerte, og de er fortsatt tilgjengelige.
  • Foreldreløse endepunkter. Ingen på det nåværende laget eier dem.

Ingen av disse dukker opp i en kun-spesifikasjonsbeholdning, fordi det er akkurat spesifikasjonen som mangler dem.

Bevis du kan handle ut fra, ikke en billett til etterforskning

Hvert funn peker mot den nøyaktige ansvarlige behandleren: filen, klassen, metoden og den spesifikke linjen som introduserte feilen, med den problematiske koden gjengitt ved siden av. Hver av dem har også alvorlighetsgrad, OWASP API Security Top 10-kategori, CWE, endepunktets autentiseringsstatus og sensitivitetsklassifiseringen til de involverte dataene.

Et funn som bare navngir et endepunkt sender en utvikler på jakt gjennom kodebasen før de i det hele tatt kan begynne å fikse noe. Et funn som navngir linjen setter dem umiddelbart på rettingen.

Funnene eksporteres som JSON, CSV, Markdown og SARIF 2.1.0, slik at de havner i tverktøyene teamene dine allerede jobber i. 

Behandleren, linjen og koden som introduserte eksponeringen. Ikke en sak å etterforske.

Hvorfor dette finnes på én plattform, ikke en annen konsoll

Xygeni kjører API-sikkerhet ved siden av SAST, SCA, Hemmeligheter Sikkerhet, IaC og DAST innenfor en enkelt plattform, korrelert gjennom ASPM, i stedet for å sende det som et separat verktøy med sitt eget login og sin egen etterslep.

Det er viktig fordi statiske funn og kjøretidsfunn svarer på forskjellige spørsmål om det samme endepunktet, og de er mer nyttige sammen enn hver for seg. Statisk forteller deg at et endepunkt er risikabelt før det sendes. DAST bekrefter hva som faktisk er tilgjengelig og utnyttbart når det kjører.

Del det på tvers av to konsoller, og korrelert risiko blir to urelaterte etterslep. Ingen avstemmer dem, og endepunktet som både er udokumentert og uautentisert, står ikke i noen av køene.

Se din virkelige API-angrepsflate. API-sikkerhet er tilgjengelig som en Enterprise tillegg til Xygeni-plattformen, og en skanning kjøres mot dine egne databaser i din egen infrastruktur.

FAQ

Kan den fortelle hvilke endepunkter som håndterer sensitive data?

Ja. Xygeni flagger PII, PCI og PHI i endepunktparametere og -responser, og bruker denne klassifiseringen til å rangere funn etter reell eksponering.

Kan den kjøre på alle pull request?

Ja. Inkrementell skanning analyserer bare endepunktene som endret seg, og manifestet den produserer kan fokusere en påfølgende DAST-skanning på de samme endepunktene, slik at statisk og kjøretidstesting forblir justert til det som faktisk endret seg.

Forlater koden min miljøet mitt?

Nei. Skanninger kjører i din egen infrastruktur. Bare resultater lastes opp, beskyttes under overføring og i lagring.

Hvordan får jeg API-sikkerhet?

API-sikkerhet er tilgjengelig som en Enterprise tillegg. Be om en PoC, så vil den bli vurdert sammen med deg.

sca-tools-programvare-verktøy for komposisjonsanalyse
Prioriter, utbedre og sikre programvarerisikoene dine
Få din gratis konto.
Ingen kredittkort kreves.

Sikre programvareutviklingen og -leveringen din

med Xygeni-produktpakken