Joka pull request joka lisää tai muuttaa päätepistettä, muuttaa API-hyökkäyspintaasi. Useimmat API-tietoturvatyökalut eivät huomaa muutosta, ennen kuin päätepiste on käytössä ja ottaa jo vastaan liikennettä. Tällöin korjaus ei ole enää yhden rivin muutos koodikatselmuksessa, vaan se on tapaukseen liittyvä vastauskeskustelu.
API-tietoturva on käytäntö, jolla löydetään ja poistetaan riskit, jotka liittyvät siihen, miten sovellus paljastaa päätepisteensä: kuka voi kutsua niitä, mitä tietoja ne palauttavat ja tekevätkö ne niin kuin dokumentaatiossa sanotaan.
Suurin osa tähän ongelmaan kehitetyistä työkaluista testaa API:a ajonaikaisesti ulkopuolelta samalla tavalla kuin hyökkääjä tekisi. Tämä lähestymistapa toimii, mutta se toimii vasta API:n käyttöönoton jälkeen. Xygeni valitsee aikaisemman polun: se lukee lähdekoodisi ja API-spesifikaatiosi ennen kuin yksikään pyyntö osuu päätepisteeseen.
Neljä tapaa testata API:a ja mitä kukin niistä vastaa
Useimmat aikuisille tarkoitetut ohjelmat suorittavat useamman kuin yhden näistä:
- Staattinen testaus analysoi lähdekoodin ja API-spesifikaatiot ennen käyttöönottoa. Se vastaa kysymykseen "mitä juuri paljastimme?". Tähän lähestymistapaan tämä artikkeli keskittyy.
- Dynaaminen testaus (DAST) lähettää todellista liikennettä käynnissä olevaan API:in ja tarkkailee sen reaktioita. Se vastaa kysymykseen "mikä on tällä hetkellä oikeasti saavutettavissa ja hyödynnettävissä?".
- fuzzing heittää virheellisesti muotoiltua tai odottamatonta syötettä päätepisteisiin, mikä johtaa pintakaatumisiin ja reunatapausten virheisiin. Se vastaa kysymykseen "mitä katkoksia syötteen alla ei odotettu?"
- Manuaalinen penetraatiotestaus lisää ihmisen harkintakykyä löytääkseen logiikkavirheitä, joita automatisoidut työkalut eivät huomaa. Se vastaa kysymykseen ”mitä älykäs hyökkääjä ketjuttaisi yhteen?”
Mikään näistä ei korvaa muita. Ne vastaavat eri kysymyksiin elinkaaren eri vaiheissa, ja useimpien ohjelmien aukko on ensimmäinen.
Miksi useimmat API-tietoturvatyökalut näkevät riskin liian myöhään
Suorituksenaikainen API-tietoturvatestaus lähettää liikennettä reaaliaikaiseen sovellukseen ja tarkkailee sen reaktioita. Se on oikeutettu ja välttämätön taso. Se on myös rakenteeltaan viiveen ilmaisin: päätepisteen on oltava olemassa, otettu käyttöön ja saavutettavissa, ennen kuin ajonaikainen skanneri voi sanoa siitä mitään. Löytö oli jo paljastunut niin kauan kuin skannaus kesti.
Tuon ajoitusongelman alla on toinenkin aukko. Suorituksenaikaiset työkalut voivat testata vain sitä, minkä ne tietävät olevan olemassa. Jos päätepistettä ei ole koskaan dokumentoitu tai OpenAPI-spesifikaatio vanhenee sillä hetkellä, kun joku julkaisee uuden reitin, suorituksenaikaisella skannerilla ei ole mitään keinoa tietää sen olemassaolosta. Se testaa karttaa, ei aluetta.
Staattinen API-tietoturvatestaus paikaa molemmat aukot siirtämällä tarkistuksen siihen, missä päätepiste on määritelty: koodiisi ja API-spesifikaatioosi, ennen käyttöönottoa. Sama pull request joka esittelee päätepisteen, on pull request joka nostaa esiin riskinsä.
Mitä staattinen API-tietoturva oikeastaan tarkoittaa
Xygeni rakentaa API-varastosi kahdesta lähteestä: sovelluksesi lähdekoodista ja API-spesifikaatioistasi, mukaan lukien OpenAPI ja Swagger.
Spesifikaatioon perustuva inventaario näyttää päätepisteet, jotka joku muisti dokumentoida. Koodiin perustuva inventaario näyttää, mitä on olemassa, mutta ei välttämättä sitä, miten sitä oli tarkoitus käyttää. Molempien lukeminen antaa kokonaiskuvan: tiimisi dokumentoimat päätepisteet ja ne, joita kukaan ei dokumentoinut.
Tuo inventaario on perusta, jonka päälle kaikki muu rakentuu:
- Löydettyjen API-rajapintojen kokonaismäärä ja riskialttiiden omaisuuserien määrä verrattuna lähtötasoon
- Päätepisteet HTTP-menetelmän mukaan jaoteltuina
- Ongelmat ryhmiteltynä palvelun mukaan
- Jokainen päätepiste metodineen, polkuineen, palveluineen, moduulineen, todennustiloineen ja riskipisteineen
Suunnittelupäällikösi näkevät API-pintasi muodon avaamatta yhtäkään tikettiä.
Jokainen Xygenin löytämä päätepiste, menetelmäineen, todennustiloineen ja riskipisteineen, rakennettiin koodista ja spesifikaatiosta yhdessä.
Production note Rajaa tekoälyn triage-paneeli mistä tahansa API-tietoturvan kuvakaappauksesta.
Yhdistetty OWASP API:n tietoturvan kymmenen parhaan joukkoon
Löydökset kuvaavat sitä viitekehystä, jota tietoturvatiimisi ja auditoijasi jo käyttävät. Xygeni havaitsee riskit OWASP-rajapinnan kautta. Neljä parasta (2023):
Yksi kategoria on tarkoituksella poissa. API6 eli rajoittamaton pääsy arkaluonteisiin liiketoimintavirtoihin edellyttää ymmärrystä siitä, mitä liiketoimintaprosessin on tarkoitus sallia, eikä mikään staattinen analysaattori tunnista sitä uskottavasti. Jokainen muuta väittävä toimittaja myy sinulle valintaruudun. Se pysyy uhkamallinnuksessasi ja penetraatiotestaajissasi.
Kaikki löydökset eivät ole samanarvoisia: datan herkkyys ja myrkylliset yhdistelmät
Tasainen löydösluettelo käsittelee todentamatonta terveystarkastuspäätepistettä samalla tavalla kuin todentamatonta päätepistettä, joka palauttaa asiakastietoja. Nämä eivät ole sama ongelma, ja priorisointimalli, joka pisteyttää ne identtisesti, kouluttaa tiimisi jättämään listan huomiotta.
Xygeni luokittelee kunkin päätepisteen käsittelemän datan merkitsemällä PII-, PCI- ja PHI-tiedot pyyntöparametreissa ja vastauksissa ja yhdistää ne päätepisteen todennustilaan.
Se myös korreloi samaan päätepisteeseen osuvat löydökset ja nostaa vakavuusastetta, kun ne kasautuvat. Henkilökohtaisesti tunnistettujen tietojen vuoto vastauksessa on itsessään vakava löydös. Sama vuoto päätepisteessä, joka ei vaadi todennusta, on kriittinen, ja alusta pisteyttää sen tällä tavalla sen sijaan, että yhteys jätettäisiin jonkun manuaalisesti huomattaviksi.
Zombien ja orpojen päätepisteiden välinen ajautuminen: Koodin ja speksien välinen ajautuminen
Koska Xygeni lukee koodiasi ja API-spesifikaatiotasi rinnakkain, se näkee, missä ne eroavat toisistaan. Tämä poikkeama näkyy kolmena tunnistettavana mallina:
- Dokumentoimattomat päätepisteet. Ne ovat koodissa, eikä niitä koskaan lisätty spesifikaatioon.
- Zombien päätepisteet. Ne on merkitty vanhentuneiksi tai poistetuiksi, mutta ne ovat edelleen tavoitettavissa.
- Orpopäätepisteet. Kukaan nykyisessä joukkueessa ei omista heitä.
Mikään näistä ei näy pelkän erikoisosaamisen varastossa, koska juuri erikoisosaamisesta ne puuttuvat.
Todisteet, joiden perusteella voit toimia, eivät pääsylippu tutkintaan
Jokainen löydös viittaa tarkkaan käsittelijään, joka on vastuussa virheestä: tiedostoon, luokkaan, metodiin ja tiettyyn riviin, joka toi virheen mukanaan, sekä sen vieressä renderöityyn haitalliseen koodiin. Jokaisella löydöksellä on myös vakavuusaste, OWASP API Security Top 10 -kategoria, CWE-arvo, päätepisteen todennustila ja kyseessä olevien tietojen herkkyysluokitus.
Löydös, joka vain nimeää päätepisteen, pakottaa kehittäjän metsästämään koodikantaa läpi ennen kuin he ehtivät edes alkaa korjata mitään. Löydös, joka nimeää rivin, vie heidät korjauksen äärelle välittömästi.
Löydökset viedään JSON-, CSV-, Markdown- ja SARIF 2.1.0 -tiedostoina, joten ne päätyvät t-valikkoon.työkalut, joissa tiimisi jo työskentelevät.
Käsittelijä, rivi ja koodi, jotka aiheuttivat altistumisen. Ei tutkittavaa tikettiä.
Miksi tämä sijaitsee yhdellä alustalla, ei toisella konsolilla
Xygeni ylläpitää API Securityä rinnakkain SAST, SCA, Salaisuudet Turvallisuus, IaC ja DAST yhden alustan sisällä, korreloituna ASPMsen sijaan, että se toimitettaisiin erillisenä työkaluna omalla login ja oma ruuhkansa.
Tällä on merkitystä, koska staattiset löydökset ja ajonaikaiset löydökset vastaavat eri kysymyksiin samasta päätepisteestä, ja ne ovat hyödyllisempiä yhdessä kuin erikseen. Staattinen kertoo päätepisteen riskialttiudesta ennen sen lähettämistä. DAST vahvistaa, mikä on todella saavutettavissa ja hyödynnettävissä, kun se on käynnissä.
Jos se jaetaan kahdelle konsolille ja korreloivasta riskistä tulee kaksi toisiinsa liittymätöntä jonoa. Kukaan ei täsmää niitä, ja sekä dokumentoimaton että todentamaton päätepiste ei ole kummassakaan jonossa.
Näe todellinen API-hyökkäyspintasi. API-suojaus on saatavilla seuraavasti: Enterprise lisäosa Xygeni-alustalle, ja skannaus suoritetaan omia tietovarastojasi vastaan omassa infrastruktuurissasi.
FAQ
Voiko se kertoa, mitkä päätepisteet käsittelevät arkaluonteisia tietoja?
Kyllä. Xygeni merkitsee PII:n, PCI:n ja PHI:n päätetapaparametreissa ja vastauksissa ja käyttää tätä luokitusta löydösten luokittelemiseen todellisen altistuksen mukaan.
Voiko se toimia jokaisella pull request?
Kyllä. Inkrementaalinen skannaus analysoi vain muuttuneet päätepisteet, ja sen tuottama manifesti voi keskittää seuraavan DAST-skannauksen samoihin päätepisteisiin, joten staattinen ja ajonaikainen testaus pysyvät linjassa sen kanssa, mikä todellisuudessa muuttui.
Poistuuko koodini ympäristöstäni?
Ei. Skannaukset suoritetaan omassa infrastruktuurissasi. Vain tulokset ladataan palvelimelle ja suojataan siirron aikana ja säilytystilassa.
Miten saan API-suojauksen?
API-suojaus on saatavilla seuraavasti: Enterprise lisäosa. Pyydä PoC:tä, niin se tarkastetaan kanssasi.
