Press "Enter" to skip to content

OWASP ZAP – Testování neautentizovaným a autentizovaným uživatelem

Published 17/08/2023 by Oxford

Při bezpečnostním testování webových aplikací je důležité zohlednit – mimo jiné – různé uživatelské perspektivy, aby bylo možné identifikovat co nejvíce potenciálních slabých míst. Proto mnohá bezpečnostní testování (zejména zranitelnostní) webů je vhodné provádět z pohledu

  • neautentizovaného uživatele,
  • autentizovaného uživatele.

Obojí, testování z pohledu neautentizovaného i autentizovaného uživatele, jsou kritické součásti komplexního bezpečnostního testování webových aplikací, jež by měly být zvažovány v rámci každé bezpečnostní revize (když hovořím o „bezpečnostní revizi“, myslím tím systematický proces, při kterém se analyzuje webová aplikace s cílem identifikovat potenciální bezpečnostní zranitelnosti a nedostatky. Tato revize by měla být součástí standardního vývojového cyklu webových aplikací a měla by se provádět pravidelně, nejen při vývoji, ale i během provozu aplikace, aby se udržela co nejvyšší úroveň bezpečnosti). Samozřejmě, každý pohled (neautentizovaným i autentizovaným uživatelem) na bezpečnostní testování webových aplikací přináší i možná omezení a nevýhody.

Výhody a nevýhody bezpečnostního testování autentizovaným a neautentizovaným uživatelem

Níže uvádím některé výhody a nevýhody testování z pohledu neautentizovaného (anonymního) uživatele a autentizovaného uživatele:

Výhody testování z pohledu neautentizovaného (anonymního) uživatele:

  • Detekce zranitelností ve veřejně přístupných částech aplikace: Testování z tohoto pohledu umožní identifikovat zranitelnosti, které mohou být využity kýmkoli na internetu, aniž by bylo třeba se přihlašovat do aplikace.
  • Testování přístupových kontrol: Můžete ověřit, zda jsou určité citlivé části aplikace řádně chráněny a nejsou přístupné bez přihlášení.
  • Identifikace informačního úniku: Detekuje, zda aplikace neodhaluje citlivé informace (např. chybové zprávy, interní cesty, …, verze software.), které by mohly napomoci k útoku.
  • Ověření bezpečnostních mechanismů na straně klienta: Testuje, zda aplikace spoléhá na bezpečnostní kontroly prováděné na straně klienta, které mohou být obejity.
  • Atd.

Nevýhody testování z pohledu neautentizovaného (anonymního) uživatele:

  • Omezený přístup k funkcím aplikace: Testování neautentizovaným uživatelem omezuje průzkum na veřejně dostupné části aplikace – tím nejsou ověřeny všechny možné cesty a funkce.
  • Nedostatečné testování oprávnění: Bez autentizace nelze plně ověřit, zda jsou role a přístupová práva správně implementována.
  • Nemožnost detekce určitých typů zranitelností: Některé zranitelnosti se mohou vyskytnout pouze v kontextu autentizovaného uživatele.
  • Atd.

Výhody testování z pohledu autentizovaného uživatele:

  • Testování oprávnění a role-based access control (RBAC): Je možné ověřit, zda jsou uživatelská oprávnění správně implementována a zda uživatelé nemohou přistupovat k datům nebo funkcím, ke kterým by mít přístup neměli.
  • Identifikace zranitelností po přihlášení: Některé zranitelnosti se mohou projevit až po přihlášení. Autentizované testování to umožní odhalit.
  • Testování zneužití funkcí: Autentizovaný uživatel může mít možnost zneužít aplikaci různými způsoby, např. provádění neoprávněný akcí (jako je mazání nebo modifikace dat atp.).
  • Testování zabezpečení dat: Může ověřit, zda jsou uživatelská data izolována a chráněna, a zda uživatelé nemohou přistupovat k datům jiných uživatelů.
  • Ověření bezpečnostních opatření při změně údajů uživatele: Testuje, zda jsou např. změny hesla, e-mailových adres nebo jiných citlivých informací chráněny dalšími bezpečnostními opatřeními (např. potvrzením pomocí e-mailu, 2FA).
  • Atd.

Nevýhody testování z pohledu autentizovaného uživatele:

  • Riziko změny nebo poškození dat: Autentizované testování může zahrnovat manipulaci s citlivými daty či funkcionalitami; to může vést k nechtěným změnám nebo poškození dat v testované aplikaci.
  • Potřeba platných uživatelských účtů: Pro testování autentizovaným uživatelem je potřeba mít přístup k platným uživatelským účtům, což může být z hlediska správy a bezpečnosti komplikovanější.
  • Složitost a náročnost testování: Poctivé testování s různými uživatelskými rolemi a oprávněními může být časově náročné a komplikované, což může zvyšovat náklady na bezpečnostní testování.
  • Nemožnost detekce některých zranitelností ve veřejných částech aplikace: Pokud je testování omezeno pouze na autentizované uživatele, mohou být přehlédnuty některé zranitelnosti, které by byly viditelné neautentizovaným uživatelům.
  • Potřeba dodržování právních a etických norem: Pro testování z pohledu autentizovaného uživatele musí být zvýšena právní a etická pozornost – např. může být třeba získat souhlas majitelů dat, což může být právně a eticky náročnější (než v případě neautentizovaného testování).
  • Atd.

OWASP ZAP – testování (skenování) autentizovaným uživatelem

OWASP ZAP (Zed Attack Proxy) je oblíbený a vysoce konfigurovatelný open-source bezpečnostní skener zranitelností webových aplikací (ale lze ho použít také například pro testování mobilních aplikací), který je k dispozici zdarma. Je navržen tak, aby automaticky testoval bezpečnost webových aplikací a pomáhal najít bezpečnostní zranitelnosti během vývoje a testování aplikací. ZAP může být použit pro manuální i automatizované testování bezpečnosti a je vhodný pro profesionální, ale i začínající bezpečnostní testery.

OWASP ZAP je mimořádně užitečný nástroj pro bezpečnostní testování webových aplikací. Avšak jako každý nástroj má své silné a slabé stránky. Je důležité ho používat jako součást širší strategie bezpečnostního testování, která může zahrnovat i jiné nástroje a metody, včetně manuálního testování.

Když se bavíme o autentizovaném skenování zranitelností pomocí OWASP ZAP, mluvíme o skenování, při kterém je skener konfigurován tak, aby se přihlašoval do webové aplikace stejně jako legitimní uživatel. To umožňuje skeneru testovat bezpečnost částí aplikace, které jsou přístupné pouze po přihlášení.

OWASP ZAP umožňuje pracovat s pestrou škálou autentizačních mechanismů, které zohledňují:

  • Autentizační metodu: Ta definuje, jakým způsobem je autentizace zpracována. Autentizace se používá k vytvoření webových relací, jež odpovídají ověřeným uživatelům webové aplikace.
  • Strategii ověřování autentizace: Ta definuje, jak by ZAP měl zjišťovat, kdy zprávy odpovídají ověřeným požadavkům.

Aby bylo možné provést autentizaci uživatele, metoda a strategie ověřování definují proces autentizace, přičemž potřebné přihlašovací údaje (přesné identifikátory) jsou závislé na uživateli – ti se konfigurují v uživatelích (Users).

Hlavní obecné kroky pro konfiguraci autentizace nástrojem OWASP ZAP jsou následující:

Praktický příklad

V praxi je nejběžnější (resp. velmi častá) konfigurace pro autentizované skenování zranitelností prostřednictvím form-based authentication a cookie-based session management. Proto v praktické ukázce se budu ubírat tímto směrem.

Form-based Authentication: Jedná se běžný a široce používaný způsob autentizace na webových stránkách a aplikacích. Uživatelé se přihlašují do aplikace vyplněním a odesláním webového formuláře, který obsahuje jejich přihlašovací údaje, typicky uživatelské jméno a heslo. OWASP ZAP umožňuje nastavit skenování tak, že může automatizovat proces přihlášení uživatele prostřednictvím tohoto formuláře.

Cookie-Based Session Management: Po úspěšné autentizaci je uživateli přidělen unikátní identifikátor sezení, který je obvykle uložen v cookie. Tato cookie je pak odesílána spolu s každým následujícím HTTP požadavkem na server, aby aplikace mohla identifikovat a autorizovat uživatele. OWASP ZAP je schopen rozpoznat a spravovat tyto cookies během skenování, což umožňuje, aby skenování probíhalo jako by bylo prováděno legitimním, přihlášeným uživatelem.

Ujištění se, prohlížeč je nakonfigurován tak, aby používal ZAP jako proxy

Potřebujete mít nakonfigurován svůj prohlížeč tak, aby používal ZAP jako proxy. Ve výchozím nastavení ZAP používá adresu „localhost“ a port „8080“, ale lze je změnit pomocí Options > Network > Local Servers/Proxies.

Bližší informace k nastavení je na ZAP – Configuring Proxies.

Pokud máte správně nakonfigurován prohlížeč a ZAP, pak pokud budete proklikávat webovou stránku, veškerý provoz můžete zaznamenat v ZAP. Potíže se mohou vyskytnout s HTTPS – to lze řešit pomocí dynamického certifikátu – blíže viz ZAP – Server Certificates, YouTube – ZAP Installing Dynamic Certificate.

Nastavení kontextu

Tím, jak jste proklikávali testovaný web se v ZAP projevil provoz mezi prohlížečem a serverem. Kontext lze vytvořit například tak, že přes pravé tlačítko myši vyberete Include in Context > New Context.

V rámci Context následně budeme zadávat všechny potřebné informace.

Blíže k tématu Context viz ZAP – Contexts.

Nastavení metodu správy relací na Cookie-based Session Management

V rámci daného kontextu vyberte Session Management > Cookie-based Session Management.

Existuje více možností pro Session Management, ty ale nyní nevyužijeme: HTTP Authentication Session Management, Script-based Session Management, Header-based Session Management, Auto-Detect Session Management.

Přihlášení se do aplikace pomocí prohlížeče

V ZAP potřebujeme zachytit požadavek pro přihlášení do webu. Proto v prohlížeči proveďte přihlášení uživatelským jménem a heslem.

Identifikace přihlašovacího požadavku v ZAP

Přejděte na ZAP a identifikujte požadavek, který byl proveden pro přihlášení (nejčastěji se jedná o HTTP POST požadavek obsahující uživatelské jméno a heslo a případně další prvky).

Zohlednění anti-CSRF tokenu

Pokud je v požadavku na přihlášení anti-CSRF token, přidejte název tokenu do Options >Anti-CSRF Tokens (pokud tam již není uveden).

Blíže k anti-CSRF tokenům viz ZAP – Anti CSRF Handling.

Nastavení metody ověření

Nastavte metodu ověřování:

  • Pravým tlačítkem klikněte na autentizační požadavek a vyberte možnost „Flag as Context“ > daný kontext s Form-based Auth Login Request.
  • Otevře se okno již obsahující URL požadavku a parametry (pokud existují). Pomocí rozbalovacích možností vyberte, který z parametrů odpovídá uživatelskému jménu a heslu
  • Obvykle jsou (v okne Authentication – Session Properties) v poli Login Request POST Data (if any) předvyplněny data, která odešla s požadavkem. Ale protože budeme chtít přihlašovat i jiné uživatele, je vhodnější předvyplněné údaje upravit tak, aby byly obsaženy proměnné – například (podle specifik případu): p_userid={%p_userid%}&p_password={%p_password%}

Nastavte strategii ověřování autentizace

Vyberte něco (např. textový řetězec), co identifikuje stav přihlášení a odhlášení, např. odkaz na odhlášení nebo uvítací zprávu a nastavte:

  • Relevantní Verification Strategy.
  • Regex pattern used to identify Logged In messages.
  • Regex pattern used to identify Logged Out messages.

Blíže ke strategii ověřování autentizace viz ZAP – Authentication Verification Strategies.

Definování jednotlivých uživatelů

Definujte tolik uživatelů, kolik potřebujete, v sekci Session Properties > Users section.

Spouštějte sken v kontextu uživatele

Po konfiguraci ověřování jsou v ZAP k dispozici různé akce. Nyní můžete například vybrat uživatele v dialogu Spider. Nebo pomocí režimu nuceného uživatele můžete vynutit, aby všechny interakce, které procházejí přes ZAP pro daný kontext, byly z pohledu konkrétního uživatele.

Vynucený uživatelský režim (Forced User Mode) se aktivuje pomocí tlačítka na panelu nástrojů (ikona s uživatelem a zámkem) a konfiguruje se pomocí Session Properties > Forced User Mode..

Závěr

Autentizované skenování zranitelností pomocí OWASP ZAP umožňuje nástroji identifikovat bezpečnostní chyby, které jsou viditelné nebo zneužitelné pouze po přihlášení. K tomu ZAP používá různé konfigurace jako například form-based authentication, kdy simuluje přihlašovací proces uživatele vyplněním a odesláním webového formuláře s přihlašovacími údaji, a cookie-based session management, kdy je schopen zacházet se seeionid v cookies, které server používá k identifikaci a sledování autentizovaných uživatelů.

Při autentizovaném skenování je důležité pečlivě nastavit ZAP, včetně přihlašovacích údajů, URL přihlašovacího formuláře a indikátorů přihlášení a odhlášení. Tato pečlivá konfigurace umožňuje ZAPu efektivně testovat nejen veřejně přístupné, ale také autentizací chráněné části aplikace, aniž by vyvolal bezpečnostní mechanizmy, jako je blokování účtu kvůli opakovaným neúspěšným pokusům o přihlášení.

Nicméně při autentizovaném automatizovaném skenování webů je třeba o to více vnímat související rizika bezpečnostního testování – o to více to platí v případě testování produkčních (ostrých) webů. Jedním z klíčových rizik je například možnost změny nebo poškození dat, protože skener může interagovat s aplikací podobně jako legitimní uživatel a může tak třeba neúmyslně modifikovat nebo smazat citlivé informace. Kromě toho je nezbytné dodržovat právní a etické normy (viz např. Morální dilemata kyberbezpečnostního testování) – skenování webu bez souhlasu jeho vlastníka může být považováno za nelegální činnost a může mít právní důsledky. Tato rizika zdůrazňují důležitost pečlivé konfigurace skeneru a potřebu provádět testy v kontrolovaném a legálním prostředí, ideálně na testovacích verzích aplikací, kde jsou použita anonymizovaná nebo fiktivní data a kde je zajištěn informovaný souhlas vlastníka systému.

Zdroje

Published in Kyberbezpečnost