Prin ce diferă securitatea API de securitatea generală a aplicațiilor?
Publicat: 2023-07-19Deși uneori confundate cu același lucru, securitatea aplicațiilor și securitatea API sunt două discipline distincte. Securitatea aplicațiilor se referă la securizarea aplicațiilor întregi, în timp ce securitatea API se referă la securizarea API-urilor pe care organizațiile le folosesc pentru a conecta aplicații și a face schimb de date. Ca atare, organizațiile trebuie să adopte abordări diferite ale celor două discipline.
Ce este securitatea aplicației?
Securitatea aplicațiilor (AppSec) utilizează practici de autorizare, criptare și codare securizată pentru a proteja datele și sistemele de atacurile cibernetice. Organizațiile care implementează AppSec reduc riscul de încălcare a datelor, protejează datele sensibile și se asigură că aplicațiile lor respectă standardele din industrie.
ISACA definește cele cinci componente critice ale programelor AppSec astfel:
- Securitate prin proiectare
- Testarea codului securizat
- Lista materialelor software
- Instruire și conștientizare în materie de securitate
- WAF-uri și gateway-uri de securitate API și dezvoltare de reguli
Ce este securitatea API?
Securitatea API sau interfața de programare a aplicațiilor protejează API-urile de atacurile cibernetice. Utilizarea API a explodat în ultimii ani, oferind organizațiilor oportunități de inovare, permițând transferurile de date între aplicații. Din păcate, pe măsură ce utilizarea API-urilor a crescut, la fel și atacurile lansate asupra lor. Cercetările de la Salt Security au arătat că atacurile asupra API-urilor au crescut cu 400% între iunie și decembrie 2022.
Amenințări de securitate aplicație vs. API
Înțelegerea diferenței dintre securitatea AppSec și API necesită înțelegerea principalelor amenințări ale fiecărei discipline. Din fericire, OWASP, o organizație non-profit care încearcă să îmbunătățească securitatea software-ului, oferă o listă cuprinzătoare a celor mai semnificative amenințări la adresa securității aplicațiilor și a securității API. Cunoscute sub numele de OWASP Top Ten, listele adună informații de la comunitatea globală de experți în securitate a OWASP pentru a identifica cele mai critice amenințări la adresa aplicațiilor și API-urilor.
Interesant este că, în timp ce OWASP a publicat topul celor mai bune zece riscuri de securitate a aplicațiilor web în 2003, a lansat lista Top zece riscuri de securitate API abia la sfârșitul anului 2019. Această discrepanță reprezintă o altă diferență cheie între securitatea aplicației și API: securitatea aplicației este bine stabilită, disciplină amplu cercetată care a trecut prin numeroase etape evolutive, în timp ce securitatea API nu este.
Deși nu avem timp pentru o analiză aprofundată, merită să ne uităm pe scurt la fiecare listă pentru a vedea cum diferă, ceea ce ar trebui să informeze modul în care organizațiile abordează securitatea AppSec și API.
Primele zece riscuri de securitate a aplicațiilor OWASP (2021)
- Controlul accesului întrerupt – Când un utilizator neautorizat poate accesa informații sau sisteme restricționate
- Eșecuri criptografice - Când o terță parte expune date sensibile fără o intenție specifică din cauza lipsei sau defectelor criptografiei
- Injectare – Când un atacator încearcă să trimită date către o aplicație într-un mod care va schimba sensul comenzilor trimise unui interpret
- I nsecure Design – Riscuri legate de defecte arhitecturale și de design
- Configurare greșită a securității – Când echipele de securitate configurează incorect sau lasă controalele de securitate nesigure
- Componente vulnerabile și învechite – atunci când organizațiile lasă componente nepatchizate
- Eșecuri de identificare și autentificare (nee Broken Authentication) - Când aplicațiile sunt vulnerabile la atacuri de autentificare
- Eșecuri de integritate software și date – Când codul și infrastructura nu reușesc să protejeze împotriva încălcărilor de integritate
- Eșecuri de înregistrare și monitorizare a securității (nee înregistrare și monitorizare insuficiente) - Când organizațiile nu reușesc să detecteze încălcări ale datelor din cauza procedurilor inadecvate de înregistrare și monitorizare
- Falsificarea cererilor pe partea serverului – Când atacatorii păcălesc aplicațiile pentru a trimite o solicitare elaborată către o destinație neașteptată, chiar și atunci când sunt protejate de un firewall, VPN sau alt tip de listă de control al accesului la rețea (ACL)
Primele zece riscuri de securitate API OWASP (2023)
- Broken Object Level Authorization – Când un obiect API – de exemplu, baze de date sau fișiere – nu are controale de autorizare adecvate, acordând acces utilizatorilor neautorizați
- Autentificare întreruptă - Când inginerii de software și de securitate înțeleg greșit limitele autentificării API și cum să o implementeze
- Broken Object Property Level Authorization – O combinație de expunere excesivă a datelor și atribuire în masă: atunci când atacatorii exploatează o blocare sau o autorizare necorespunzătoare la nivelul proprietății obiectului.
- Consum nerestricționat de resurse – Satisfacerea solicitărilor API necesită lățime de bandă a rețelei, CPU, memorie și stocare. Furnizorii de servicii pun la dispoziție alte resurse, cum ar fi e-mailuri/SMS/apeluri telefonice sau validarea biometrică, prin integrări API și plătite la cerere. Atacurile de succes pot duce la refuzarea serviciului sau la creșterea costurilor operaționale.
- Autorizarea la nivel de funcție întreruptă implică atacatorii care trimit apeluri API legitime către punctele finale API expuse
- Acces nerestricționat la fluxuri de afaceri sensibile – API-urile vulnerabile la acest risc expun un flux de afaceri – cum ar fi cumpărarea unui bilet sau postarea unui comentariu – fără a compensa modul în care funcționalitatea ar putea dăuna afacerii dacă este folosită excesiv într-o manieră automată; acest lucru nu vine neapărat din erori de implementare.
- Falsificarea cererilor pe partea serverului – Când un API preia o resursă de la distanță fără a valida URI-ul furnizat de utilizator; permițând unui atacator să constrângă aplicația să trimită o cerere crafted către o destinație neașteptată, chiar și atunci când este protejată de un firewall sau de un VPN.
- Configurare greșită a securității – API-urile și sistemele care le suportă conțin de obicei configurații complexe pentru a le face mai personalizabile. Inginerii software și DevOps pot să rateze aceste configurații sau să nu urmeze cele mai bune practici de securitate în ceea ce privește configurarea, deschizând ușa pentru diferite tipuri de atacuri.
- Gestionarea incorectă a inventarului – API-urile expun mai multe puncte finale decât aplicațiile web tradiționale, făcând importantă documentația corectă și actualizată. Un inventar adecvat al gazdelor și al versiunilor de API implementate este, de asemenea, esențial pentru a atenua probleme precum versiunile API depreciate și punctele finale de depanare expuse.
- Consum nesigur de API-uri – Dezvoltatorii tind să aibă încredere în datele primite de la API-uri terță parte mai mult decât în input-ul utilizatorului și adoptă standarde de securitate mai slabe. Pentru a compromite API-urile, atacatorii caută servicii integrate de la terți în loc să încerce să compromită direct API-ul țintă.
După cum puteți vedea, deși există unele suprapuneri, aplicațiile și API-urile sunt în principal supuse unor amenințări diferite și unice, iar organizațiile trebuie să răspundă în consecință. Diferența cheie dintre cele două liste este că organizațiile pot atenua toate riscurile critice asociate cu securitatea aplicațiilor cu instrumente și tehnici tradiționale de securitate multifuncționale, dar securitatea API este diferită.
Securitatea API este o problemă extrem de modernă care necesită o soluție la fel de modernă. Organizațiile nu se pot aștepta ca instrumentele pe care le folosesc pentru a-și proteja aplicațiile și alte active pentru a îndeplini sarcina de a securiza API-urile. Securitatea API necesită instrumente de securitate specifice API; metodele tradiționale de protecție, cum ar fi gateway-urile API și Web Application Firewall-uri (WAF) nu merg suficient de departe.