Správa session

• Session = posloupnost transakcí a HTTP požadavků spojených se stejným uživatelem
• Session poskytuje možnost stanovení přístupových práv, lokalizace, jazykových preferencí a dalších proměnných, které se budou vztahovat ke každé interakci uživatele s aplikací po dobu trvání session
• Session umožňuje identifikaci uživatele po přihlášení
  • Je však možné je vytvářet i pro anonymní uživatele
• Po přihlášení je vytvořené session ID ekvivalentní uživatelskému jménu a heslu, certifikátu, tokenu, biometrickým údajům a dalším
  • Více informací najdete v cheat sheetu o autentizaci
• Session koncept byl zaveden proto, že každý požadavek a odpověď jsou na sobě nezávislé (stateless)

• Session ID nebo token se váže na poslední přihlášení
• Implementace bezpečného správy session je náročná, protože je v rukou vývojáře
  • Framework neposkytuje striktní vztahy mezi přihlášením, správou session a řízením přístupu
• Útočníci mohou provádět session hijacking útoky (předvídání, brute force, zachycení, fixace session ID)
  • Útočník se může vydávat za jiného (konkrétního nebo jakéhokoli) uživatele

Vlastnosti session ID

• Session ID slouží k udržení stavu o přihlášeném uživateli
• Session ID je sdílen a vyměňován mezi uživatelem a aplikací po celou dobu trvání session
  • Je odesíláno při každém HTTP požadavku
• Session ID je dvojice name=value

Session ID name fingerprinting

1. Nedělejte název session ID příliš popisný (neměl by poskytovat podrobnosti o účelu a významu)

• Názvy používané v běžných frameworcích lze snadno identifikovat (PHPSESSID, JSESSIONID)
• Session name může prozradit používané technologie a jazyky

1. Změňte výchozí session ID name na obecný název (např. id)

Délka session ID

1. Zajistěte, aby bylo session ID dostatečně dlouhé (zabránění brute force útoků)
2. Zajistěte, aby byla délka alespoň 128b (16B)

• Délka je sama o sobě pouze referenční - sílu ovlivňují další faktory

Session ID entropy

1. Zajistěte, aby bylo session ID nepředvídatelné (zabránění “guessing” útokům)
2. Použijte kvalitní generátor pseudonáhodných čísel (CSPRNG)

• Session ID value musí poskytovat alespoň 64b entropy (polovina délky session ID)
  • Útočníkovi bude trvat nejméně 292 let, než uhodne platné ID s 64b entropy

1. Zabraňte duplicitním ID - session ID není pouze náhodné, ale také jedinečné

Obsah / hodnota session ID

1. Zajistěte, aby byla hodnota session ID bezvýznamná (zabránění úniku informací)
2. Zajistěte, aby hodnota nikdy neobsahovala citlivé informace
3. Uložte význam a logiku spojenou se session ID na serveru
   • Uložené informace mohou zahrnovat IP adresu, user agent, email, uživatelské jméno, id uživatele, roli, přístupová práva, jazykové preference, session limit atd.
   1. Zašifrujte a řádně ochraňte session v případě, že obsahuje citlivé informace (kreditní karty)
4. Použijte session ID vytvořené frameworkem
   1. Použijte CSPRNG generátor o velikosti alespoň 128b a zajistěte unikátnost v případě, že potřebujete vytvořit vlastní session ID

Implementace správy session

• Mechanismus, který bude použit k výměně session mezi uživatelem a aplikací
• Existuje více možností výměny - cookies, URL parametry a argumenty, skrytá pole formuláře, HTTP hlavičky
• Mechanismus by měl umožňovat definování vlastností jako je datum a čas vypršení platnosti, granulární omezení použití
  • Jeden z důvodů, proč jsou cookies nejrozšířenějším mechanismem (nabízejí možnosti, které jsou nedostupné u jiných metod)
• Použití některých mechanismů může vést k odhalení session ID a usnadnění dalších útoků

Built-in implementace

1. Používejte vestavěné funkce frameworků namísto vytváření vlastních mechanismů od nuly
   • Používají se po celém světě v mnoha prostředích, a tak jsou časem prověřeny vývojáři i bezpečnostními odborníky
2. Používejte nejnovější dostupné verze frameworků
3. Zkontrolujte a případně změňte výchozí konfiguraci, abyste zvýšili bezpečnost
   1. Postupujte podle doporučení v tomto dokumentu
4. Zabezpečte session ID úložiště před neoprávněným přístupem a vyzrazením

Mechanismy výměny session ID

1. Využívejte cookies pro správu výměny session ID
2. Zabraňte přijetí session ID prostřednictvím jiného mechanismu výměny (předcházení fixace session)
   • I když aplikace používá cookies, může akceptovat i jiné mechanismy výměny
   1. Omezte akceptované mechanismy na cookies a testováním potvrďte, že jiné mechanismy neakceptujete

Zabezpečení transportní vrstvy

1. Použijte šifrované HTTPS (TLS) připojení pro ochranu výměny session ID
2. Podívejte se na možnost použití HSTS
3. Použijte atribut Secure, čímž zajistíte výměnu pouze šifrovaným kanálem

• Šifrovaná komunikace chrání session před útoky typu fixace session

1. Nepřepínejte session z HTTP na HTTPS nebo naopak (dojde k prozrazení session ID)
   1. Zajistěte nastavení nebo obnovení po přesměrování při přesměrování na HTTPS
2. Nemíchejte šifrovaný a nešifrovaný obsah na stejné stránce nebo doméně
3. Vyhněte se veřejnému nešifrovanému obsahu a soukromému šifrovanému obsahu ze stejného hostitele
4. Zvažte hostování na samostatné nezabezpečené doméně, pokud je nezabezpečený obsah vyžadován
5. Implementujte HSTS pro vynucení HTTPS připojení

• Více informací naleznete v cheat sheetu o zabezpečení transportní vrstvy
• TLS nechrání proti predikci session ID, brute force atd., poskytuje však ochranu proti man-in-the-middle útoku

Cookies

• Mechanismus výměny, který poskytuje řadu bezpečnostních prvků v podobě atributů souborů cookie

Atribut Secure

• Dává prohlížeči pokyn, aby cookies odesílal pouze prostřednictvím šifrovaného HTTPS (SSL/TLS) spojení
• Tím se předchází útokům typu man-in-the-middle a vyzrazení session ID
  • Útočník nemůže jednoduše zachytit session ID
• Útočník může zachytit a zmanipulovat provoz oběti a zmocnit se / upravit session ID při používání nešifrované HTTP komunikace

Atribut HttpOnly

• Instruuje prohlížeče, aby skriptům (Javascript) neumožňovaly přístup ke cookies prostřednictvím DOM (document.cookie)
• Tím se zabrání krádeži session ID prostřednictvím XSS a CSRF útoků

Atribut SameSite

• Zabraňuje prohlížeči odesílat cookie při požadavcích na jiné stránky
• Snižuje riziko úniku informací mezi stránkami
• Poskytuje ochranu proti CSRF útokům

Atributy Domain a Path

• Domain dává prohlížeči pokyn, aby cookies odesílal pouze do zadané domény a všech subdomén
  • Pokud není nastaven, bude cookies odesílat pouze na server původu
• Path dává prohlížeči pokyn, aby cookies odesílat pouze do zadaného adresáře nebo podadresářů (cest a zdrojů) v rámci aplikace
  • Pokud není nastaven, bude cookies odesílat pouze na cestu požadovaného zdroje

1. Použijte co nejužší a omezený rozsah pro tyto atributy
   1. Nenastavujte atributy Domain a Path

• Nastavení Domain na příliš obecnou (example.com), umožňuje útočníkovi provádět útoky mezi různými hostiteli (cross-subdomain cookies)
  • Zranitelnosti na adrese example.com mohou umožnit získání session ID z secure.example.com

1. Nemíchejte různé úrovně zabezpečení ve stejné doméně
   • Zranitelnost v jedné aplikaci by umožnila nastavení session ID v jiné aplikaci na stejné doméně (útok typu fixace session)
2. Nespouštějte různé aplikace na stejném hostiteli (zejména z různých úrovní zabezpečení nebo rozsahů)
   • Aplikace mohou k přístupu k session ID používat i jiné metody (document.cookie)

• Cookies jsou zranitelné vůči DNS spoofing / hijacking / poisoning útokům
  • Útočník může manipulovat s DNS resolution a donutit prohlížeč prozradit session ID hostitele nebo domény

Atributy Expires a Max-Age

• Pokud má cookie jeden z těchto atributý, je považována za trvalou a prohlížeč ji uloží na disk až do doby vypršení platnosti
• Max-Age má přednost před Expires
• Funkce správy session, které umožňují sledovat uživatele po přihlášení, obvykle využívají neperzistentní cookies
  • Session z klienta zmizí po zavření prohlížeče

1. Používejte neperzistentní cookies, aby session ID nezůstávalo po dlouhou dobu v mezipaměti, odkud ho může útočník získat
2. Zajistěte, aby citlivé informace nebyly ohroženy
   1. Neuchovávejte je trvale, šifrujte a ukládejte je pouze po dobu nezbytně nutnou
3. Zajistěte, aby prostřednictvím manipulace s cookies nedošlo k neoprávněným činnostem
4. Zkontrolujte, zda je nastaven Secure příznak
5. Zajistěte, aby všechny stavové přechody v kódu kontrolovaly cookies a vynucovaly jejich použití
6. Zašifrujte celou cookie, pokud jsou v ní uloženy citlivé údaje
7. Definujte cookies, které aplikace používá - jejich název a důvod, proč jsou potřeba

HTML5 Web Storage API

• Mechanismy pro ukládání name-value párů / dat na straně klienta
• Obsah není automaticky sdílen v rámci požadavků a odpovědí

localStorage

• Data jsou přístupná stránkám, které mají stejný původ
• Tím je dosaženo podobného přístupu k datům, jako při použití Secure příznaku u cookies
• Data v localStorage mohou být náchylná k problémům se sdíleným přístupem
  • Data by měla být považována za neuzamčená
• Data zde uložená jsou uchovávána napříč sessions, čímž se prodlužuje doba, ve které mohou být přístupná ostatním uživatelům systému
• Nevyžaduje šifrování dat, čímž je možné k datům přistupovat napřímo

1. Používejte localStorage pro data, ke kterým je potřeba přistupovat v různých oknech a kartách, ve více sessions a v případech, kdy je potřeba z výkonnostních důvodů ukládat velké objemy dat

sessionStorage

• Ukládá dat v rámci kontextu okna - jedno okno nemůže přistupovat k datům druhého okna
• Data jsou přístupná pouze stránkám, které mají stejný původ
• Tím je dosaženo podobného přístupu k datům, jako při použití Secure příznaku u cookies
• Ukládá data pouze po dobu trvání aktuální session prohlížeče
  • Po zavření karty nelze data načíst
• Nevyžaduje šifrování dat, čímž je možné k datům přistupovat napřímo

1. Používejte sessionStorage pro data, která jsou relevantní pro jednu instanci daného postupu (nákupní košík, rezervace letenek)

Web workers

• Spouští javascriptový kód v globálním kontextu aktuálního okna
• Alternativa pro ukládání secrets / session v prohlížeči (pokud není vyžadována perzistence při obnovení stránky)
• Veškerý kód, který vyžaduje secrets, by měl existovat v rámci web workers
• Secrets by nikdy neměly být přenášeny do kontextu hlavního okna
• Poskytuje stejné záruky zabezpečení jako HttpOnly u cookies
  • Přesto lze zneužít XSS
• Umožňuje přístup k secrets v izolovaném javascriptovém kódu
• Je to jediná možnost uložení dat v prohlížeči, která zachovává důvěrnost secrets

Životní cyklus session ID

Generování a ověřování session ID

• Existují dva typy správy session - permisivní a striktní
  • Obě souvisejí se zranitelností fixace session
• Permisivní mechanismus = umožňuje přijmout jakoukoli hodnotu session ID a vytvořit pro ni novou session
  • PHP ve výchozím nastavení
  1. Zajistěte, aby aplikace za určitých okolností nepoužívala tento mechanismus
• Striktní mechanismus = vynucuje přijetí dříve vygenerované session ID (nejčastěji používaný)

1. Nepřijímejte session ID, které jste nikdy nevytvořili
   1. Vygenerujte nové platné session ID v případě obdržení takového session ID

• Session by měla být zpracovávána serverem nebo generována pomocí kryptograficky zabezpečeného generátoru náhodných čísel

Spravujte session ID jako jakýkoli jiný uživatelský vstup

1. Považujte session ID za nedůvěryhodné
2. Důkladně jej validujte a ověřujte

• Neověřené session ID může být zneužito a využito k dalším útokům (SQL injection, XSS)

Obnovte session ID po změně oprávnění

1. Obnovte nebo regenerujte session ID po každé změně uživatelského oprávnění
2. Regenerujte session ID při každém přihlášení
3. Zvažte obnovení nebo regenerování v těchto případech
   • Změna hesla
   • Změna oprávnění nebo přechod z běžného uživatele na správce
4. Ignorujte předchozí session u všech citlivých stránek

• Frameworky poskytují funkce pro obnovení session ID (request.getSession(true) a HttpSession.invalidate(), session_regenerate_id(true))
• Regenerace je povinná pro zabránění útokům typu fixace session
  • Také zmírňuje dopad dalších zranitelností, které využívají fixace session (XSS)

1. Použijte odlišné session ID nebo název před a po přihlášení
   • Umožňuje sledovat anonymní a přihlášené uživatele
   1. Nesvazujte session uživatele mezi oběma stavy

Používání více souborů cookie

1. Ověřte všechny cookie soubory a vynuťte vztahy mezi nimi před povolením přístupu k session uživatele

• U aplikací je běžné, že se před přihlášením přes HTTP nastaví cookie uživatele (sledování anonymních uživatelů)
• Po přihlášení se nastaví nový, zabezpečený cookie soubor a vytvoří se vazba mezi oběma cookie soubory
• Pokud aplikace neověří oba soubory pro, může útočník využít nezabezpečený cookie soubor (ten před přihlášením) a získat přístup k ověřené session uživatele

1. Vyhněte se použití stejného názvu cookie pro různé cesty nebo domény v rámci aplikace

Vypršení platnosti session

1. Stanovuje, po jak dlouhou dobu bude session aktivní
2. Minimalizuje dobu, po kterou může útočník provádět útoky

• Nedostatečná expirace zvyšuje riziko útoků
  • Čím kratší je interval, tím méně času útočník má

1. Nastavte expiraci přiměřeně vůči účelu a povaze aplikace
   1. Vyvažte bezpečnost a použitelnost aplikace

• Hodnoty jsou závislé na tom, jak kritická je aplikace a data
• Obvyklé rozmezí nečinnosti je 2 - 5 minut pro kritické aplikace a 15 - 30 minut pro aplikace s nížším rizikem
• Pokud je aplikace určena k celodennímu používání pracovníkem, může být vhodný limit i 4 - 8 hodin

1. Zrušte session na straně klienta i serveru po vypšení její platnosti (hlavně na serveru)

Automatické vypršení session

Časový limit nečinnosti

• Doba, po kterou zůstane session aktivní v případě, že neprobíhá žádná aktivita
• Po vypršení limitu se session ID uzavře a zneplatní

1. Implementujte časový limit nečinnosti pro všechny sessions

• Omezuje šanci útočníka uhodnout a použít platné session ID jiného uživatele
  • Pokud se mu to však podaří, limit neomezuje akce, protože může generovat aktivitu
• Musí být vynucena na straně serveru
  • Na klientu s nimi může útočník manipulovat

Absolutní časový limit

• Definuje maximální dobu, po kterou může být session aktivní
• Po vypršení limitu se session ID uzavře a zneplatní, uživatel je donucen se znovu přihlásit

1. Implementujte absolutní limit bez ohledu na aktivitu

Časový limit pro obnovení

• Po uplynutí dodatečného limitu dojde k automatickému obnovení session ID nezávisle na aktivitě a nečinnosti
• Po uplynutí doby se vytvoří nová session a ID a dojde k obnovení i na klientovi
• Předchozí hodnota je ještě nějakou dobu platná

Manuální expirace session

1. Poskytněte uživatelům mechanismus bezpečného ukončení session

Logout tlačítko

1. Implementujte viditelné a snadno přístupné tlačítko pro odhlášení
2. Zajistěte, aby bylo tlačítko dostupné z každé stránky
3. Zajistěte ukončení session po kliknutí na tlačítko, jak je popsáno výše

Ukládání dat do mezipaměti

• I po ukončení session může být možné získat přístup k soukromým nebo citlivým údajům prostřednictvím mezipaměti

1. Použijte omezující cache direktivy (Cache-Control, Pragma) na všech (nebo alespoň na citlivých) stránkách
2. Nikdy neukládejte session ID do mezipaměti
   1. Použijte Cache-Control: no-cache="Set-Cookie, Set-Cookie2" direktivu, která umožní ukládat klientům do mezipaměti vše kromě session ID

Další obrany session na straně klienta

• Obvykle jde o ověřování a kontroly javascriptu
• Útočník je může snadno překonat, ale i přesto zavádějí další vrstvu obrany

Počáteční časový limit přihlášení

• Aplikace mohou pomocí javascriptu na přihlašovací stránce měřit dobu, která uplynula od jejího načtení a přidělení session ID
• Pokud je pokus o přihlášení proveden po uplnutí určité doby, může klientský kód upozornit uživatele na překročení maximální doby pro přihlášení a získat nové session ID
• Mechanismus se snaží vynutit obnovení session ID
• Snaží se zabránit opakovanému použití session ID a útoku fixace session

Vynucení odhlášení při zavření okna prohlížeče

• Pomocí javascriptu je možné zachytit událost zavření okna prohlížeče
• Díky tomu je možné provést akce k uzavření aktuální session před zavřením
• Jde o napodobení ručního ukončení session (jako při odhlášení pomocí tlačítka)

Zakázání sdílení session mezi okny prohlížeče

• Při otevření nové karty se stejnou aplikací je možné vyzvat uživatele k opětovnému přihlášení
• Neumožňuje, aby více karet prohlížeče sdílelo stejnou session
• Nelze použít, pokud se k výměně používá cookies mechanismus
  • Cookies jsou sdíleny mezi všemi kartami prohlížeče

Automatické odhlášení

• Pomocí javascriptu je možné uživatele automaticky odhlásit po uplynutí časového limitu
• Výhodou funkce časového limitu na straně klienta je, že uživatel vidí, že session skončila z důvodu nečinnosti
  • Může být předem upozorněn nebo sledovat odpočet
  • Uživatelsky přívětivé
  • Pomáhá zabránit ztrátě rozdělané práce

Detekce útoků na session

Hádání a brute force session ID

• Pokud se útočník pokusí uhodnout session ID, musí spustit několik sekvenčních požadavků na aplikaci s různými session ID

1. Detekujte pokusy na základě počtu pokusů o získání session ID a upozorněte nebo zablokujte danou IP adresu

Zjišťování anomálií session ID

1. Zaměřte se na detekci anomálií spojených se session ID, například pomocí OWASP AppSensor

• Problémy často souvisejí s byznys logikou aplikace
  • Úprava, přidání nebo odstranění cookie a použití session ID jiného uživatele
  • Změna umístění uživatele uprostřed relace nebo změna user agenta

Vazba session ID na další vlastnosti uživatele

1. Navazujte session ID na další vlastnosti uživatele nebo klienta (IP adresa, user agent)
   • Tím docílíte odhalení nebo ochrany neočekávaného chování uživatele
2. Ukončete relaci pokud zjistíte nějakou změnu nebo anomálii během trvání session
   • Může jít o indikátor manipulace se session

• Útočník však může kontroly obejít například použitím proxy serveru, případně ručně změní user agent

Logování

1. Logujte události související se session - vytvoření, obnovení, zničení session ID, podrobnosti o přihlášení a odhlášení, vypršení časového limitu, neplatné aktivity a kritické byznys operace během session

• Podrobnosti logu mohou obsahovat timestamp, zdrojovou IP adresu, požadovaný zdroj, HTTP hlavičky, GET a POST parametry, chybové kódy a zprávy, uživatelské jméno nebo ID uživatele

1. Nelogujte citlivé údaje jako je session ID
2. Logujte solený hash session ID, aby bylo možné kontrolovat záznamy specifické pro danou session bez odhalení session ID
3. Zabezpečte rozhraní pro správu aktivních sessions
   • Často používané pracovníky podpory k řešení problémů
   • Vydávají se za uživatele (přepnou režim) a nahlížejí / kontrolují aplikaci jako daný uživatel

• Logy jsou jedním z hlavních zdrojů dat pro detekci narušení aplikace
• Mohou být využívány systémy ochrany proti narušení k automatickému ukončení session a deaktivaci účtu při zjištění útoku
  1. Zaznamenejte tyto akce, pokud je tato ochrana implementována
• Více informací o logování najdete v cheat sheetu

Souběžná přihlášení

• O tom, zda je povoleno více současných přihlášení od stejného uživatele rozhoduje návrh aplikace

1. Ukončete dříve dostupnou session nebo se zeptejte uživatele, která session má zůstat aktivní, pokud nechcete povolit souběžná přihlášení
2. Přidejte uživatelské funkce, které umožňují
   • zkontrolovat podrobnosti o aktivních session
   • sledovat a upozorňovat na souběžná přihlášení
   • poskytovat funkce pro vzdálené ukončení sessions
   • sledovat historii aktivity účtu
3. Logujte více informací o klientovi - IP adresa, user agent, datum a čas přihlášení, doba nečinnosti atd.

WAF ochrana

• Jsou situace, kdy kód aplikace není k dispozici nebo jej nelze upravit, případně změny vyžadují přepracování architektury aplikace (nelze provést v krátkém čase)

1. Použijte externí ochranu, jako je WAF, ve výše zmíněných případech nebo jako doplněk

• WAF nabízejí funkce detekce ochrany proti útokům založených na sessions
• Poskytuje základní ochranu pomocí atributů popsaných v tomto dokumentu, ale také umožňuje sledovat session ID a aplikovat všechny druhy ochrany proti session fixaci (obnovení session ID, ověření vztahu mezi session ID a klientem, řízení vypršení platnosti session, vynucení ukončení session)
• Pro více informací navštivte například open source OWASP Core Rule Set

Kam dál

Checklisty

• Správa session
• Autentizace