Open menu Close menu
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 sepouží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 minimalizovali případnépokusy například o 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 minimalizovali 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ýma 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í paramter, 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á konkrténtí URL adresu. Pro přístup na stránku správce by mělo 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í:

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 důležité zaměřit se minimálně na následující kroky:

  • Zjistíte jaká data vaše webová aplikace zpracovávaná, 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ádat zbytečně citlivá data. Zvážit která citlivá data jsou důležitá ukládat a která ne. Data, která nejsou uchována, nemohou být odcizena.

  • Ujistěte se, že máte šifrovaná všechna citlivá data.

  • Pravidelně kontrolujte, aby byly 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 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í:

Jak 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í:

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í 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 ními 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 brát v potaz zpětnou vazbu

  • Využít modelování hrozeb pro kritickou autentizaci, nebo řízení přístupu

  • Integrujte kontroly na každé úrovni vaší 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 designua 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í:

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 frameworkcí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ě:

  • Platforma 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 nebude 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ůžezjistit, 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ůženají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í:

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).

  • Pokud je software 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.

  • Pokud pravidelněa včas neupgradujete základní platformu, frameworky.

  • Pokud vývojáři softwaru netestují kompatibilitu aktualizovaných, upgradovaných nebo opravených knihoven.

  • Pokud 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í:

  • 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řiobnově 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žijte 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 administratory.

  • 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 jako jsou 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í:

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 šance ke vzniku nové kritické zranitelnosti

  • Ujistěte se, aby nepodepsaná nebo nezašifrovaná serializovaná data nebyla 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ář č. 1Aktualizace bez podpisu: Mnoho domácích routerů, set-top boxů, firmwaru 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 bude jen zhoršovat.

Scénář č. 2 Škodlivá aktualizace SolarWinds: Je známo, že útočníci vyhledávají neauktá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í:

  • 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 i 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:

  • Ujistěte se, 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.

  • Ujistěte se, 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 protokoů - 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 nebo odstranění databázových tabulek.

  • Bezpečnostní oddělení by mělo zavést monitorování a 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ánpro 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ícizískali, díky bezpečnostní zranitelnosti platebních 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í:

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

  • Nastavit 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í: