Fiecare pull request Adăugarea sau modificarea unui endpoint modifică suprafața de atac a API-ului. Majoritatea instrumentelor de securitate API nu observă acest lucru până când endpoint-ul respectiv nu este activ și preia deja trafic. Până atunci, remedierea nu mai este o modificare de o singură linie într-o revizuire a codului, ci o conversație de răspuns la incident.
Securitatea API este practica de a identifica și închide riscurile legate de modul în care o aplicație își expune endpoint-urile: cine le poate apela, ce date returnează și dacă fac ceea ce se specifică în documentație.
Majoritatea instrumentelor create pentru această problemă testează API-ul în timpul execuției, din exterior, în același mod în care ar face-o un atacator. Această abordare funcționează, dar funcționează numai după ce API-ul este implementat. Xygeni adoptă calea anterioară: citește codul sursă și specificația API-ului înainte ca o singură solicitare să ajungă la endpoint.
Cele patru modalități de a testa o API și ce răspunde fiecare dintre ele
Majoritatea programelor mature rulează mai mult de unul dintre următoarele:
- Testarea statică analizează codul sursă și specificațiile API înainte de implementare. Răspunde la întrebarea „ce tocmai am expus?”. Aceasta este abordarea pe care se concentrează acest articol.
- Testare dinamică (DAST) trimite trafic real către o API care rulează și observă cum răspunde. Răspunde la întrebarea „ce este de fapt accesibil și exploatabil în acest moment?”
- fuzzing lansează intrări incorecte sau neașteptate la punctele finale pentru a supraviețui erorilor și erorilor din cazurile limită. Răspunde la întrebarea „ce întreruperi ale intrărilor nu am anticipat?”
- Testarea manuală a penetrării adaugă judecata umană pentru a găsi defecte logice pe care instrumentele automate le ratează. Răspunde la întrebarea „ce ar lega împreună un atacator inteligent?”
Niciuna dintre acestea nu le înlocuiește pe celelalte. Ele răspund la întrebări diferite în diferite etape ale ciclului de viață, iar lacuna pe care o au majoritatea programelor este prima.
De ce majoritatea instrumentelor de securitate API văd riscul prea târziu
Testarea securității API-ului în timpul rulării trimite trafic către o aplicație activă și urmărește cum aceasta răspunde. Este un strat legitim și necesar. De asemenea, prin construcție, este un indicator de întârziere: un endpoint trebuie să existe, să fie implementat și să fie accesibil înainte ca un scaner în timpul rulării să poată spune ceva despre el. Orice găsește a fost deja expus pentru durata de timp necesară rulării scanării.
Există o a doua lacună în spatele acestei probleme de sincronizare. Instrumentele de execuție pot testa doar ceea ce știu că există. Dacă un punct final nu a fost niciodată documentat sau specificația OpenAPI a devenit depășită în momentul în care cineva a lansat o nouă rută, un scaner de execuție nu are cum să știe că există. Testează harta, nu teritoriul.
Testarea statică a securității API acoperă ambele lacune prin mutarea verificării acolo unde este definit endpoint-ul: codul și specificația API-ului, înainte de implementare. Același lucru pull request care introduce un punct final este pull request care își scoate la iveală riscul.
Ce înseamnă de fapt securitatea API statică
Xygeni îți construiește inventarul API din două surse: codul sursă al aplicației tale și specificațiile API, inclusiv OpenAPI și Swagger.
Un inventar care conține doar specificații arată endpoint-urile pe care cineva și-a amintit să le documenteze. Un inventar care conține doar cod arată ce există, dar nu neapărat cum a fost destinat să fie utilizat. Citind ambele informații, obțineți o imagine completă: endpoint-urile documentate de echipele dvs. și cele pe care nimeni nu le-a documentat.
Acel inventar este fundamentul pe care se construiesc toate celelalte:
- Total API-uri descoperite și active expuse riscului măsurate în raport cu o valoare de referință
- Puncte finale defalcate după metoda HTTP
- Probleme grupate după serviciu
- Fiecare punct final cu metoda, calea, serviciul, modulul, starea de autentificare și scorul de risc al acestuia
Liderii tăi de inginerie văd forma suprafeței API-ului tău fără a deschide niciun tichet.
Fiecare endpoint găsit de Xygeni, împreună cu metoda, starea de autentificare și scorul de risc, a fost construit din cod și specificații.
Production note Decupați panoul AI Triage din orice captură de ecran cu securitatea API.
Mapat la Top 10 în materie de securitate API OWASP
Constatările reflectă cadrul pe care echipele dvs. de securitate și auditorii dvs. îl utilizează deja. Xygeni detectează riscurile în cadrul securității API-ului OWASP. Top 10 (2023):
O categorie lipsește în mod deliberat. API6, Acces nerestricționat la fluxuri de business sensibile, necesită înțelegerea a ceea ce ar trebui să permită un proces de business, iar niciun analizor static nu detectează acest lucru în mod credibil. Orice furnizor care susține contrariul vă vinde o casetă de selectare. Aceasta rămâne la modelarea amenințărilor și la testerii de penetrare.
Nu fiecare constatare este egală: Sensibilitatea datelor și combinațiile toxice
O listă plată de constatări tratează un endpoint de verificare a stării de funcționare neautentificat la fel ca un endpoint neautentificat care returnează înregistrări de clienți. Acestea nu reprezintă aceeași problemă, iar un model de prioritizare care le acordă un scor identic antrenează echipele să ignore lista.
Xygeni clasifică datele gestionate de fiecare endpoint, semnalând PII, PCI și PHI în parametrii solicitării și în răspunsuri și asociind aceste date cu starea de autentificare a endpoint-ului.
De asemenea, corelează descoperirile care ajung pe același endpoint și crește severitatea atunci când acestea se compun. O scurgere de informații personale (PII) într-un răspuns este o descoperire gravă în sine. Aceeași scurgere de informații pe un endpoint care nu necesită autentificare este critică, iar platforma o evaluează în acest fel, în loc să lase conexiunea pentru ca cineva să o observe manual.
Puncte finale zombi și orfane: Deriva dintre cod și specificații
Deoarece Xygeni citește codul și specificațiile API-ului alăturate, vede unde acestea nu sunt de acord. Această abatere apare sub forma a trei modele recognoscibile:
- Puncte finale nedocumentate. Acestea există în cod și nu au fost niciodată adăugate la specificații.
- Puncte finale zombi. Sunt marcate ca perimate sau retrase și sunt încă accesibile.
- Puncte finale orfane. Nimeni din echipa actuală nu le deține.
Niciunul dintre acestea nu apare într-un inventar bazat exclusiv pe specificații, deoarece specificația este exact ceea ce le lipsește.
Dovezi pe baza cărora poți acționa, nu un bilet pentru a investiga
Fiecare constatare indică exact handler-ul responsabil: fișierul, clasa, metoda și linia specifică care a introdus defectul, cu codul ofensator redat alături de acesta. Fiecare conține, de asemenea, gravitatea sa, categoria OWASP API Security Top 10, CWE-ul său, starea de autentificare a endpoint-ului și clasificarea sensibilității datelor implicate.
O constatare care doar denumește un endpoint îl trimite pe dezvoltator să caute prin baza de cod înainte de a putea începe măcar să remedieze ceva. O constatare care denumește linia îl plasează imediat la rezolvare.
Rezultatele sunt exportate ca JSON, CSV, Markdown și SARIF 2.1.0, deci ajung în tinstrumentele în care echipele dumneavoastră lucrează deja.
Handler-ul, linia și codul care au introdus expunerea. Nu este un tichet de investigat.
De ce se află pe o singură platformă, nu pe o altă consolă
Xygeni rulează API Security alături de SAST, SCA, Secrete de securitate, IaC și DAST în cadrul unei singure platforme, corelate prin ASPM, în loc să fie expediat ca un instrument separat, cu propriul său login și propria restanță.
Acest lucru este important deoarece descoperirile statice și descoperirile din timpul rulării răspund la întrebări diferite despre același endpoint și sunt mai utile împreună decât separat. Staticul vă spune că un endpoint este riscant înainte de a fi livrat. DAST confirmă ce este de fapt accesibil și exploatabil odată ce rulează.
Împărțiți acest lucru în două console și riscul corelat devine două restanțe fără legătură. Nimeni nu le reconciliază, iar endpoint-ul care este atât nedocumentat, cât și neautentificat nu se află în niciuna dintre cozi.
Vedeți suprafața reală de atac a API-ului. Securitatea API este disponibilă ca Enterprise un add-on pentru platforma Xygeni și o scanare se execută împotriva propriilor depozite din cadrul propriei infrastructuri.
FAQ
Poate spune ce endpoint-uri gestionează date sensibile?
Da. Xygeni semnalează PII, PCI și PHI în parametrii și răspunsurile endpoint-urilor și folosește această clasificare pentru a clasifica rezultatele în funcție de expunerea reală.
Poate rula pe fiecare pull request?
Da. Scanarea incrementală analizează doar endpoint-urile care s-au modificat, iar manifestul pe care îl produce poate concentra o scanare DAST ulterioară asupra acelorași endpoint-uri, astfel încât testarea statică și cea în timpul rulării să rămână aliniate la ceea ce s-a mutat efectiv.
Codul meu părăsește mediul meu?
Nu. Scanările rulează în propria infrastructură. Doar rezultatele sunt încărcate, protejate în tranzit și în repaus.
Cum obțin securitatea API?
Securitatea API este disponibilă ca Enterprise supliment. Solicitați o probă de conformitate (PoC) și aceasta va fi stabilită împreună cu dumneavoastră.
