Skener webu

Co zjišťujeme?

A1 - Chyba zabezpečení řízení přístupu (Broken Access Control)

Řízení přístupu je důležité k tomu, aby uživatelé měli taková oprávnění, která mají mít. Aby například běžný uživatel neměl oprávnění správce serveru a nemohl přistupovat ke stránkám, ke kterým by neměl mít přístup. Špatné nastavení může způsobit neoprávněné zveřejnění informací, úpravu nebo zničení všech dat.

Mezi běžné chyby zabezpečení řízení přístupu patří:

Špatné nastavení oprávnění, kdy přístup na stránku je udělen všem uživatelům, místo konkrétnímu uživateli. Například stránka pro změnu oprávnění by měla být přístupná pouze administrátorovi stránky. V případě, že by oprávnění měli i běžní uživatelé, můžou se po zadání konkrétní URL dostat na administrátorské stránky, kam by přístup mít neměli.

Vynechání kontroly řízení přístupu při upravování adresy URL (neoprávněná manipulace s parametry), interního stavu aplikace nebo stránky HTML nebo pomocí nástroje pro útok upravující požadavky rozhraní API.

Možné zobrazení nebo úpravy jiného uživatele zadáním jeho jedinečného identifikátoru (nezabezpečené přímé odkazy na objekt).

Přístup do aplikačního rozhraní se špatně nastavenými metodami řízením přístupu pro POST, PUT a DELETE.

Chováte se na stránce jako uživatel, aniž byste byli přihlášeni, nebo jednáte jako správce, když jste přihlášeni jako uživatel.

Manipulace s metadaty, jako je manipulace s tokenem řízení přístupu JSON Web Token (JWT) nebo se souborem cookie nebo skrytým polem manipulovaným za účelem zvýšení oprávnění nebo zneužití zrušení platnosti JWT.

Nesprávná konfigurace CORS umožňuje přístup k API z neautorizovaných/nedůvěryhodných zdrojů

Jak mohu předejít „Špatnému zabezpečení řízení přístupu“?

Řízení přístupu je účinné pouze v důvěryhodném kódu na straně serveru nebo rozhraní API bez serveru, kde útočník nemůže upravit kontrolu řízení přístupu nebo metadata.

Naimplementované mechanismy řízení přístupu se používají v celé aplikaci.
Deaktivovat procházení adresářové struktury webového serveru a zajistíte, aby se metadata souborů (např. .git) a záložní soubory nenacházely ve webových kořenových adresářích.
Logovat a monitorovat špatné pokusy o přihlášení, v případě potřeby upozornit administrátory (např. opakovaná selhání).
Omezit přístup k rozhraní API v případě opakovaného špatného pokusu o přihlášení, aby se minimalizovaly případné pokusy například bruteforce nástroji pro automatizované útoky.
ID session by měly být na serveru po odhlášení zrušeny. Tokeny JWT by měly být spíše krátkodobé, aby se minimalizovaly příležitosti pro útočníka. U déle žijících JWT se důrazně doporučuje dodržovat standardy OAuth.

Příklady možných útoků

Scénář #1: Aplikace neověřuje data zadaná například do SQL, se kterými přistupuje k informacím o účtu:
pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
Útočník jednoduše upraví parametr „acct“ prohlížeče tak, aby odeslal jakékoli číslo účtu, které chce. Pokud není správně ošetřen vstupní parametr, může útočník získat přístup k účtu libovolného uživatele.
https://example.com/app/accountInfo?acct=notmyacct

Scénář #2: Útočník jednoduše zadá konkrétní URL adresu. Přístup na stránku správce by měl být možný pouze po přihlášení.
https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
Pokud má nepřihlášený uživatel přístup na některou stránku, je to chyba.

Odkazy

OWASP:

Externí:

A2 - Kryptografická selhání (Cryptographic Failures)

Přenos citlivých dat je kritická oblast a je velice důležité ji zabezpečit tak, aby útočník nemohl odchytit a přečíst posílaná citlivá data. Například hesla, čísla kreditních karet, zdravotní záznamy, osobní údaje a obchodní tajemství vyžadují zvláštní ochranu, zejména pokud tato data spadají pod zákony na ochranu soukromí, např. obecné nařízení EU o ochraně osobních údajů (GDPR), nebo nařízení, např. ochrana finančních údajů, jako je PCI Data Security Standard (PCI DSS).

Pro všechny výše zmíněné údaje je důležité si položit následující otázky:

Jsou nějaká data přenášena v čistém textu? Týká se to protokolů jako HTTP, SMTP, FTP.

Používají se ve výchozím nastavení nebo ve starším kódu nějaké staré nebo slabé kryptografické algoritmy nebo protokoly?

Používají se výchozí šifrovací klíče, generují se nebo se znovu používají slabé šifrovací klíče nebo chybí správná správa klíčů?

Chybí přesměrování na HTTPS, chybí nějaké bezpečnostní HTTP hlavičky?

Je certifikát serveru důvěryhodný?

Používají se zastaralé hašovací funkce, jako je MD5 nebo SHA1, nebo se používají nekryptografické hašovací funkce, když jsou potřeba kryptografické hašovací funkce?

Používají se zastaralé metody šifrování, jako je PCKS číslo 1 v1.5?

Jsou kryptografické chybové zprávy nebo informace postranního kanálu zneužitelné, například ve formě útoků „padding oracle“?

Jak mohu předejít „Kryptografickému selhání“?

Hlavním doporučením pro organizaci je to, aby se zaměřila minimálně na následující kroky:

Zjistěte, jaká data vaše webová aplikace zpracovává, ukládá nebo přenáší. Identifikujte, která data jsou citlivá podle zákonů na ochranu soukromí, regulačních požadavků nebo obchodních potřeb.
Neukládejte zbytečně citlivá data. Zvažte, která citlivá data je třeba ukládat a která ne. Data, která nejsou uchována, nemohou být odcizena.
Ujistěte se, že máte šifrována všechna citlivá data.
Pravidelně kontrolujte, že jsou zavedeny aktuální a silné standardní algoritmy, protokoly a klíče.
Šifrujte všechna data při přenosu pomocí zabezpečených protokolů, jako je TLS se šiframi FS (Forward secrecy). Používejte bezpečnostní hlavičku Strict Transport Security (HSTS).
Zakažte ukládání do mezipaměti pro ty odpovědi, které obsahují citlivá data.
Nepoužívejte protokoly FTP a SMTP pro posílání citlivých dat.
Ukládejte hesla pomocí silných adaptivních a osolených hashovacích funkcí jako je Argon2, scrypt, bcrypt nebo PBKDF2.
Klíče by měly být generovány kryptograficky náhodně a uloženy v paměti jako bajtová pole. Pokud je použito heslo, musí být převedeno na klíč pomocí vhodné funkce.
Zajistěte, aby se tam, kde je to vhodné, použila kryptografická náhodnost.

Příklady možných útoků

Scénář č. 1: Aplikace šifruje čísla kreditních karet v databázi pomocí automatického šifrování databáze. Tato data jsou však při načtení automaticky dešifrována, což v případě úspěšného SQL útoku může vést k odcizení čísel kreditních karet v čitelné podobě.

Scénář č. 2: Web nepoužívá ani nevynucuje TLS pro všechny stránky nebo podporuje slabé šifrování. Útočník monitorující síťový provoz (např. v nezabezpečené bezdrátové síti), může přesměrovat připojení z HTTPS na HTTP, zachytit požadavky a ukradnout cookie relace uživatele. Útočník pak může využít ukradenou cookie k tomu, aby získal uživatelskou (ověřenou) relaci. Může tak získat přístup k soukromým datům uživatele.

Scénář č. 3: Databáze hesel používá slabé hashe k ukládání hesel. Chyba při nahrávání souboru umožňuje útočníkovi získat databázi hesel. Všechny neosolené hashe lze prolomit pomocí duhové tabulky předem vypočítaných hashů. Hashe generované jednoduchými nebo rychlými hashovacími funkcemi mohou být prolomeny GPU, i když byly osolené.

Odkazy

OWASP:

Externí:

A3 - Injektování (Injection)

Aplikace je zranitelná vůči útoku, když:

Data zadaná uživatelem nejsou aplikací ověřena či filtrována.
Přímo v překladači se používají dynamické dotazy nebo neparametrizovaná volání bez kontextového escapování.
Data se používají v rámci vyhledávacích parametrů objektově relačního mapování (ORM) k extrahování dalších citlivých záznamů.

Některé z běžnějších injekcí jsou SQL, NoSQL, OS příkaz, Object Relational Mapping (ORM), LDAP a Expression Language (EL) nebo Object Graph Navigation Library (OGNL). Koncept je u všech interpretů stejný. Kontrola zdrojového kódu je nejlepší metodou jak zjistit, zda jsou aplikace zranitelné vůči tomuto typu útoku. Důrazně se doporučuje automatizované testování všech parametrů, záhlaví, URL, souborů cookie, datových vstupů JSON, SOAP a XML.

Jak tomu mohu předejít

Zabránění vkládání vyžaduje uchovávat data odděleně od příkazů a dotazů:

Jednou z možností je použití bezpečného API, které se zcela vyhýbá použití interpretu, poskytuje parametrizované rozhraní nebo migruje na nástroje Object Relational Mapping Tools (ORM).
Poznámka: I když jsou uložené procedury parametrizované, mohou stále zavádět vkládání SQL, pokud PL/SQL nebo T-SQL zřetězí dotazy a data nebo spouští data pomocí EXECUTE IMMEDIATE nebo exec().
Použijte ověřovací mechanismy vstupu na straně serveru. Toto není úplná obrana, protože mnoho aplikací vyžaduje speciální strukturu, jako jsou textové oblasti nebo API pro mobilní aplikace.
U všech ostatních dynamických dotazů escapujte speciální znaky pomocí specifické syntaxe escape pro daný interpret.
Poznámka: Struktury SQL, jako jsou názvy tabulek, názvy sloupců atd., nelze escapovat, a proto jsou názvy struktur zadané uživatelem nebezpečné. Toto je běžný problém v softwaru pro psaní zpráv.
Používejte LIMIT a další ovládací prvky SQL v dotazech, abyste zabránili hromadnému zveřejnění záznamů v případě úspěšného útoku SQL injection.

Příklady možných útoků

Scénář #1: Aplikace používá nedůvěryhodná data při konstrukci následujícího zranitelného volání SQL:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + " ' ";

Scénář č. 2: Podobně slepá důvěra aplikace v rámce může mít za následek dotazy, které jsou stále zranitelné (např. Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID=' " + request.getParameter("id") + " ' ");

V obou případech útočník upraví hodnotu parametru 'id' ve svém prohlížeči tak, aby odeslala: ' nebo '1'='1. Například: http://example.com/app/accountView?id=' nebo '1'='1 Tím se změní význam obou dotazů a vrátí se všechny záznamy z tabulky účtů. Nebezpečnější útoky by mohly upravit nebo odstranit data.

Odkazy

OWASP:

Externí:

A4 - Nezabezpečený design (Insecure Design)

Nezabezpečený design je široká kategorie představující různé slabiny vyjádřené jako „chybějící nebo neefektivní návrh kontroly“. Nezabezpečený design není zdrojem všech ostatních 10 hlavních rizikových kategorií. Důležité je zmínit, že je rozdíl mezi nezabezpečeným návrhem a nezabezpečenou implementací. Chyby v návrhu a implementační vady rozlišujeme z nějakého důvodu, mají různé základní příčiny a způsoby nápravy. Bezpečný návrh může mít stále chyby implementace vedoucí ke zranitelnostem, které lze zneužít. Nezabezpečený návrh nelze opravit dokonalou implementací, protože potřebné bezpečnostní kontroly nebyly nikdy vytvořeny k obraně proti konkrétním útokům. Jedním z faktorů, které přispívají k nezabezpečenému návrhu, je chybějící profilování obchodních rizik vlastního vyvíjeného softwaru nebo systému, a tedy neschopnost určit, jaká úroveň návrhu zabezpečení je požadována.

Požadavky a řízení zdrojů

Shromažďovat a vyjednávat obchodní požadavky na aplikaci s firmou, včetně požadavků na ochranu týkajících se důvěryhodnosti, integrity, dostupnosti a pravosti všech datových aktiv a očekávané obchodní logiky. Vezměte v úvahu, do jaké míry bude vaše aplikace vystavena. Sestavte technické požadavky včetně požadavků na funkční a nefunkční zabezpečení. Plánujte rozpočet pokrývající veškerý návrh, sestavení, testování a provoz, včetně bezpečnostních činností.

Bezpečný Design

„Secure design“ je kultura a metodika, která neustále vyhodnocuje hrozby a zajišťuje, že kód je robustně navržen a testován tak, aby zabránil známým metodám útoku. Při vývoji uživatelského příběhu je důležité určit správný tok dat, včetně poruch. Zajistit, aby byly dobře pochopeny a schváleny odpovědnými a dotčenými stranami. Určit, jak ověřit předpoklady a prosadit podmínky potřebné pro správné chování. Zajistit, aby byly výsledky zdokumentovány. Učit se z chyb a nabídnout pozitivní pobídky ke zlepšení. Zabezpečený design není ani doplněk, ani nástroj, který se může přidat do softwaru.

Životní cyklus bezpečného vývoje

Zabezpečený software vyžaduje bezpečný životní cyklus vývoje, určitou formu bezpečného návrhového vzoru, zabezpečenou knihovnu komponent. Je důležité oslovit své bezpečnostní specialisty na začátku vývoje softwarového projektu a komunikovat s nimi během celého projektu a také během údržby. Zvážit využití modelu OWASP Software Assurance Maturity Model (SAMM).

Jak mohu předejít „Nezabezpečenému designu“?

Vytvořte a používejte bezpečný životní cyklus vývoje s profesionály AppSec, abyste pomohli vyhodnotit a navrhnout zabezpečené ovládací prvky související s ochranou soukromí.
Vytvořte a používejte knihovnu podle bezpečných návrhových vzorů a berte v potaz zpětnou vazbu.
Využijte modelování hrozeb pro kritickou autentizaci nebo řízení přístupu.
Integrujte kontroly na každé úrovni své aplikace (od frontendu po backend).

Příklady možných útoků

Scénář č. 1: Pracovní postup obnovy účtu může zahrnovat „otázky a odpovědi“, což není doporučeno standardy NIST 800-63b, OWASP ASVS a OWASP Top 10. Otázky a odpovědi nelze považovat za bezpečné prokázání identity. Na otázky může odpovědět i někdo jiný, než oprávněný uživatel. Takový kód by měl být odstraněn a nahrazen bezpečnějším designem.

Scénář č. 2: Řetězec kin umožňuje slevy na skupinové rezervace a má maximálně patnáct účastníků, než bude požadována záloha. Útočníci by mohli zkusit zneužít model tohoto designu a vyzkoušet, zda dokážou zarezervovat šest set míst a všechna kina najednou v několika žádostech, což by způsobilo masivní ztrátu příjmů.

Odkazy

OWASP:

Externí:

A5 - Nezabezpečená konfigurace (Security Misconfiguration)

Zranitelnost umožňující napadení využitím nedostatků v zabezpečení konfigurací aplikačních serverů, webových serverů, databázových serverů, softwarových platforem atd., a to např. ponecháním výchozích hodnot, neprovedením aktualizací aj.

Znalosti zranitelností serverů mohou ohrozit provozovatele serveru anebo ostatní provozovatele webů, kteří hostují na témže serveru. Proto jestliže nejste provozovatelem serveru, kde je webová aplikace hostována, zjištěné slabiny vám můžeme sdělit pouze po svolení provozovatele serveru, a to pouze v případě, že tímto sdělením nebude ohrožen jiný provozovatel webu.

Jsem zranitelný vůči „nezabezpečené konfiguraci“?

Aplikace může být zranitelná, pokud:

Jsou povoleny nebo instalovány nepotřebné funkce (např. nepotřebné porty, služby, stránky, účty nebo oprávnění).
Výchozí účty a jejich hesla jsou stále aktivní a beze změny.
Zpracování chyb odhaluje uživatelům trasování zásobníku nebo jiné příliš informativní chybové zprávy.
U upgradovaných systémů jsou nejnovější funkce zabezpečení deaktivovány nebo nejsou správně nakonfigurovány.
Nastavení zabezpečení na aplikačních serverech, aplikačních frameworkách (např. Struts, Spring, ASP.NET), knihovnách, databázích atd. nejsou nastaveny bezpečné hodnoty.
Na serveru nejsou správně nastaveny bezpečnostní hlavičky.

Bez koordinovaného a opakovatelného procesu konfigurace zabezpečení aplikací jsou systémy vystaveny vyššímu riziku.

Jak mohu předejít „nezabezpečené konfiguraci“?

Měly by být implementovány procesy bezpečné instalace včetně:

Platformy pouze s funkcemi, které jsou pro daný web potřebné, bez jakýchkoli zbytečných funkcí, komponent, dokumentace a vzorků. Odeberte nebo neinstalujte nepoužívané funkce a frameworky.
Pravidelné kontroly konfigurací. Je důležité kontrolovat, jestli náš systém nemá volně přístupné konfigurační soubory. Správnou konfigurací také zajistíme to, že nebudeme zbytečně zobrazovat verzi, na které běží náš server.
Odesílání bezpečnostních direktiv klientům, např. Security Headers.
Automatizovaný proces pro ověření účinnosti konfigurací a nastavení ve všech prostředích.

Příklady možných útoků

Scénář č. 1: Aplikační server je dodáván s ukázkovými aplikacemi, které nebyly odstraněny z produkčního serveru. Tyto ukázkové aplikace mají známé bezpečnostní chyby, které útočníci můžou použít ke kompromitaci serveru. Předpokládejme, že jednou z těchto aplikací je administrátorská konzole a výchozí účty, které nebyly změněny. V takovém případě se útočník přihlásí pomocí výchozích hesel a převezme kontrolu nad účtem, případně nad celým webem.

Scénář č. 2: Výpis adresářů není na serveru zakázán. Útočník může zjistit, jaké adresáře se na serveru nacházejí. Útočník může najít a stáhnout zkompilované třídy Java, které následně dekompiluje a analyzuje. Útočník pak v aplikaci může najít závažnou chybu řízení přístupu.

Scénář č. 3: Špatná konfigurace aplikačního serveru může zobrazit uživatelům podrobné chybové zprávy, např. trasování zásobníku či verze systémů. To může odhalit citlivé informace nebo základní chyby, jako jsou verze komponent. V případě, že na serveru jsou neaktualizované komponenty, může útočník využít případné kritické zranitelnosti.

Scénář č. 4: Poskytovatel cloudových služeb (CSP) má výchozí oprávnění ke sdílení otevřená na internetu jinými uživateli CSP. To umožňuje přístup k citlivým datům uloženým v cloudovém úložišti.

Odkazy

OWASP:

Externí:

A6 - Zranitelné a zastaralé komponenty (Vulnerable and Outdated Components)

Zranitelnosti umožňující napadení neaktualizovaných komponent.

Jsem zranitelný vůči „expozici citlivých dat“?

Pravděpodobně jste zranitelní, pokud:

Nemáte aktualizované verze všech komponent, které používáte (jak na straně klienta, tak na straně serveru).
Software je zranitelný, nepodporovaný nebo zastaralý. To zahrnuje OS, webový/aplikační server, systém správy databází (DBMS), aplikace, API a všechny komponenty, runtime prostředí a knihovny.
Pravidelně a včas neupgradujete základní platformu, frameworky.
Vývojáři softwaru netestují kompatibilitu aktualizovaných, upgradovaných nebo opravených knihoven.
Nezabezpečíte konfigurace součástí (viz A05:2021 – Nesprávná konfigurace zabezpečení).

Jak mohu předejít „Zranitelným a zastaralým komponentům “?

Měl by existovat proces správy záplat:

Odstranit nepotřebné funkce a soubory.
Průběžná inventarizace verzí komponent na straně klienta i serveru (např. frameworků, knihoven) a jejich závislostí pomocí speciálních nástrojů. Nepřetržitě sledujte bezpečnostní novinky na platformě a frameworku, který používáte. Přihlaste se k odběru e-mailových upozornění na chyby zabezpečení související s komponentami, které používáte.
Součásti získávejte pouze z oficiálních zdrojů přes zabezpečené odkazy. Upřednostňujte podepsané balíčky, abyste snížili pravděpodobnost stažení upravené, či škodlivé verze frameworku (viz A08:2021-Selhání integrity softwaru a dat).
Monitorujte knihovny a komponenty, které nejsou již podporovány nebo nevytvářejí bezpečnostní záplaty pro starší verze.

Příklady možných útoků

Scénář č. 1: Komponenty obvykle běží se stejnými oprávněními jako samotná aplikace, takže chyby v jakékoli komponentě mohou mít vážný dopad. Takové chyby mohou být náhodné (např. chyba v kódu) nebo záměrné (např. zadní vrátka v komponentě). Některé příklady zjištěných zneužitelných zranitelností součástí: • CVE-2017-5638, zranitelnost vzdáleného spuštění kódu Struts 2, která umožňuje spouštění libovolného kódu na serveru.

Zatímco (IoT) je často obtížné nebo nemožné záplatovat. Existují automatizované nástroje, které útočníkům pomohou najít neopravené nebo špatně nakonfigurované systémy. Například vyhledávač Shodan IoT vám může pomoci najít zařízení, která stále trpí zranitelností Heartbleed opravenou v dubnu 2014.

Odkazy

OWASP:

Externí:

A7 - Selhání Identifikace a Autentizace (Identification and Authentication Failures)

Potvrzení identity uživatele, autentizace a správa relací je zásadní pro ochranu před útoky souvisejícími s autentizací. Ověření může být slabé, pokud aplikace:

Umožňuje útoky hrubou sílu (bruteforce) nebo jiné automatizované útoky.
Povoluje výchozí, slabá nebo dobře známá hesla, jako je „Heslo1“ nebo „admin/admin“.
Používá slabé nebo neefektivní postupy při obnově zapomenutého hesla, jako jsou „odpovědi založené na znalostech“, které nelze zabezpečit.
Používá nezašifrovaná, případně slabě zašifrovaná nebo slabě hašovaná úložiště dat hesel (viz A02:2021 – Cryptographic Failures).
Chybí nebo je neúčinné vícefaktorové ověřování.
Ukazuje identifikátor relace v URL.
Po úspěšném přihlášení znovu použije stejný identifikátor relace.
Správně neruší platnost ID relace. Uživatelské relace nebo ověřovací tokeny (hlavně tokeny jednotného přihlášení (SSO)) nejsou správně znehodnoceny během odhlášení nebo období nečinnosti.

Jak mohu předejít „Selhání Identifikace a Autentizace“?

Kde to je možné, implementujte vícefaktorovou autentizaci, abyste zabránili útokům hrubou silou a útokům, které využívají ukradených přihlašovacích údajů z jiné webové aplikace.
Nepoužívejte výchozí účty, zejména pro administrátory.
Implementujte kontroly slabých hesel, například testování nových nebo změněných hesel podle seznamu 10 000 nejhorších hesel.
Porovnávejte zásady délky, složitosti a rotace hesla s pokyny Národního institutu pro standardy a technologie (NIST) 800-63b v části 5.1.1.
Nastavte dočasné zablokování účtu po pár neúspěšných pokusech. V případě opakovaného zablokování upozorněte administrátory.
Použijte zabezpečený správce relací na straně serveru, který po přihlášení generuje nové náhodné ID relace s vysokou entropií. Identifikátor relace by neměl být v adrese URL, měl by být bezpečně uložen a po odhlášení nebo nečinnosti zrušen.

Příklady možných útoků

Scénář č. 1: Takzvaný „credential stuffing“, používání seznamů známých hesel, při pokusu o kompromitování hesel. Někteří uživatelé používají stejné přihlašovací údaje pro více služeb, a když se útočníkům podaří sehnat přihlašovací údaje z jiné služby, mohou zkusit i na další služby a tak se dostat na účet vaší služby.

Scénář č. 2: K útokům, které se snaží obejít autentizaci, dochází v důsledku absence vícefaktorového ověřování. Dříve se doporučovalo jako nejlepší praktiky rotace hesel, složitá hesla atd. Dle nejnovějšího OWASP 10 se doporučuje spíše používat vícefaktorové ověřování.

Scénář č. 3: Časové limity správy sezení aplikací nejsou správně nastaveny. Uživatel používá k přístupu k aplikaci veřejný počítač. Místo výběru „odhlásit“ uživatel jednoduše zavře kartu prohlížeče a odejde. Útočník použije stejný prohlížeč o hodinu později a uživatel je stále přihlášen.

Odkazy

OWASP:

Externí:

A8 - Selhání integrity softwaru a dat (Software and Data Integrity Failures)

Selhání integrity softwaru a dat se týkají kódu a infrastruktury a nastává v případě, kdy aplikace spoléhá na pluginy, knihovny nebo moduly z nedůvěryhodných zdrojů a úložišť. Nezabezpečený kanál CI/CD představuje bezpečnostní riziko, kdy hrozí, že knihovny a pluginy z nedůvěryhodných zdrojů můžou obsahovat backdoory a způsobit neoprávněný přístup, nahrání škodlivého kódu nebo kompromitaci systému. A konečně, mnoho aplikací nyní obsahuje funkci automatických aktualizací, kdy se aktualizace stahují bez dostatečného ověření integrity a aplikují se na dříve důvěryhodnou aplikaci. Útočníci by potenciálně mohli nahrát své vlastní aktualizace, které budou distribuovány a spuštěny na všech instalacích. Dalším příkladem je situace, kdy jsou data zakódována nebo serializována do struktury, kterou útočník vidí, kterou může upravit a která je zranitelná vůči nezabezpečené deserializaci.

Jak mohu předejít "Selhání integrity softwaru a dat"?

Používejte digitální podpisy nebo podobné mechanismy k ověření, že software nebo data pocházejí z oficiálního zdroje a nebyly změněny.
Ujistěte se, že vaše frameworky a knihovny neobsahují žádnou známou zranitelnost, využít můžete například nástroje jako jsou „OWASP Dependency Check“ nebo „OWASP CycloneDX“.
Ujistěte se, že máte zavedený proces na přezkoumání u kódu a konfigurace po jejich změnách, abyste minimalizovali rizika vzniku nové kritické zranitelnosti.
Ujistěte se, že nepodepsaná nebo nezašifrovaná serializovaná data nejsou odesílána nedůvěryhodným klientům bez určité formy kontroly integrity nebo digitálního podpisu k detekci manipulace nebo přehrání serializovaných dat.

Příklady možných útoků

Scénář č. 1 Aktualizace bez podpisu: Mnoho domácích routerů, set-top boxů, firmware zařízení a dalších neověřuje aktualizace prostřednictvím podepsaného firmwaru. Nepodepsaný firmware je rostoucím cílem útočníků a očekává se, že se to bude jen zhoršovat.

Scénář č. 2 Škodlivá aktualizace SolarWinds: Je známo, že útočníci vyhledávají neaktuální systémy, přičemž nedávným pozoruhodným útokem byl útok SolarWinds Orion. Společnost, která vyvíjí software, měla zabezpečené procesy integrity sestavení a aktualizace. Přesto se je podařilo kompromitovat a firma několik měsíců distribuovala škodlivou aktualizaci více než 18 000 organizacím, z nichž asi 100 bylo postiženo. Jde o jedno z nejdalekosáhlejších a nejvýznamnějších porušení této povahy v historii.

Odkazy

OWASP:

Externí:

A9 - Nedostatečné bezpečnostní logování a monitorování (Security Logging and Monitoring Failures)

OWASP Top 10 2021 jako kategorie má pomáhat odhalovat a eskalovat aktivní porušení a reagovat na ně. Bez logů a monitorování nelze tyto hrozby detekovat. K nedostatečnému ukládání logů, detekci, monitorování a aktivní reakci dochází z důvodů:

Události, jako jsou přihlášení, neúspěšná přihlášení a transakce s vysokou hodnotou, nejsou uloženy do logů.
Varování a chyby nevytváří žádné nebo vytváří nečitelné logy.
Logy aplikací a rozhraní API nejsou sledovány ani v případě, že jsou dobře zaznamenávány.
Logy se ukládají pouze lokálně.
Penetrační testování a skenování pomocí automatických nástrojů pro testování zabezpečení aplikací (DAST) (jako je OWASP ZAP) nespouštějí výstrahy a administrátoři o nich nevědí.
Aplikace nemůže detekovat, eskalovat nebo upozorňovat na aktivní útoky v reálném čase nebo téměř v reálném čase.

Jste zranitelní vůči úniku informací tím, že zpřístupníte logy a upozornění pro uživatele nebo útočníka (viz A01:2021-Broken Access Control).

Jak mohu předejít „Nedostatečnému bezpečnostní logování a monitorování“?

Vývojáři by měli implementovat některé nebo všechny následující ovládací prvky v závislosti na riziku aplikace:

Zajistěte, aby všechna neúspěšná přihlášení a ověření vstupních údajů na straně serveru mohla být správně logována s dostatečným uživatelským kontextem, aby bylo možné identifikovat podezřelé nebo kompromitované účty a zálohujte je dostatečně dlouhou dobu, aby byla umožněna případná budoucí forenzní analýza.
Zajistěte, aby byly logy generovány ve formátu, který je dobře čitelný.
Existují komerční a open-source rámce ochrany aplikací, jako je sada základních pravidel OWASP ModSecurity open source software pro korelaci protokolů - ELK stack (Elasticsearch, Logstash, Kibana), které obsahují vlastní řídicí panely a upozornění.
Ujistěte se, že logy jsou správně zakódovány, aby se zabránilo útokům injektování nebo útokům na systémy logování a monitorování.
Zajistěte, aby transakce s vysokou hodnotou měly auditní záznam s kontrolami integrity, aby se případně odhalila manipulace s databázovými tabulkami nebo jejich odstranění.
Bezpečnostní oddělení by mělo zavést monitorování a získávat upozornění, aby bylo možné sledovat podezřelé aktivity a v případě potřeby na ně rychle reagovat.
Vytvořte případný reakční plán pro incidenty a obnovu dat, jako je National Institute of Standards and Technology (NIST) 800-61r2 nebo novější.

Příklady možných útoků

Scénář č. 1: Provozovatel webových stránek poskytovatele zdravotní péče pro děti neměl správně nastavenou detekci a logování útoků. Externí strana informovala poskytovatele webových stránek, že útočník zpřístupnil a upravil tisíce citlivých zdravotních záznamů více než 3,5 milionu dětí. Kontrola po incidentu zjistila, že vývojáři webových stránek neřešili významná zranitelná místa. Vzhledem k tomu, že nedocházelo k žádnému logování ani monitorování systému, mohlo narušení dat probíhat již od roku 2013, tedy období více než sedmi let.

Scénář č. 2: Od velké evropské letecké společnosti údajně útočníci získali díky bezpečnostní zranitelnosti platební brány více než 400 000 záznamů o platbách zákazníků. Letecká společnost v důsledku toho dostala pokutu 20 milionů liber.

Odkazy

OWASP:

Externí:

A10 - Server-Side Request Forgery (SSRF)

K chybám SSRF dochází vždy, když webová aplikace načítá vzdálený zdroj, aniž by ověřovala uživatelem zadanou adresu URL. To umožňuje útočníkovi přinutit aplikaci, aby odeslala vytvořený požadavek do nečekaného cíle, i když je chráněn firewallem, VPN nebo jiným typem seznamu řízení přístupu k síti (ACL).

Protože moderní webové aplikace poskytují koncovým uživatelům pohodlné funkce, stává se načítání adresy URL běžným scénářem. V důsledku toho se zvyšuje výskyt SSRF. Také závažnost SSRF je stále vyšší kvůli cloudovým službám a složitosti architektur.

Jak mohu předejít „SSRF“?

Vývojáři mohou zabránit SSRF implementací některých nebo všech následujících zmíněných kontrol:

Síťová vrstva

Segmentujte funkce vzdáleného přístupu ke zdrojům v samostatných sítích, abyste snížili dopad SSRF.
Nastavte pravidla brány firewall „ve výchozím nastavení odepřít“ nebo pravidla řízení přístupu k síti k blokování veškerého intranetového provozu kromě nezbytného.
Tipy:
~ Nastavte vlastnictví a životní cyklus pravidel brány firewall na základě aplikací.
~ Zaznamenávejte všechny přijaté a blokované síťové toky na bránách firewall (viz A09:2021-Security Logging and Monitoring Failures).

Aplikační vrstva:

Ošetřete a kontrolujte všechna data zadaná uživateli.
Neposílejte uživatelům nezpracované odpovědi.
Zablokujte HTTP přesměrování.

Příklady možných útoků

Útočníci mohou pomocí SSRF zaútočit na systémy chráněné za firewally webových aplikací, firewally nebo síťové kontrolní seznamy, jako jsou:

Scénář č. 1: Skenování portů interních serverů – Pokud síťová architektura není segmentovaná, útočníci mohou zmapovat vnitřní sítě a určit, zda jsou porty na interních serverech otevřené nebo zavřené.

Scénář č. 2: Vystavení citlivých dat – Útočníci mohou přistupovat k místním souborům, jako jsou interní služby, a získat tak citlivé informace, jako jsou file:///etc/passwd</span> a http://localhost:28017/.

Scénář č. 3: Přístup k úložišti metadat cloudových služeb – Většina poskytovatelů cloudu má úložiště metadat, jako je http://169.254.169.254/. Útočník může číst metadata, aby získal citlivé informace.

Scénář č. 4: Ohrožení interních služeb – Útočník může zneužít interní služby k dalším útokům, jako je vzdálené spuštění kódu (RCE) nebo Denial of Service (DoS).

Odkazy

OWASP:

Externí:

CWE-918 Server-Side Request Forgery (SSRF)