Iga pull request mis lisab või muudab lõpp-punkti, muudab teie API rünnakupinda. Enamik API turvatööriistu ei märka seda enne, kui see lõpp-punkt on aktiivne ja juba liiklust vastu võtab. Selleks ajaks ei ole parandus enam üherealine muudatus koodiülevaates, vaid see on intsidendile reageerimise vestlus.
API turvalisus on praktika, mille käigus leitakse ja kõrvaldatakse riskid, mis kaasnevad rakenduse lõpp-punktide avalikustamisega: kes saab neile helistada, milliseid andmeid nad tagastavad ja kas nad teevad seda, mida dokumentatsioon lubab.
Enamik selle probleemi jaoks loodud tööriistadest testib API-t käitusajal väljastpoolt, samamoodi nagu ründaja. See lähenemisviis toimib, kuid alles pärast API juurutamist. Xygeni valib varasema tee: see loeb teie lähtekoodi ja API spetsifikatsiooni enne, kui üks päring jõuab lõpp-punkti.
Neli viisi API testimiseks ja mida igaüks neist annab
Enamik küpsemaid programme käitab rohkem kui ühte neist:
- Staatiline testimine analüüsib lähtekoodi ja API spetsifikatsioone enne juurutamist. See annab vastuse küsimusele „mida me just avalikustasime?“. See on lähenemisviis, millele see artikkel keskendub.
- Dünaamiline testimine (DAST) saadab töötava API kaudu reaalset liiklust ja jälgib selle reaktsiooni. See vastab küsimusele: „Mis on praegu tegelikult kättesaadav ja ärakasutatav?“.
- Hägune viskab lõpp-punktides vigase või ootamatu sisendi, mis põhjustab pinna krahhe ja servajuhtumite tõrgei. See annab vastuse küsimusele „millised sisendi all esinevad katkestused, mida me ette ei näinud?“.
- Manuaalne penetratsioonitestimine lisab inimliku otsustusvõime, et leida loogikavigasid, mida automatiseeritud tööriistad ei märka. See annab vastuse küsimusele „mida nutikas ründaja kokku aheldaks?”.
Ükski neist ei asenda teisi. Nad vastavad erinevatele küsimustele elutsükli eri etappidel ja enamiku programmide tühimik on just esimene.
Miks enamik API turvatööriistu näeb ohtu liiga hilja
Käitusaja API turvatestimine saadab liikluse reaalajas rakendusele ja jälgib selle reageeringut. See on õigustatud ja vajalik kiht. See on oma ülesehituselt ka mahajäämuse indikaator: enne kui käitusaja skanner saab selle kohta midagi öelda, peab lõpp-punkt olemas olema, olema juurutatud ja kättesaadav. Ükskõik, mida see leiab, oli juba avalikustatud nii kaua, kui skannimine aega võttis.
Selle ajastusprobleemi taga on teinegi lünk. Käitusaja tööriistad saavad testida ainult seda, mille olemasolust nad teavad. Kui lõpp-punkti pole kunagi dokumenteeritud või OpenAPI spetsifikatsioon on uue marsruudi avaldamise hetkel aegunud, pole käitusaja skanneril mingit võimalust teada saada, et see on olemas. See testib kaarti, mitte territooriumi.
Staatiline API turvatestimine täidab mõlemad lüngad, viies kontrolli enne juurutamist sinna, kus lõpp-punkt on määratletud: teie koodi ja API spetsifikatsiooni. Sama pull request mis tutvustab lõpp-punkti, on pull request mis toob esile oma riski.
Mida staatiline API turvalisus tegelikult tähendab
Xygeni loob teie API inventuuri kahest allikast: teie rakenduse lähtekoodist ja teie API spetsifikatsioonidest, sealhulgas OpenAPI-st ja Swaggerist.
Ainult spetsifikatsioonidel põhinev inventuur näitab lõpp-punkte, mida keegi meeles pidas dokumenteerima. Ainult koodil põhinev inventuur näitab, mis on olemas, aga mitte tingimata seda, kuidas seda pidi kasutama. Mõlema lugemine annab sulle tervikpildi: lõpp-punktid, mida sinu meeskonnad dokumenteerisid, ja need, mida keegi ei dokumenteerinud.
See inventuur on alus, millele kõik muu ehitatakse:
- Avastatud API-de koguarv ja riskirühma kuuluvad varad, mida mõõdeti võrreldes algtasemega
- Lõpp-punktid HTTP-meetodi järgi jaotatud
- Probleemid teenuse kaupa rühmitatud
- Iga lõpp-punkt koos oma meetodi, tee, teenuse, mooduli, autentimisoleku ja riskiskooriga
Teie insenerijuhid näevad teie API pinna kuju ilma ühtegi piletit avamata.
Iga Xygeni leitud lõpp-punkt koos meetodi, autentimisoleku ja riskiskooriga loodi koodi ja spetsifikatsiooni koosmõjul.
Production note Kärpige tehisintellekti triaaži paneeli mis tahes API turvalisuse ekraanipildilt.
Kaardistatud OWASP API turvalisuse esikümnesse
Tulemused peegeldavad raamistikku, mida teie turvameeskonnad ja audiitorid juba kasutavad. Xygeni tuvastab riske kogu OWASP API ulatuses. 10 parimat (2023):
| OWASP | Oht | Mida see praktikas tähendab |
|---|---|---|
API1 | Katkine objektitaseme autoriseerimine | Lõpp-punkt tagastab või muudab teisele kasutajale või rentnikule kuuluvaid andmeid. |
API2 | Autentimata lõpp-punktid | Marsruut on ligipääsetav ilma igasuguse autentimiseta |
API3 | Liigne andmetega kokkupuude | Vastus tagastab rohkem välju, kui kutsuja vajab või peaks nägema |
API3 | Massülesanne | Lõpp-punkt aktsepteerib ja rakendab välju, mida see ei pidanudki aktsepteerima |
API3 / API10 | Vastustes olevad tundlikud andmed | PII, PCI või PHI jõuab kliendini lõpp-punktist, mis seda saatma ei peaks |
API4 | Puuduvad kiirusepiirangud | Lõpp-punktil puudub kaitse kuritarvituste või jõhkra jõu kõnede eest |
API5 | Katkise funktsioonitaseme autoriseerimine | Lõpp-punkt sooritab privilegeeritud toimingu kontrollimata, kas helistajal on lubatud |
API7 | SSRF | API-t saab petta ründaja nimel päringuid esitama |
API8 | JWT vale konfiguratsioon | Tokeni valideerimine, allkirjastamine või aegumine on valesti seadistatud. |
API8 | CORS-i vale konfiguratsioon | Ristpäritolu reeglid on piisavalt lubavad, et neid ära kasutada |
API9 | Zombide ja orbude lõpp-punktid | Aegunud või unustatud marsruudid, mis on endiselt kättesaadavad, ja marsruudid, mis ei kuulu kellelegi |
Üks kategooria on teadlikult puudu. API6 ehk piiramatu juurdepääs tundlikele ärivoogudele nõuab mõistmist, mida äriprotsess peaks lubama, ja ükski staatiline analüsaator seda usaldusväärselt ei tuvasta. Iga müüja, kes väidab vastupidist, müüb teile märkeruutu. See jääb teie ohu modelleerimise ja penetratsioonitestijate juurde.
Mitte iga leid pole võrdne: andmete tundlikkus ja toksilised kombinatsioonid
Ühetaoline leidude loend käsitleb autentimata tervisekontrolli lõpp-punkti samamoodi nagu autentimata lõpp-punkti, mis tagastab kliendiandmeid. Need ei ole sama probleem ja prioriseerimismudel, mis neid identselt hindab, õpetab teie meeskondi loendit ignoreerima.
Xygeni klassifitseerib iga lõpp-punkti käideldavaid andmeid, märkides päringuparameetrites ja vastustes PII, PCI ja PHI ning sidub need lõpp-punkti autentimisolekuga.
Samuti korreleerib see samale lõpp-punktile langevaid leide ja suurendab tõsidust, kui need summeeruvad. Vastuses olev isikuandmete leke on iseenesest tõsine leid. Sama leke lõpp-punktis, mis ei vaja autentimist, on kriitiline ja platvorm hindab seda vastavalt, selle asemel, et jätta ühendus kellegi käsitsi märkamiseks.
Zombide ja orbude lõpp-punktid: triiv koodi ja spetsifikatsiooni vahel
Kuna Xygeni loeb teie koodi ja API spetsifikatsiooni kõrvuti, näeb see, kus need erinevad. See triiv ilmneb kolme äratuntava mustrina:
- Dokumenteerimata lõpp-punktid. Need on koodis sees ja neid pole kunagi spetsifikatsiooni lisatud.
- Zombide lõpp-punktid. Need on märgitud aegunuks või pensionile jäänuks, kuid on endiselt kättesaadavad.
- Harvaesinevad lõpp-punktid. Keegi praegusest meeskonnast ei oma neid.
Ainult spetsifikatsioonidele mõeldud inventaris ei kuvata ühtegi neist, sest need puuduvad just spetsifikatsioonidest.
Tõendid, mille põhjal saate tegutseda, mitte uurimise alustamise pilet
Iga leid viitab vastutavale käitlejale: failile, klassile, meetodile ja konkreetsele reale, mis vea põhjustas, koos sellega kaasneva sobimatu koodiga. Iga leid sisaldab ka selle raskusastet, OWASP API turvalisuse top 10 kategooriat, CWE-d, lõpp-punkti autentimisolekut ja kaasatud andmete tundlikkuse klassifikatsiooni.
Leid, mis lihtsalt nimetab lõpp-punkti, paneb arendaja enne millegi parandamisega alustamist koodibaasi läbi kammima. Leid, mis nimetab rea, viib nad kohe paranduse juurde.
Tulemused eksporditakse JSON-, CSV-, Markdown- ja SARIF 2.1.0-vormingus, seega maanduvad need t-sse.tööriistad, millega teie meeskonnad juba töötavad.
Käitleja, rida ja kood, mis paljastasid ohu. Mitte uuritav taotlus.
Miks see elab ühes platvormis, mitte teises konsoolis
Xygeni haldab API turvalisust koos SAST, SCA, Saladused Turvalisus, IaC ja VASTU ühe platvormi sees, omavahel seotud ASPM, selle asemel, et seda eraldi tööriistana tarnida koos oma login ja omaenda mahajäämust.
See on oluline, sest staatilised ja käitusaja leiud vastavad sama lõpp-punkti kohta erinevatele küsimustele ning need on koos kasulikumad kui eraldi. Staatiline annab enne lõpp-punkti saatmist teada, et see on riskantne. DAST kinnitab, mis on pärast töötamist tegelikult kättesaadav ja kasutatav.
Kui see kahe konsooli vahel jagada ja seotud risk jaotatakse, saab kahest omavahel mitteseotud ootejärjekorrast. Keegi ei lepi neid kokku ning dokumenteerimata ja autentimata lõpp-punkt jääb kummassegi järjekorda.
Näe oma tegelikku API rünnakupinda. API turvalisus on saadaval järgmiselt: Enterprise lisandmoodul Xygeni platvormile ja skannimine toimub teie enda infrastruktuuris asuvate repositooriumide vastu.
KKK
Kas see suudab öelda, millised lõpp-punktid tundlikke andmeid töötlevad?
Jah. Xygeni märgistab näitajate parameetrites ja vastustes isiku tuvastamiseks vajaliku teabe (PCI) ja isiku tuvastamiseks vajaliku teabe (PHI) ning kasutab seda klassifikatsiooni leidude järjestamiseks tegeliku kokkupuute alusel.
Kas see saab töötada igal pull request?
Jah. Täiendav skaneerimine analüüsib ainult muutunud lõpp-punkte ja selle loodud manifest saab suunata järgneva DAST-skannimise samadele lõpp-punktidele, nii et staatiline ja käitusaegne testimine jäävad vastavusse sellega, mis tegelikult muutus.
Kas mu kood lahkub minu keskkonnast?
Ei. Skaneeringud toimuvad teie enda infrastruktuuris. Laaditakse üles ainult tulemused, mis on edastamise ja puhkeoleku ajal kaitstud.
Kuidas ma saan API turvalisuse?
API turvalisus on saadaval järgmiselt: Enterprise lisandmoodul. Taotle PoC-d ja see arutatakse sinuga läbi.





