care este lista de vulnerabilități OWASP Top 10?
publicată pentru prima dată în 2004 de Open Web Application Security Project, acum celebra listă de vulnerabilități OWASP Top 10 (inclusă în partea de jos a articolului) este probabil cea mai apropiată de comunitatea de dezvoltare care a ajuns vreodată la un set de porunci despre cum să-și păstreze produsele în siguranță.,această listă reprezintă cele mai relevante amenințări la adresa securității software astăzi, potrivit OWASP, la fruntea multora care se întreabă cum injecțiile SQL sunt încă o astfel de preocupare după toți acești ani. Ei judeca vulnerabilitate tipuri bazează pe patru criterii de puncte:
- ușor de exploatabilitate
- prevalențele
- detectabilitate
- impactul asupra afacerii
destul de Interesant, OWASP membre care nu au de fapt un factor de luat în calcul probabilitatea ca atacatorii vor încerca să exploateze o anumită vulnerabilitate.,
când a început, scriitorii au decis că cel mai bun mod de a acoperi cel mai mult teren a fost de a pune vulnerabilități similare pe care le credeau a fi cele mai îngrijorătoare în grupări. Ei au recunoscut că, în lipsa statisticilor adecvate, ar putea exista întotdeauna o întrebare asupra vulnerabilităților care au fost în mod necesar îngrijorările de top, mai ales că aceasta poate fi o întrebare subiectivă conform modelului de amenințare al fiecărei organizații.cu toate acestea, după multe dezbateri, și-au oferit lista cu ceea ce credeau că se adresează celui mai larg set de organizații, deși nu într-o ordine specială.,cu timpul, Lista de vulnerabilități OWASP Top 10 a fost adoptată ca standard pentru cele mai bune practici și cerințe de către numeroase organizații, stabilind un standard într-un sens pentru dezvoltare. Un bine cunoscut adoptator al listei este standardele de procesare a plăților PCI-DSS.din păcate, deoarece lista de vulnerabilități OWASP Top 10 a ajuns la un public mai larg, intențiile sale reale ca ghid au fost interpretate greșit, rănind dezvoltatorii în loc să ajute. Deci, cum ar trebui să înțelegem scopul acestei liste și să încurajăm dezvoltatorii să codifice mai sigur?,
înțelegerea actualizărilor la lista din 2017
în anii care au urmat, au reîmprospătat și reordonat intrările, adăugând unele noi tipuri de vulnerabilitate pe măsură ce devin relevante, chiar dacă altele au fost eliminate din listă. Noile versiuni au fost emise în 2010, 2013 și 2017. Noua listă a fost asamblată după un studiu lung și dificil, care a analizat peste 50,000 de aplicații și a analizat aproximativ 2,3 milioane de vulnerabilități.,
adepții obișnuiți ai listei vor fi observat că, împreună cu unele modificări ale ordinii — în ciuda faptului că atacurile de injecție rămân în top — există unii nou-veniți în versiunea actualizată din 2017 a familiei de vulnerabilități OWASP Top 10.
Bate concurenta la centimetru pe câmpul de lovind pe unvalidated redirecționează și înainte este problema neprotejat APIs., Includerea sa pe listă la numărul A10 este probabil rezultatul faptului că dezvoltatorii sunt pur și simplu mult mai dependenți de API-uri decât obișnuiau, interacționând cu mult mai multe componente și produse externe decât înainte. Venirea la fața locului A7 este o protecție insuficientă împotriva atacurilor, ceea ce bate dezvoltatorii pentru că nu sunt suficient de cuprinzători în adăugarea de Protecții pentru detectarea, înregistrarea și, desigur, răspunsul la încercările de a le dăuna produselor.,
cealaltă schimbare majoră aici în versiunea 2017 este combinarea referințelor de obiecte directe nesigure ale A4 și controlul accesului la nivel de funcție lipsă A7, creând o vulnerabilitate unificată a controlului accesului rupt și subliniind necesitatea stabilirii corecte a controalelor pentru cine poate și nu poate accesa conturile și datele.,
interpretarea greșită a listei de vulnerabilități OWASP Top 10
o forță pentru bine, această listă s-a transformat, din păcate, într-un instrument de rușine a dezvoltatorilor care nu reușesc să-i urmeze învățăturile, folosit ca un club pentru a-i mustra pentru că nu este perfect când vine vorba de securitate. Această abordare este contraproductivă și ratează misiunea OWASP de a încuraja și de a echipa dezvoltatorii să codifice mai sigur. În plus, nu reușește să recunoască realizările scorurilor dezvoltatorilor care împing cantități masive de software nou la o rată niciodată văzută.,într-un interviu recent, președintele OWASP, Martin Knobloch, și-a exprimat dezamăgirea față de faptul că lista este folosită ca un fel de listă de verificare pentru o trecere finală înainte de lansare, servind mai mult ca mecanism de validare decât ca ghid.
ca cineva care crede cu tărie într-o abordare de stânga a securității, nu sunt surprinzător de copleșitor de acord cu frustrarea lui Knobloch de cât de mulți au luat lista OWASP Top 10 ca instrument al FUD și nu setul de principii directoare care a fost destinat să fie.,strategiile de securitate organizaționale care depind de așteptarea eșecului din partea elementelor umane în modul în care securizează software-ul în favoarea instrumentelor strălucitoare sunt obligate să eșueze.
în ultimii ani, mesageria de la prea mulți furnizori, în special în partea de rețea, a fost că „perimetrul este mort” și că companiile trebuie să caute securitate la adâncime pentru a găsi băieții răi care sunt deja în rețeaua lor., Mult prea multe titluri la conferințe au încercat să convingă CISOs că echipele de hackeri de elită sunt gunning pentru ei cu rarefiat 0-day exploit care le va lăsa fără apărare, dacă nu cumpăra produsul lor într-un fel care le va face inexpugnabilă pentru aceste altfel de neoprit atacuri. această perspectivă asupra stării de securitate este inutil fatalistă, picurând cu hype de marketing și ratează unele dintre conceptele de bază ale modului în care profesioniștii în securitate ar trebui să se gândească la risc.,o abordare cuprinzătoare a securității nu ar trebui să predice eliminarea dezvoltatorilor umani din proces, doar pentru a aduce instrumentele de securitate ale unui furnizor pentru a le repara după ce și-au terminat munca. Acest lucru presupune că dezvoltatorii nu pot fi de încredere, este insultător și nu face nimic pentru a vă face echipa mai puternică atunci când vine vorba de securitate și gestionarea riscurilor.
ce este și nu este lista de vulnerabilități OWASP Top 10
de câteva ori pe an există postarea obligatorie pe blog care întreabă cum este posibil ca în 2017 să vorbim încă despre atacuri la nivel de script kiddie., Probabil am scris și eu câteva dintre acestea, pentru care îmi cer scuze.
OWASP Top 10 nu este configurat pentru a rezolva fiecare atac din carte, ci pentru a ajuta echipele să evite greșelile comune care sunt mult mai susceptibile de a-și încălca aplicațiile. Un atacator determinat poate găsi multe căi de a-și încălca ținta. Cu toate acestea, recomandările inteligente de gestionare a riscurilor nu se concentrează pe minoritatea cazurilor, ci încearcă să abordeze problemele cu care se confruntă cea mai largă audiență.,
pentru a trage de La conceptele de fizică domeniul de securitate, media manager de risc ar trebui să fie mult mai îngrijorat de clientul ei obține într-un accident pe drum decât ninja antrenat de Echipa SEAL 6 vine prin ferestre, ghidat de AI (și blockchain). securitatea reală se referă la instruirea oamenilor cu privire la modul de lucru în siguranță și la oferirea tehnologiilor, cunoștințelor și proceselor pentru a-i ajuta să rămână în siguranță., În timp ce este întotdeauna important pentru a rula QA și finale controale de securitate înainte de a o elibera, de securitate trebuie să înceapă de la primele etape de cum merge echipa, care rulează de-a lungul procesului de dezvoltare a produsului. Se vor întâmpla greșeli, dar este mult mai rentabil și de-a dreptul mai inteligent să încerci să eviți cât mai multe probleme posibil în primul rând.pentru mulți dezvoltatori, obiectivul de conducere se concentrează pe obținerea produsului să funcționeze, concentrându-se mai puțin pe siguranța sau nu. Nu este vina lor.,de-a lungul educației lor, au aflat că, dacă produc un produs cu o cantitate minimă de bug-uri, atunci au primit un A. securitatea ar fi oricum gestionată de un alt departament. În schimb, managerii trebuie să profite de ocazie pentru a le arăta o modalitate mai bună de a lucra, care include luarea în considerare a modului în care codifică și a componentelor cu care lucrează, afectează securitatea produsului lor.,
OBȚINE 451 RESEARCH REPORTON ASIGURAREA OPEN SOURCE SOFTWARE-ul Descărca Gratuit,
Măsuri Practice Pentru a Permite Mai bune Practici de Securitate
O capcană comună care a ieșit de zile de la cascada de dezvoltare a fost să aștepte până la sfârșitul ciclului de dezvoltare pentru a efectua controale de securitate, în care dezvoltatorii vor primi o listă de vulnerabilități pentru a repara, întârziind eliberarea și creșterea frecării între ele și echipa de securitate.,în speranța de a lubrifia angrenajele și de a ține pasul cu viteza DevOps, organizațiile caută noi modalități de a-și asigura Codul De la început și de a menține armonia între departamentele lor.o metodă din ce în ce mai populară pentru a aduce securitatea în etapele anterioare ale dezvoltării produsului este în echipele cu polenizare încrucișată, cu un amestec de dezvoltatori și oameni de securitate, permițând fiecărei părți să ofere informații și să învețe unul de la celălalt., Aceasta poate fi o oportunitate excelentă pentru experții în securitate de a aduce în discuție multe dintre problemele pe care OWASP Top 10 încearcă să le abordeze într-un mediu mai puțin conflictual, într-o etapă care ar putea avea de fapt un impact.
când vine vorba de instrumente care pot contribui la promovarea unei implementări mai bune a securității, trebuie să ne gândim nu numai la modul în care tehnologia ne poate prinde greșelile sau încălcările după fapt, ci ne poate ajuta să lucrăm mai inteligent și mai sigur încă din primele etape., Această perspectivă este parte integrantă a mentalității de stânga-stânga, căutând oportunități de a aborda problemele înainte ca acestea să devină probleme costisitoare.un exemplu clar al modului în care tehnologiile pentru deplasarea spre stânga pot ajuta dezvoltatorii să utilizeze OWASP Top 10 vine cu intrarea numărul 9 care avertizează împotriva utilizării componentelor cu vulnerabilități cunoscute. Una dintre cele mai frecvente probleme care apar în acest spațiu este obținerea vizibilității asupra componentelor open source pe care le-au adăugat produsului lor.,dezvoltatorii apelează aproape întotdeauna la componente open source pentru a-i ajuta să-și construiască produsul mai rapid și mai eficient, adăugând funcții puternice, fără a fi nevoie să scrie singuri noul cod.în majoritatea cazurilor, este puțin probabil să verifice dacă componenta are vulnerabilități cunoscute înainte de a o adăuga la produsul lor. Chiar dacă efectuează o verificare sumară pentru a vedea dacă are probleme specifice, este puțin probabil să fie conștienți de probleme în dependențele componentei.,
cu toate Acestea, dacă acestea sunt folosind un Software Compoziția instrument de Analiză, de fapt, ei pot primi informații utile despre dacă o componentă open source are vulnerabilități cunoscute asociate cu acesta de-a lungul ciclului de viață de dezvoltare de software (SDLC), economie de timp care altfel ar fi petrecut rupere și înlocuirea componentelor după un cec de la echipa de securitate mai târziu înainte de eliberare, după ce a fost angajat la codul lor.,
fii un factor de securitate în cadrul organizației
pe baza lecturii mele din OWASP Top 10 și comentariile lui Knobloch, lista ar trebui să fie luată ca un instrument pentru abilitarea echipelor să includă securitatea în procesul lor de gândire a modului în care codifică, configurează și livrează produsele lor.
echipele de securitate care nu se angajează cu dezvoltatorii lor, făcând efortul de a înțelege modul în care le pot împuternici să aibă securitatea ca element inerent al fluxului lor de lucru, se vor găsi rapid marginalizate.,dacă doriți să rămâneți relevant, deveniți un facilitator și utilizați lista OWASP Top 10 ca o modalitate de a începe conversațiile, nu de a amenința. În cele din urmă, s-ar putea să descoperiți că prindeți mai multe (o)viespi cu miere decât oțet.
lista oficială de vulnerabilități OWASP Top 10
A1. Injecție-defectele de injecție, cum ar fi injecția SQL, NoSQL, OS și LDAP, apar atunci când datele de încredere sunt trimise unui interpret ca parte a unei comenzi sau interogări. Datele ostile ale atacatorului pot păcăli interpretul să execute comenzi neintenționate sau să acceseze date fără autorizarea corespunzătoare.
A2., Autentificare defectuoasă – funcțiile aplicației legate de autentificare și gestionarea sesiunilor sunt adesea implementate incorect, permițând atacatorilor să compromită parole, chei sau jetoane de sesiune sau să exploateze alte defecte de implementare pentru a-și asuma identitatea altor utilizatori temporar sau permanent.
A3. Expunerea datelor sensibile – multe aplicații web și API-uri nu protejează în mod corespunzător datele sensibile, cum ar fi cele financiare, de asistență medicală și PII. Atacatorii pot fura sau modifica astfel de date slab protejate pentru a efectua fraude cu carduri de credit, furt de identitate sau alte infracțiuni., Datele sensibile pot fi compromise fără protecție suplimentară, cum ar fi criptarea în repaus sau în tranzit și necesită precauții speciale atunci când sunt schimbate cu browserul.
A4. Entități externe XML (XXE) – multe procesoare XML mai vechi sau slab configurate evaluează referințele entităților externe din documentele XML. Entitățile externe pot fi utilizate pentru a dezvălui fișiere interne folosind handler-ul de fișiere URI, acțiuni de fișiere interne, scanarea porturilor interne, executarea codului de la distanță și atacurile de refuz al serviciului.
A5.,Controale de acces întrerupte-restricțiile privind ceea ce li se permite utilizatorilor autentificați nu sunt adesea aplicate în mod corespunzător. Atacatorii pot exploata aceste defecte pentru a accesa functionalitati si/sau date neautorizate, a accesa conturile altor utilizatori, a vizualiza fisiere sensibile, a modifica datele altor utilizatori, a schimba drepturile de acces etc.
A6. Securitate Misconfiguration – securitate misconfiguration este problema cel mai frecvent observate., Acest lucru este de obicei un rezultat nesigur, default configurații, incomplete sau ad-hoc configurații, deschis de stocare cloud, greșit antete HTTP, și verbose mesaje de eroare care conțin informații sensibile. Nu numai că toate sistemele de operare, cadrele, bibliotecile și aplicațiile trebuie configurate în siguranță, dar trebuie să fie patch-uri/actualizate în timp util.
A7.,Cross Site Scripting (XXS)-defectele XSS apar ori de câte ori o aplicație include date de încredere într-o nouă pagină web fără validare sau scăpare corespunzătoare sau Actualizează o pagină web existentă cu date furnizate de utilizator folosind un API de browser care poate crea HTML sau JavaScript. XSS permite atacatorilor să execute scripturi în browser-ul victimei, care poate deturna sesiuni de utilizator, deface site-uri web, sau redirecționa utilizatorul către site-uri rău intenționate.
A8. Deserializare nesigură – deserializarea nesigură duce adesea la executarea codului de la distanță., Chiar dacă defectele de deserializare nu duc la executarea codului de la distanță, ele pot fi utilizate pentru a efectua atacuri, inclusiv atacuri de reluare, atacuri de injecție și atacuri de escaladare a privilegiilor.
A9. Utilizarea componentelor cu vulnerabilități cunoscute-componente, cum ar fi biblioteci, cadre și alte module software, rulează cu aceleași privilegii ca și aplicația. Dacă o componentă vulnerabilă este exploatată, un astfel de atac poate facilita pierderea gravă a datelor sau preluarea serverului., Aplicațiile și API-urile care utilizează componente cu vulnerabilități cunoscute pot submina apărarea aplicațiilor și pot permite diverse atacuri și impacturi.
A10. Insuficientă Logare & Monitorizare – Insuficiente de înregistrare și monitorizare, împreună cu lipsă sau ineficiente integrarea cu răspuns la incidente, și permite atacatorilor la alte sisteme de atac, pentru a menține persistența, pivot la mai multe sisteme, și manipuleze, extract, sau distruge date., Majoritatea studiilor de încălcare arată că timpul pentru detectarea unei încălcări este de peste 200 de zile, de obicei detectat de părți externe, mai degrabă decât de procese interne sau de monitorizare.