Majoritatea echipelor tratează securitatea API ca pe o problemă de autentificare. Adaugă tokenuri, le verifică pe fiecare rută și consideră treaba încheiată. Apoi un tester schimbă o singură cifră într-un URL și citește factura altui client.

Exact în această distanță dintre „autentificat” și „autorizat” se află majoritatea breșelor reale de API, iar un scaner nu o descoperă în mod fiabil. Un instrument automat vede un token valid și un răspuns 200 și raportează succes. Doar un om care înțelege regulile tale de business observă că răspunsul conținea datele altcuiva.

Distincția esențială: autentificarea dovedește cine face apelul. Autorizarea decide ce anume poate vedea sau modifica exact acel apelant, iar ea trebuie impusă pe fiecare obiect, la fiecare cerere, în stratul de date. Aproape orice vulnerabilitate serioasă de API este o cădere a celei de-a doua, în timp ce prima funcționează impecabil.

Autorizarea defectuoasă la nivel de obiect și de ce domină

Cea mai frecventă vulnerabilitate gravă de API este și cea mai simplu de descris.

Endpointul tău este /api/invoices/48213. Apelantul este autentificat, așa că handlerul aduce factura 48213 și o returnează. Nimeni nu verifică dacă factura 48213 îi aparține acelui apelant. Schimbi numărul, primești factura altcuiva. API-ul s-a comportat exact așa cum a fost scris; scrierea a fost greșită.

Lucrul acesta scalează prost pentru tine și excelent pentru un atacator. Identificatorii secvențiali permit cuiva să parcurgă întregul tău set de date cu o simplă buclă. Trecerea la identificatori imposibil de ghicit ajută puțin, dar nu este o rezolvare, pentru că identificatorii se scurg oricum prin alte endpointuri, prin exporturi și prin e-mailuri.

Rezolvarea este structurală, nu întâmplătoare. Apartenența trebuie verificată chiar în interogare: adu factura care aparține acestui client și poartă acest identificator, în loc să aduci factura și să speri că verifică ceva mai încolo. Pune acea verificare în stratul de acces la date, ca să nu poată fi uitată într-un controller nou, scris peste șase luni de cineva care nu a citit niciodată acest paragraf.

Aceeași cădere se aplică funcțiilor, nu doar obiectelor. Dacă un endpoint administrativ este protejat doar de faptul că interfața nu îl afișează utilizatorilor obișnuiți, atunci nu este protejat deloc.

Vulnerabilitățile de securitate API care apar cu adevărat

Dincolo de autorizare, o mână de probleme explică majoritatea constatărilor. OWASP API Security Top 10 este referința standard aici, iar OWASP o revizuiește periodic, așa că verifică ediția curentă, nu un rezumat.

Returnarea a mai mult decât arată interfața. Un endpoint returnează obiectul utilizator complet pentru că așa a fost comod, iar interfața afișează trei câmpuri. Celelalte douăsprezece, inclusiv tokenul de resetare a parolei și scorul intern de risc, rămân în răspuns. Oricine deschide fila de rețea le are. Serializează deliberat: construiește răspunsul din câmpuri numite, în loc să reverși un model întreg.

Atribuirea în masă la intrare. Imaginea în oglindă. Un endpoint de actualizare a profilului acceptă orice câmpuri sosesc și le scrie în înregistrare, așa că un apelant adaugă "role": "admin" și se promovează singur. Leagă explicit datele de o listă de câmpuri permise, în loc să accepți corpul cererii în bloc.

Consum nelimitat. Fără limite, un singur apelant poate cere un milion de înregistrări pe pagină, poate rula căutări costisitoare în buclă sau poate declanșa mii de resetări de parolă. Nu este doar o chestiune de indisponibilitate; acolo unde fiecare cerere te costă bani, ca în cazul unui model de limbaj aflat în spatele endpointului tău, este un atac asupra facturii. Limitele de rată se pun pe consumator și pe endpoint, iar operațiunile scumpe se limitează mai strâns decât cele ieftine.

Inventar și încredere în terți

Endpointuri nedocumentate și uitate. Versiunea doi este în producție și documentată, versiunea unu încă rulează cu vechea logică de autorizare, iar un API de staging cu date reale este accesibil din internet. Atacatorii caută exact așa ceva. Ține un inventar al fiecărui API pus în funcțiune, al fiecărei versiuni și al fiecărui mediu, și scoate lucrurile din uz în mod deliberat, nu prin neglijență.

Încrederea în sistemele pe care le apelezi. API-ul tău consumă alte API-uri, iar răspunsurile lor ajung în baza ta de date și în ceea ce afișezi. Validează ce vine înapoi, în loc să presupui că un partener este sigur. Un răspuns venit din exterior rămâne o intrare, cu tot ce presupune asta în materie de verificări. Ghidul nostru despre integrarea API-urilor terțe tratează latura de fiabilitate a aceleiași relații.

Cum construiești corect autentificarea

Autentificarea este partea pe care majoritatea echipelor o nimeresc aproximativ, așa că aici discutăm detaliile care o strică.

Folosește tokenuri de acces cu durată scurtă și reînnoire, nu chei de lungă durată care nu expiră niciodată. O credențială scursă care funcționează la nesfârșit este o compromitere permanentă; una care expiră în cincisprezece minute este un incident cu un final delimitat.

Îngustează domeniul tokenurilor. Un token emis pentru o integrare de raportare nu ar trebui să poată crea utilizatori. Domeniile îți permit să impui asta central, în loc să te bazezi pe verificarea fiecărui handler în parte.

Validează tokenurile ca lumea, ceea ce înseamnă în primul rând să nu accepți algoritmul pe care îl declară tokenul însuși. Fixează algoritmul de semnătură așteptat, verifică emitentul și destinatarul și controlează expirarea. Există biblioteci care fac asta implicit; verificarea scrisă de mână este locul unde stau greșelile.

Rotește credențialele după un calendar și oferă consumatorilor o cale de schimbare fără oprire, de obicei acceptând două chei valide pe durata tranziției. Dacă rotația provoacă o cădere, nimeni nu o va face.

În fine, nu pune niciodată credențiale în URL-uri. Șirurile de interogare ajung în jurnalele serverului, în istoricul browserului, în jurnalele proxy și în anteturile de referință. Folosește anteturi.

Ce descoperă de fapt un test de penetrare

Scanarea automată și testarea manuală găsesc lucruri diferite, iar tu ai nevoie de amândouă din motive diferite.

Scanerele se descurcă bine cu dependențele vulnerabile cunoscute, anteturile de securitate lipsă, configurarea greșită a TLS și injecțiile evidente. Rulează-le continuu în pipeline, pentru că sunt ieftine și prind regresiile. Lista noastră de verificare pentru auditul de securitate al serverului arată ce se controlează pe partea de infrastructură.

Ce nu pot face este să raționeze despre afacerea ta. Un tester descoperă că un endpoint de coduri de reducere poate fi apelat repetat pentru a cumula reducerile, că o funcționalitate cu plată rămâne accesibilă dintr-un plan gratuit dacă apelezi direct API-ul, sau că anularea unei comenzi deja expediate declanșează o rambursare fără verificarea stocului. Acestea sunt constatările care costă bani reali și ies la suprafață doar când cineva înțelege la ce servește API-ul tău.

Pentru un API, cere explicit ca testul să includă verificarea autorizării între roluri: testerul deține credențiale pentru doi clienți diferiți și încearcă sistematic să ajungă la datele unui cont cu tokenul celuilalt. Acest singur exercițiu găsește mai mult decât toate celelalte la un loc. Prezentarea noastră despre tipurile de teste de penetrare explică cât acces merită să dai unui tester, iar documentația și credențialele oferite produc rezultate mult mai bune decât un test în orb.

La capitolul buget, testarea axată pe API pornește de obicei de la aproximativ £3.000 pentru un API mic și bine documentat și ajunge la £15.000 sau mai mult pentru o suprafață mare, cu mai multe roluri și integrări. Ghidul nostru privind costul testelor de penetrare detaliază ce anume mișcă acest interval.

Jurnalizează suficient cât să poți investiga

Diferența dintre un incident și o catastrofă stă de obicei în capacitatea de a reconstitui ce s-a întâmplat.

Jurnalizează evenimentele de autentificare, refuzurile de autorizare și fiecare operațiune care schimbă starea, fiecare cu identitatea apelantului, obiectul vizat și un identificator de corelare. Refuzurile de autorizare sunt în mod special avertismentul tău timpuriu: o integrare legitimă produce aproape niciunul, deci o rafală înseamnă că cineva sondează.

Nu jurnaliza valorile sensibile în sine. Tokenurile, datele cardurilor și datele personale ajunse în fișiere de jurnal transformă o breșă ținută sub control într-una care trebuie raportată.

Alertează pe tipare, nu pe volum. Un singur apelant care generează erori de autorizare pe multe identificatoare de obiecte înseamnă enumerare în desfășurare, iar pentru asta merită trezit cineva. Rata totală de erori nu înseamnă asta.

Păstrează jurnalele suficient cât să fie utile. Compromiterile sunt descoperite frecvent la săptămâni după ce au început, iar treizeci de zile de jurnale sunt adesea prea puține pentru a găsi punctul de intrare.

Testează API-ul pe care chiar l-ai livrat

Mecanik oferă testare de securitate a aplicațiilor axată pe defectele de autorizare și de logică de business pe care uneltele automate le ratează, inclusiv testare între conturi cu credențiale reale, pe mai multe roluri.

Lucrăm pornind de la specificația și documentația ta, nu ghicind suprafața expusă, ceea ce scoate la iveală, ca efect secundar, endpointurile nedocumentate și versiunile rămase în urmă. Acolo unde munca se extinde la infrastructură și rețea, serviciile noastre de testare de penetrare acoperă acel teren. Iar dacă API-ul tău stă în spatele unei aplicații web, ghidul nostru pentru auditul de securitate al site-ului arată cum se îmbină cele două verificări. Iar dacă încă proiectezi API-ul, ghidul nostru despre costul dezvoltării unui API arată unde își au locul autorizarea, limitarea ratei și jurnalizarea chiar în construcție, în loc să fie adăugate ulterior.

Trimite-ne specificația și o descriere a rolurilor, iar noi îți spunem unde se concentrează riscul.

Articole similare: WordPress spart: eliminarea programului malițios , Conformitate tehnică GDPR pentru dezvoltatorii din Marea , Cloudflare Zero Trust: un ghid pentru securitatea accesului în întreprindere , Testarea de penetrare in Marea Britanie .

Întrebări frecvente

Care este cea mai frecventă vulnerabilitate de securitate API? Autorizarea defectuoasă la nivel de obiect, în care un apelant autentificat ajunge la datele altui utilizator schimbând un identificator din cerere. Autentificarea funcționează corect, dar nimic nu verifică dacă obiectul cerut îi aparține apelantului. Apartenența trebuie deci impusă chiar în interogare.

Sunt suficiente cheile API pentru securitate? Nu de unele singure. Cheile de lungă durată care nu expiră niciodată transformă orice scurgere într-o compromitere permanentă. Folosește tokenuri de acces cu durată scurtă și reînnoire, limitează-le la ce are nevoie consumatorul, permite rotația fără oprire și trimite-le mereu în anteturi, nu în URL-uri.

Poate scanarea automată să securizeze un API? Nu, deși merită rulată continuu. Scanerele găsesc dependențe vulnerabile cunoscute, anteturi lipsă și injecții evidente. Nu pot raționa despre regulile tale de business, așa că ratează reducerile cumulate, funcționalitățile cu plată accesibile din planul gratuit și accesul la datele altui cont.

Cât costă un test de penetrare pentru un API? De obicei de la aproximativ £3.000 pentru un API mic și bine documentat până la £15.000 sau mai mult pentru o suprafață mare, cu mai multe roluri și integrări. Costul este determinat de numărul de endpointuri, de numărul de roluri distincte și de faptul dacă sunt puse la dispoziție documentația și credențialele.

Ce ar trebui să jurnalizeze un API din motive de securitate? Evenimentele de autentificare, refuzurile de autorizare și fiecare operațiune care schimbă starea, fiecare cu identitatea apelantului, obiectul vizat și un identificator de corelare. Nu jurnaliza niciodată tokenuri sau date personale. Alertează atunci când un singur apelant produce erori de autorizare pe multe identificatoare, semn de enumerare.