OWASP Top 10 seznam zranitelností – pravděpodobně jej používáte špatně

jaký je seznam zranitelností OWASP Top 10?

poprvé vydaný v roce 2004 projektem Open Web Application Security Project je nyní slavný seznam zranitelností OWASP Top 10 (obsažený v dolní části článku) pravděpodobně nejblíže, že vývojová komunita někdy dospěla k souboru přikázání, jak udržet své produkty v bezpečí.,

Tento seznam představuje dnes podle owaspa nejdůležitější hrozby pro bezpečnost softwaru, a to pro mnoho lidí, kteří se ptají, jak jsou injekce SQL po všech těch letech stále takovým problémem. Posuzují typy zranitelností na základě čtyř kritérií:

  1. snadná využitelnost
  2. prevalence
  3. detekovatelnost
  4. obchodní dopad

zajímavé je, že OWASP uvádí, že do své rovnice ve skutečnosti nezohledňují pravděpodobnost, že se útočníci pokusí zneužít určitou zranitelnost.,

když to začalo, spisovatelé se rozhodli, že nejlepší způsob, jak pokrýt co nejvíce půdy, bylo dát podobné zranitelnosti, o kterých se domnívali, že se nejvíce týkají seskupení. Uznali, že bez řádných statistik by vždy mohla existovat otázka, které zranitelnosti jsou nutně nejvyššími obavami, zejména proto, že to mohou být subjektivní otázky podle modelu ohrožení každé organizace.

po velké debatě však nabídli svůj seznam toho, o čem věřili, že oslovují nejširší soubor organizací, i když ne v žádném konkrétním pořadí.,

s časem byl seznam zranitelností OWASP Top 10 přijat jako standard pro osvědčené postupy a požadavky mnoha organizací a stanovil standard v smyslu pro vývoj. Jeden známý osvojitel seznamu je standardy zpracování plateb PCI-DSS.

bohužel, protože seznam zranitelností OWASP Top 10 dosáhl širšího publika, jeho skutečné záměry jako průvodce byly nesprávně interpretovány a ubližovaly vývojářům místo pomoci. Jak bychom tedy měli pochopit účel tohoto seznamu a skutečně povzbudit vývojáře, aby kódovali bezpečněji?,

porozumění aktualizacím seznamu 2017

v letech od té doby obnovily a přeskupily položky a přidaly některé nové typy zranitelností, jak se stanou relevantními, i když ostatní byli ze seznamu vyřazeni. Nové verze byly vydány v letech 2010, 2013 a 2017. Nový seznam byl sestaven po dlouhé a náročné studii, která zkoumala více než 50 000 aplikací a analyzovala přibližně 2, 3 milionu zranitelností.,

pravidelní následovníci seznamu si všimli, že spolu s některými změnami v pořadí — navzdory skutečnosti, že injekční útoky zůstávají na vrcholu-existují někteří nováčci v aktualizované verzi OWASP Top 10 zranitelnosti rodiny 2017.

porazit konkurenci, aby se dostala na pole tím, že zahájí neověřené přesměrování a dopředu, je otázkou nechráněných API., Jeho zařazení na seznam na místě číslo A10 je pravděpodobně důsledkem skutečnosti, že vývojáři jsou prostě mnohem více závislí na API než dříve, interagují s mnohem více komponenty a externími produkty než dříve. Přichází na A7 místě je nedostatečná ochrana útok, který srazí vývojáři za to, že dostatečně komplexní na přidávání ochrany pro detekci, záznam a samozřejmě reagovat na pokusy poškodit jejich produkty.,

další významnou změnou ve verzi 2017 je kombinace nejistých odkazů na přímé objekty A4 a chybějící kontroly přístupu na úrovni funkcí A7, vytvoření jednotné chyby zabezpečení kontroly přístupu a zdůraznění nutnosti řádného zavedení kontrol pro kdo může a nemůže přistupovat k účtům a datům.,

Interpretací OWASP Top 10 Zranitelností Seznam

silou dobra, tento seznam se bohužel proměnil v nástroj pro ostudu vývojáři, kteří nedokáží následovat jeho učení, se používá jako klub nadávat jim za to, že nejsem perfektní, když jde o bezpečnost. Tento přístup je kontraproduktivní a postrádá poslání společnosti OWASP povzbuzovat a vybavovat vývojáře, aby kódovali bezpečněji. Kromě toho, že nedokáže rozpoznat úspěchy skóre vývojářů, kteří se tlačí obrovské množství nového softwaru na nikdy předtím neviděl sazby.,

V nedávném rozhovoru vyjádřil předseda Owaspu Martin Knobloch své zklamání nad tím, že seznam byl použit jako jakýsi kontrolní seznam pro závěrečný běh před vydáním, který sloužil spíše jako ověřovací mechanismus než průvodce.

jako někdo, kdo silně věří v posun doleva přístup k bezpečnosti, jsem nepřekvapivě v drtivé shodě s Knobloch frustrace z toho, kolik vzali OWASP Top 10 seznam jako nástroj FUD, a ne soubor hlavních zásad, že to mělo být.,

náročné průmyslové přístupy k zabezpečení

organizační bezpečnostní strategie, které závisí na očekávání selhání lidských prvků v tom, jak zabezpečují software ve prospěch lesklých nástrojů, musí selhat.

v posledních letech zasílání zpráv od příliš mnoha dodavatelů, zejména na straně sítě, bylo to, že“ obvod je mrtvý “ a že společnosti musí hledat bezpečnost do hloubky, aby našly padouchy, kteří jsou již ve své síti., Příliš mnoho titulků na konferencích se pokusilo přesvědčit CISOs, že týmy elitních hackerů pro ně střílejí rarifikovanými 0denními exploity, které je nechají bezbrannými, pokud si nekoupí svůj produkt, který je nějakým způsobem učiní nedobytnými k těmto jinak nezastavitelným útokům.

tento pohled na stav bezpečnosti je zbytečně fatalistický, kape marketingovým humbukem a postrádá některé základní pojmy o tom, jak by bezpečnostní odborníci měli přemýšlet o riziku.,

komplexní přístup k bezpečnosti by neměly kázat odstranění lidské vývojáři z procesu, jen aby v dodavatele bezpečnostních nástrojů pro opravu poté, co dokončil svou práci. To předpokládá, že vývojářům nelze důvěřovat, je urážlivé a nedělá nic pro to, aby byl váš tým silnější, pokud jde o bezpečnost a řízení rizik.

Co OWASP Top 10 Seznam Zranitelností Je A co Není

několikrát za rok je povinné blogu ptá, jak je možné, že v roce 2017 stále hovoříme o script kiddie úrovni útoků., Pravděpodobně jsem napsal několik z nich sám, za což se omlouvám.

OWASP Top 10 není nastaven tak, aby vyřešil každý útok v knize, ale aby pomohl týmům vyhnout se běžným chybám, u nichž je mnohem pravděpodobnější, že jejich aplikace budou porušeny. Odhodlaný útočník může najít mnoho cest, jak prolomit svůj cíl. Rady pro inteligentní řízení rizik se však nezaměřují na menšinu případů, ale místo toho se snaží řešit problémy, kterým čelí nejširší publikum.,

Chcete-li čerpat z konceptů oblasti fyzické bezpečnosti, průměrný manažer rizik by měl být mnohem více znepokojen tím, že se její klient dostane do nehody na silnici, než ninjové vyškolení Seal Team 6 procházející okny, vedeni AI (a blockchain).

skutečná bezpečnost je o školení lidí o tom, jak bezpečně pracovat a dát jim technologie, znalosti a procesy, aby jim usnadnilo zůstat v bezpečí., I když je vždy důležité, aby spustit QA a závěrečné bezpečnostní kontroly před vydáním, bezpečnosti musí začít v počátečních fázích, jak váš tým pracuje, běží v celém procesu vzniku výrobku. Chyby se stanou, ale je mnohem nákladově efektivnější a vyloženě chytřejší pokusit se vyhnout co největšímu počtu problémů.

pro mnoho vývojářů se hnací cíl soustředí na to, aby produkt fungoval, a zaměřuje se méně na to, zda je nebo není bezpečný. To není jejich chyba.,

během svého vzdělávání se dozvěděli, že pokud produkují produkt s minimálním množstvím chyb, pak dostali a.bezpečnost by stejně řešilo jiné oddělení. Místo toho musí manažeři využít příležitosti, aby jim ukázali lepší způsob práce, který zahrnuje zvážení toho, jak kódují, a komponenty, se kterými pracují, ovlivňují bezpečnost jejich produktu.,

získejte 451 report výzkumu o zabezpečení softwaru s otevřeným zdrojovým kódem Stáhněte si zdarma

praktické kroky umožňující lepší bezpečnostní postupy

společným úskalím, které vyšlo z dnů vývoje vodopádu, bylo počkat, až do konce vývojového cyklu provede bezpečnostní kontroly, kde vývojáři obdrží seznam chyb zabezpečení, které opraví, odloží uvolnění a zvýší tření mezi nimi a bezpečnostním týmem.,

V naději, že mazání ozubených kol a držet krok s rychlostí DevOps, organizace hledají nové způsoby, jak zajistit jejich kód od začátku a udržovat harmonii mezi jejich oddělení.

jedna stále populárnější metoda pro uvedení bezpečnosti do dřívějších fází vývoje produktu je v cross-opylovacích týmech se směsí vývojářů a bezpečnostních lidí, což umožňuje každé straně dát vstup a učit se od sebe navzájem., To může být vynikající příležitost pro bezpečnostní odborníky, aby vyvolali mnoho otázek, které se OWASP Top 10 pokouší řešit v méně konfrontačním prostředí, ve fázi, která by mohla mít skutečně dopad.

pokud jde o nástroje, které mohou pomoci podpořit lepší implementaci zabezpečení, musíme přemýšlet nejen o tom, jak technologie dokáže zachytit naše chyby nebo porušení po skutečnosti, ale pomůže nám pracovat chytřeji a bezpečněji od nejranějších fází., Tato perspektiva je nedílnou součástí mentality posunu doleva a hledá příležitosti k řešení problémů dříve, než se stanou drahými problémy.

integrace technologií pro rozšíření schopností vývojářů

jasný příklad toho, jak technologie pro posun doleva mohou vývojářům pomoci využít OWASP Top 10, přichází s položkou číslo 9, která varuje před použitím komponent se známými zranitelnostmi. Jedním z nejčastějších problémů, které vznikají v tomto prostoru, je získání viditelnosti nad tím, co je v součástech s otevřeným zdrojovým kódem, které přidali do svého produktu.,

vývojáři se téměř vždy obracejí na komponenty s otevřeným zdrojovým kódem, aby jim pomohli rychleji a efektivněji budovat svůj produkt a přidávat výkonné funkce bez nutnosti psát nový kód sami.

ve většině případů je nepravděpodobné, že by před přidáním do svého produktu zkontrolovali, zda má komponenta nějaké známé zranitelnosti. I když provedou zběžnou kontrolu, aby zjistili, zda má nějaké konkrétní problémy, je nepravděpodobné, že by si byli vědomi jakýchkoli problémů v závislostech komponenty.,

Nicméně, pokud jsou pomocí Software Složení nástroj pro Analýzu souborů, mohou skutečně získat užitečné informace o tom, zda open source komponent nějakou známou zranitelností s ním spojené v průběhu vývoje softwaru životního cyklu (SDLC), šetří jim čas, který by jinak strávil trhání a výměna komponent po kontrole z bezpečnostní tým později než vydání po byl spáchán na jejich kód.,

buďte aktivátorem zabezpečení ve vaší organizaci

na základě mého čtení komentářů OWASP Top 10 a Knobloch by měl být seznam považován za nástroj pro posílení zabezpečení týmů v jejich myšlenkovém procesu, jak kódují, konfigurují a odesílají své produkty.

bezpečnostní týmy, které se nezabývají svými vývojáři a snaží se pochopit, jak jim mohou umožnit, aby bezpečnost byla neodmyslitelným prvkem jejich pracovního postupu, se rychle ocitnou stranou.,

Pokud chcete zůstat relevantní, Staňte se aktivátorem a použijte seznam OWASP Top 10 jako způsob, jak zahájit konverzace, neohrožovat. Nakonec můžete zjistit, že chytíte více (o) vosy s medem než octem.

oficiální seznam zranitelností OWASP Top 10

A1. K chybám vstřikování injekce, jako je injekce SQL, NoSQL, OS a LDAP, dochází, když jsou nedůvěryhodná data odeslána tlumočníkovi jako součást příkazu nebo dotazu. Nepřátelská data útočníka mohou tlumočníka přimět k provádění neúmyslných příkazů nebo přístupu k datům bez řádného oprávnění.

A2., Broken Authentication – Aplikace, funkce, vztahující se k ověřování totožnosti a řízení relací, jsou často provedena nesprávně, která útočníkům umožňuje kompromitovat hesla, klíče nebo session tokeny, nebo využít jiné provedení nedostatky předpokládat jiných uživatelů identity dočasně nebo trvale.

A3. Expozice citlivých dat – mnoho webových aplikací a API řádně nechrání citlivá data, jako jsou finanční, zdravotní péče a PII. Útočníci mohou tyto slabě chráněné údaje ukrást nebo upravit, aby mohli provádět podvody s kreditními kartami, krádež identity nebo jiné trestné činy., Citlivá data mohou být ohrožena bez další ochrany, jako je šifrování v klidu nebo v tranzitu, a vyžaduje zvláštní opatření při výměně s prohlížečem.

A4. XML externí entity ( XXE) – mnoho starších nebo špatně nakonfigurovaných procesorů XML vyhodnocuje odkazy externích entit v dokumentech XML. Externí subjekty mohou být použity k odhalení Interních souborů pomocí obslužného programu URI, sdílení Interních souborů, skenování Interních portů, vzdálené spuštění kódu a útoků odmítnutí služby.

A5.,Broken access Controls-omezení toho, co mohou ověřovaní uživatelé dělat, často nejsou řádně vynucena. Útočníci mohou tyto nedostatky využít pro přístup k neoprávněným funkcím a/nebo datům, přístup k účtům jiných uživatelů, prohlížení citlivých souborů, úpravu dat ostatních uživatelů, změnu přístupových práv atd.

A6. Bezpečnostní Misconfiguration – bezpečnostní misconfiguration je nejčastěji vidět problém., To je obvykle výsledkem nezabezpečených výchozích konfigurací, neúplných nebo Ad hoc konfigurací, otevřeného cloudového úložiště, nesprávně nakonfigurovaných záhlaví HTTP a podrobných chybových zpráv obsahujících citlivé informace. Nejen, že musí být všechny operační systémy, rámce, knihovny a aplikace bezpečně nakonfigurovány, ale musí být včas opraveny/upgradovány.

A7.,Cross Site Scripting (XXS) – XSS chyby dojít, kdykoli aplikace obsahuje nedůvěryhodných dat do nové webové stránky bez řádného ověření nebo escapování, nebo aktualizace existující webové stránky s uživatelsky zadané údaje pomocí prohlížeče rozhraní API, které můžete vytvořit HTML nebo JavaScript. XSS umožňuje útočníkům spouštět skripty v prohlížeči oběti, které mohou unést uživatelské relace, deface webové stránky, nebo přesměrovat uživatele na škodlivé weby.

A8. Nejistá Deserializace-nejistá deserializace často vede k vzdálené spuštění kódu., I když chyby deserializace nevedou k provedení vzdáleného kódu, mohou být použity k provádění útoků, včetně replay útoků, injekčních útoků a útoků na eskalaci privilegií.

A9. Použití komponent se známými zranitelnostmi-komponenty, jako jsou knihovny, rámce a další softwarové moduly, běží se stejnými oprávněními jako aplikace. Pokud je zranitelná složka využívána, může takový útok usnadnit vážnou ztrátu dat nebo převzetí serveru., Aplikace a API používající komponenty se známými zranitelnostmi mohou narušit obranu aplikací a umožnit různé útoky a dopady.

A10. Nedostatečné Protokolování & Sledování – Nedostatečné protokolování a sledování, spolu s chybějící nebo neúčinná integrace s incident response umožňuje útočníkům k dalšímu útoku systémy, udržovat vytrvalost, pivot na více systémů, a tamper, extrakt, nebo zničit data., Většina studií porušení ukazuje, že čas na zjištění porušení je více než 200 dní, obvykle detekován externími stranami spíše než interními procesy nebo monitorováním.

Leave a Comment