V zabezpečení počítačové sítě útoky Fixace relace zneužívají zranitelnost systému, který umožňuje někomu nastavit (určit) identifikátor relace (SID nebo ID relace ) jiné osoby. Většina z těchto útoků se odehrává na webu a pochází z přijímání SID v adrese URL (řetězec požadavku) nebo v datech POST.
Alice má účet v bance http://unsafe/. Alice bohužel neví o bezpečnosti.
Mallory má v úmyslu získat Alice peníze z této banky.
Alice má přiměřenou úroveň důvěry v Mallory a navštíví dluhopisy, které jí Mallory pošle.
Přímý scénář:
Mylná představa je, že server, který přijímá pouze SID generovaná serverem, není ohrožen opravou. To je špatně .
Scénář:
Další útok na fixaci relace, vaření mezi weby , využívá chyby zabezpečení prohlížeče. To umožňuje webu http://mechant/ukládat soubory cookie v prohlížeči Alice v doméně souborů cookie jiného serveru, například tomu http://gentil/, kterému Alice důvěřuje. Tento útok může fungovat, i když v něm není žádná chyba zabezpečení http://gentil/, protože http://gentil/lze předpokládat, že zpracování souborů cookie prohlížečem Alice je zabezpečené.
Scénář:
Tato technika je identická s útokem při použití vaření napříč weby, kromě toho, že se nespoléhá na zranitelnost prohlížeče. Je založen na skutečnosti, že soubory cookie se zástupnými znaky může vytvářet jedna subdoména, což ovlivňuje další subdomény.
Scénář:
Každý z těchto scénářů útoku byl výsledkem zvýšení úrovně privilegií , kdy Mallory získala přístup k funkcím a datům obvykle vyhrazeným pro Alici.
Scénář alternativního útoku nevyžaduje, aby se Alice připojila k webu. Spíše jednoduše opravením relace může Mallory špehovat Alici a využít výhod dat, která posílá. Například Mallory může použít výše uvedené útoky, aby poskytla Alici vlastní ověřenou relaci - takže Alice začne používat web s ověřením Mallory. Pokud se Alice rozhodne něco z tohoto webu koupit a zadá číslo své kreditní karty, může být Mallory schopna data načíst nahlédnutím do historie dat uložených pro daný účet.
Kontext uživatele představuje všechny informace na straně serveru týkající se uživatele, který je ověřen (relace) a ke kterému je SID propojen. To zejména umožňuje serveru identifikovat práva odesílatele požadavku na řízení přístupu.
Nepřijímejte SID proměnných GET / POSTSID v URL (proměnné GET) nebo v proměnných POST se nedoporučují, protože tento útok zjednodušují. Vytváření odkazů nebo formulářů, které určují proměnné GET / POST, je snadné.
Používejte soubory cookie HTTP moudřeV moderních systémech je SID ve výchozím nastavení uložen v souboru cookie HTTP, což představuje průměrnou úroveň zabezpečení, pokud systém pro správu relací nezohledňuje proměnné GET / POST. Toto řešení je však zranitelné útokem CSRF (Cross-Site Request Forgery) a nerespektuje omezení bezstavové architektury REST .
PS: Je důležité chránit tyto cookies pomocí různých atributů, kterým běžné prohlížeče rozumějí (nesouvisí přímo se zranitelností „Session fixation“):
Každá změna kontextových oprávnění obecně odpovídá autentizaci, při které uživatel poskytne své tajemství. Běžně najdeme ověřovací stránky, kde se kontext mění z „oprávnění neověřeného uživatele“ na „oprávnění ověřeného uživatele“ (je třeba vzít v úvahu další případy, jako je druhé ověřování pro přístup k administraci aplikací).
Regenerace SID umožňuje zmírnit riziko, že uživatel předem umístil / přečetl SID této změny oprávnění, a může tak těžit z těchto nových oprávnění, aniž by musel znát tajemství.