Moarte de o mie de scurgeri de date: cum API-urile copleșesc securitatea

Suprafețele de atac de astăzi sunt mai largi ca niciodată, vulnerabilitățile ieșind din aplicații și locuind în interfețele flexibile de programare a aplicațiilor care țin lumea tehnologiei în schimbare.

Din păcate, deși majoritatea sunt conștienți de amenințările tradiționale ale aplicațiilor web, API-urile rămân o zonă tulbure de securitate. Peisajul imens de amenințări de astăzi necesită un WAF cloud competent și chiar investiții în WAAP.

Ce este un API?

API-urile sunt lipiciul care menține împreună experiența modernă de navigare. API-urile simplifică utilizarea și dezvoltarea software-ului, permițând aplicațiilor web individuale să facă schimb de date. Efectuarea unei cereri către un server prin intermediul unei aplicații este în prezent gestionată de un API relevant, datorită faptului că API-urile implementate corespunzător sunt foarte sigure.

În loc ca serverul să fie expus direct la informațiile dvs., dispozitivul dvs. și API-ul relevant ar trebui să partajeze pachete mici de date, comunicând doar ceea ce este necesar.

Agile și API: Security Double-Trouble

Agil este cuvântul la modă în afaceri de altădată – descrie o formă de producție care amplifică ideea antreprenorială de „produs minim viabil”. Scopul Agile este de a împinge produsul minim în fiecare etapă; în loc să numiți vreodată un produs „terminat”, acesta este doar inclus într-o nouă rundă de corecție a erorilor și îmbunătățiri.

Deși această corecție perpetuă pare fantastică pentru securitate (suport software constant? Frumos!), Realitatea economică a producției de software înseamnă că cantitatea de API-uri devine rapid greoaie.

Pe măsură ce echipele de dezvoltare se mișcă rapid, API-urile sunt rareori documentate complet. Acest lucru face incredibil de greu să cercetezi mecanismele interne ale unei aplicații și să înțelegi ce API-uri fac. De asemenea, face securitatea infinit mai dificilă, deoarece echipele de dezvoltare nu cunosc adevărata dimensiune a inventarului lor API. Acest lucru plasează securitatea cibernetică ca o prioritate scăzută; întotdeauna reactiv și niciodată proactiv.

API-uri trecute cu vederea

Când se menționează securitatea aplicației, primul lucru care îmi vine în minte sunt greii securității. Atacuri precum cross-site-scripting; Injecția SQL și atacurile DDoS sunt toate incredibil de bine cunoscute. Aplicațiile în sine sunt adesea bine păzite de soluții plug-and-play, cum ar fi firewall-uri pentru aplicații web de patrulare în perimetru.

Puțină atenție este vreodată acordată API-urilor, mult în detrimentul organizației uite și clienților lor. Luați exemplul unei vulnerabilități API care a apărut în sistemul Uber.

Când un șofer Uber se alătură Uber printr-un link de recomandare, pornește aplicația și introduce codul de recomandare. La apăsarea butonului Enter, browserul aplicației comunică cu gazda API „bonjour.uber.com”. De acolo, bonjour.uber primește parametrul User ID și returnează detalii despre șofer înapoi în aplicația utilizatorului, gata să fie introduse în următorul ecran de consimțământ.

Cu toate acestea, acest API a fost găsit vinovat de două încălcări majore de securitate. Prima a fost Broken Object Level Authorization (BOLA). API-ul nu a verificat dacă ID-ul utilizatorului se potrivește cu parametrul ID; Prin urmare, a fost posibil să se acceseze datele altor utilizatori prin simpla schimbare a ID-ului utilizatorului.

A doua problemă a fost expunerea excesivă a datelor. Răspunsul API-ului – de a returna detaliile utilizatorului – a grupat toate aceste informații într-un singur lot, conținând fiecare dintre detaliile utilizatorului. Aceasta însemna că API-ul a returnat informații de care clientul nu avea nevoie în mod explicit, încălcând un pilon major al celor mai bune practici de securitate cibernetică.

Acum luați în considerare că organizația medie se bazează pe peste 15.500 de API-uri, iar scara riscului începe să apară. Din fericire, API-ul Uber a fost conectat înainte să apară vreo daune majore; următoarea companie nu a fost la fel de norocoasă.

Problema Peloton

Brandul Peloton de fitness la domiciliu este bucurat de peste 3 milioane de abonați. Cursurile de fitness live sunt un argument important de vânzare, deși dacă nu sunteți dispus să împărtășiți datele dumneavoastră medicale cu alți participanți la curs, atunci este posibil să vă setați contul de peloton la privat.

Din păcate, o serie de vulnerabilități API au văzut expunerea acestor date către utilizatori neautorizați. Informațiile participanților la curs ar putea fi răzuite pe scară largă, deoarece un punct final API nu a reușit să valideze un utilizator solicitant. Acest lucru a permis atacatorilor neautorizați să obțină numele de utilizator, locația, ID-ul antrenamentului, sexul și vârsta utilizatorilor Peloton.

API-urile au fost cauza unor scurgeri de date importante de ani de zile. Scandalurile constante de date ale Facebook de-a lungul anilor 2018 și 2019 au văzut o încălcare după alta, în primul rând prin intermediul API-urilor pentru dezvoltatori terți. Un exemplu a fost API-ul Groups; dezvoltatorii care lucrează la o aplicație de gestionare a rețelelor sociale B2B ar putea accesa liber numele și mai multe informații personale ale membrilor grupului. Deși această aplicație de gestionare a rețelelor sociale a fost menită să ajute administratorii de grup să își gestioneze grupurile mai eficient, Facebook a trebuit să o elimine și API-ul său.

Aceste scandaluri de date au culminat în 2021, când o bază de date de pe piața neagră de peste 533 de milioane de utilizatori Facebook au avut scurgeri de nume, numere de telefon și ID-uri de utilizator Facebook.

Prevenirea scurgerii API

Open Web Application Security Project (OWASP) publică în mod regulat cele mai grave și răspândite vulnerabilități ale aplicațiilor web pe care să le urmăriți. Amenințarea de securitate în creștere reprezentată de API-uri este suficient de severă pentru a-și justifica propria listă de top-10 OWASP, care este în mod constant în frunte cu Autorizarea la nivel de obiect spart.

Din fericire, protejarea API-urilor dvs. – în afara necesității unui ciclu de dezvoltare mai lent – ​​urmărește îndeaproape cu securizarea organizației dvs. în ansamblu. Primul tău punct de apel ar fi un Web Application Firewall (WAF) decent. Această soluție monitorizează perimetrele aplicațiilor dvs., prevenind exploatarea gateway-urilor API de vulnerabilități majore.

Web Application and API Protection (WAAP) duce lucrurile cu un pas mai departe. Se află în întregime la limita publică a unei aplicații, analizând tot traficul de intrare. Prin monitorizarea tiparelor de trafic și solicitări legitime, WAAP-urile sunt instrumente de securitate extrem de specializate concepute special pentru a proteja API-urile.

În timp ce WAAP este un sistem defensiv la nivel de punct final, soluțiile Runtime Application Self Protection (RASP) se referă la anumite aplicații web. O soluție RASP – diferită de WAF – are, de asemenea, o perspectivă asupra funcționării interne și a comportamentelor aplicației sale. În acest fel, în cazul în care un API ar fi folosit ca punct de sprijin într-un atac și ar fi solicitat mai multe informații decât ar trebui să fie posibil, un RASP poate închide un atac în mod proactiv.

Cu o multitudine de opțiuni de protecție API disponibile, securizarea aplicațiilor și a organizației nu a fost niciodată mai ușoară.