Fixace relace - Session fixation

V zabezpečení počítačové sítě se útoky fixace relací pokoušejí využít zranitelnost systému, který umožňuje jedné osobě opravit (najít nebo nastavit) identifikátor relace jiné osoby . Většina útoků fixace relace je webová a většina se spoléhá na to, že identifikátory relací budou přijímány z adres URL ( řetězec dotazu ) nebo dat POST.

Scénáře útoku

Alice má účet v bancehttp://unsafe.example.com/

Mallory hodlá zaměřit peníze Alice z její banky.

Alice má v Mallory přiměřenou důvěru a bude navštěvovat odkazy, které jí Mallory pošle.

Jednoduchý scénář útoku

Jednoduchý scénář:

1. Mallory určil, že http://unsafe.example.com/přijímá jakýkoli identifikátor relace, přijímá identifikátory relací z řetězců dotazů a nemá žádné ověření zabezpečení. http://unsafe.example.com/není tedy bezpečný.
2. Mallory pošle Alice e-mail: „Hele, podívej se na to, v naší bance je skvělá nová funkce shrnutí účtu, http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID“. Mallory se pokouší opravit SID I_WILL_KNOW_THE_SID.
3. Alice má zájem a návštěvy http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. Zobrazí se obvyklá přihlašovací obrazovka a Alice se přihlásí.
4. Mallory navštěvuje http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SIDa nyní má neomezený přístup k účtu Alice.

Útok pomocí serveru generovaného SID

Mylná představa je, že pokud server přijímá pouze identifikátory relací generované serverem, je bezpečný před fixací. To je falešné .

Scénář:

1. Mallory navštíví http://vulnerable.example.com/a zkontroluje, které SID je vráceno. Například server může odpovědět: Set-Cookie: SID=0D6441FEA4496C2.
2. Mallory nyní může Alice poslat e-mail: „Podívejte se na tuto novou skvělou funkci v naší bance http://vulnerable.example.com/?SID=0D6441FEA4496C2.“
3. Alice se přihlásí s fixním identifikátorem relace SID=0D6441FEA4496C2.
4. Mallory navštěvuje http://vulnerable.example.com/?SID=0D6441FEA4496C2a nyní má neomezený přístup k účtu Alice.

Útočí pomocí souboru cookie mezi subdoménami

Tento typ útoku je podobný útoku na soubory cookie mezi weby s tím rozdílem, že se nespoléhá na zranitelnost prohlížeče uživatele. Spíše se spoléhá na skutečnost, že zástupné soubory cookie lze nastavit subdoménou a že tyto soubory cookie mohou ovlivnit jiné subdomény.

Scénář:

1. Web www.example.compředává subdomény nedůvěryhodným třetím stranám
2. Jedna taková párty, Mallory, která nyní ovládá evil.example.com, láká Alice na jeho stránky
3. Návštěva evil.example.comnastaví relační cookie s doménou .example.comv prohlížeči Alice
4. Když Alice navštíví www.example.comtento soubor cookie, bude odeslán s požadavkem a Alice bude mít relaci určenou Malloryho souborem cookie.
5. Pokud se Alice nyní přihlásí, Mallory může použít svůj účet.

Když je tento útok dokončen, Mallory může získat přístup www.example.comjako Alice.

Není nutné, aby se uživatel přihlásil k využití útoků fixace relace, a přestože tyto neautentizované útoky nejsou omezeny na útoky souborů cookie napříč subdoménami, důsledky útoků subdomén jsou pro tyto neověřené scénáře relevantní. Například Mallory může poskytnout adresu URL ze svého zlého webu, zafixovat relaci do neověřeného scénáře a použít tyto techniky k využití svého cíle. To zahrnuje scénáře využívající jak neautentizované scénáře (např. Formuláře nebo registrace), tak i možnost nakrmit uživatele zavedenou relací, aby bylo přihlášení zcela obejito.

Zvažte například, že Mallory může vytvořit uživatele A1ice na www.example.com a přihlásit se k tomuto uživateli, aby zachytil aktuální platný identifikátor relace. Mallory poté ukořistí Alice pomocí adresy URL z evil.example.com, která opraví soubor cookie relace v prohlížeči Alice (jak je popsáno výše) a přesměruje na www.example.com za účelem dokončení konkrétní transakce (nebo ve skutečnosti širšího využití). Mallory tak může relaci odstranit z původního přihlášení, seškrabávat data a provádět operace jako „A1ice“ na „www.example.com“. Pokud byla Alice úspěšně podvedena a uložila svou kreditní kartu na účet, Mallory by pak mohl nakupovat pomocí této karty.

Protiopatření

Nepřijímejte identifikátory relací z proměnných GET / POST

Identifikátory relací v adrese URL (řetězec dotazu, proměnné GET) nebo POST se nedoporučují, protože tento útok zjednodušují - je snadné vytvářet odkazy nebo formuláře, které nastavují proměnné GET / POST.

• SID se dostává k ostatním lidem, protože uživatelé vyjímají a vkládají „zajímavé odkazy“ z adresního řádku do chatů, fór, komunit atd.
• SID je uloženo na mnoha místech (protokol historie prohlížeče, protokol webového serveru, protokoly proxy, ...)

Poznámka: Soubory cookie jsou sdíleny mezi kartami a vyskakovanými okny prohlížeče. Pokud váš systém vyžaduje přístup ke stejné doméně (www.example.com/?code=site1 a www.example.com/?code=site2), mohou se soubory cookie mezi kartami navzájem konfliktovat.

Aby bylo možné toto omezení překonat, může být nutné odeslat identifikátor relace na adresu URL. Pokud je to možné, použijte site1.example.com nebo site2.example.com, aby nedocházelo ke konfliktům domény v souborech cookie. To může znamenat náklady s extra SSL certifikáty.

Toto chování lze pozorovat na mnoha webech tak, že otevřete další kartu a pokusíte se provést výsledky vyhledávání vedle sebe. Jedna z relací bude nepoužitelná.

Nejlepší řešení: Potvrzení identity

Tomuto útoku lze do značné míry zabránit změnou ID relace při přihlášení uživatelů. Pokud každý požadavek specifický pro uživatele vyžaduje, aby byl uživatel ověřen („přihlášen“) na webu, útočník by musel znát ID oběti relace přihlášení. Když oběť navštíví odkaz s pevným ID relace, bude se muset přihlásit ke svému účtu, aby mohla cokoli „důležitého“ dělat sama. V tomto okamžiku se změní jejich ID relace a útočník nebude moci s anonymním ID relace dělat nic „důležitého“.

Podobnou techniku ​​lze použít k vyřešení problému s phishingem . Pokud uživatel chrání svůj účet dvěma hesly, pak to lze do značné míry vyřešit.

Tato technika je také užitečná proti útokům padělání požadavků mezi weby .

Řešení: Uložte identifikátory relací do souborů cookie HTTP

Identifikátor relace na většině moderních systémů je ve výchozím nastavení uložen v souboru cookie HTTP , který má střední úroveň zabezpečení, pokud systém relací ignoruje hodnoty GET/POST. Toto řešení je však citlivé na padělání požadavků mezi weby a nesplňuje požadavek REST na bezstavovost .

Řešení: Použijte identifikátor relace SSL / TLS

Při povolení zabezpečení HTTPS některé systémy umožňují aplikacím získat identifikátor relace SSL / TLS . Použití identifikátoru relace SSL/TLS je velmi bezpečné, ale mnoho jazyků pro vývoj webu k tomu neposkytuje robustní integrované funkce.

Při každém požadavku znovu vygenerujte SID

Protiopatřením proti fixaci relace je vygenerování nového identifikátoru relace (SID) pro každý požadavek. Pokud je to provedeno, pak přestože útočník může přimět uživatele k přijetí známého SID, bude SID neplatné, když se útočník pokusí znovu použít SID. Implementace takového systému je jednoduchá, jak ukazuje následující:

• Získejte předchozí identifikátor relace OLD_SIDz požadavku HTTP.
• Pokud OLD_SIDje null, prázdná nebo žádná relace s SID = OLD_SIDneexistuje, vytvořte novou relaci.
• Vygenerujte nový identifikátor relace NEW_SIDpomocí zabezpečeného generátoru náhodných čísel.
• Nechte relaci identifikovat pomocí SID = NEW_SID(a již ne podle SID = OLD_SID)
• Přenos nového SID do klienta.

Příklad:

Pokud Mallory úspěšně podvede Alici na návštěvu http://victim.example.com/?SID=I_KNOW_THE_SID, bude tento požadavek HTTP odeslán na victim.example.com:

GET /?SID=I_KNOW_THE_SID HTTP/1.1
Host: victim.example.com

victim.example.compřijímá SID=I_KNOW_THE_SID, což by normálně bylo špatné. Je však victim.example.combezpečný, protože provádí regeneraci relace. victim.example.comdostane následující odpověď:

HTTP/1.1 200 OK
Set-Cookie: SID=3134998145AB331F

Alice nyní použije SID=3134998145AB331Fto, co Mallory nezná a SID=I_KNOW_THE_SIDje neplatné. Mallory je tedy neúspěšný při pokusu o fixaci relace.

Regenerace relace bohužel není vždy možná. Je známo, že k problémům dochází při používání softwaru třetích stran, jako jsou aplety ActiveX nebo Java, a při komunikaci zásuvných modulů prohlížeče se serverem. Software třetích stran by mohl způsobit odhlášení nebo relaci by bylo možné rozdělit na dvě samostatné relace.

Pokud implementace relací zahrnuje přenos SID prostřednictvím proměnných GET nebo POST, pak by to také mohlo způsobit, že tlačítko „zpět“ ve většině prohlížečů bude nepoužitelné, protože uživatel by pak používal starší, neplatný identifikátor relace z předchozí žádosti.

Přijímejte pouze SID generovaná serverem

Jedním ze způsobů, jak zlepšit zabezpečení, je nepřijímat identifikátory relací, které nebyly generovány serverem. Jak je však uvedeno výše, nezabrání to všem útokům fixace relace.

if (!isset($_SESSION['SERVER_GENERATED_SID'])) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['SERVER_GENERATED_SID'] = true;

Funkce odhlášení

Funkce odhlášení je užitečná, protože umožňuje uživatelům určit, že relace by neměla umožňovat další požadavky. Útoky tedy mohou být účinné pouze tehdy, když je relace aktivní. Následující kód neprovádí žádné kontroly padělání požadavků mezi weby , což potenciálně umožňuje útočníkovi vynutit odhlášení z webové aplikace.

if (logout) {
    session_destroy(); // Destroy all data in session
}

Time-out old SIDs

Tato obrana se snadno implementuje a má tu výhodu, že poskytuje ochranu proti neoprávněným uživatelům přistupujícím k účtu autorizovaného uživatele pomocí počítače, který mohl zůstat bez dozoru.

Uložte proměnnou relace obsahující časové razítko posledního přístupu provedeného daným SID. Když se ten SID použije znovu, porovnejte aktuální časové razítko s tím, které je uložené v relaci. Pokud je rozdíl větší než předdefinované číslo, řekněme 5 minut, relaci zničte. Jinak aktualizujte proměnnou relace aktuálním časovým razítkem.

Pokud je Referrer podezřelý, zničte relaci

Při návštěvě stránky většina webových prohlížečů nastaví záhlaví Doporučovač - stránku, která obsahovala odkaz, kterým jste se na tuto stránku dostali.

Když je uživatel přihlášen na web, na který není pravděpodobné, že by byl propojen mimo tento web (např. Bankovní weby nebo webová pošta ), a tento web není typem webu, na kterém by uživatelé zůstali přihlášeni po jakoukoli dlouhou dobu čas by měl být doporučující pracovník z tohoto webu. Jakýkoli jiný Doporučující by měl být považován za podezřelý. Pokud však původní požadavek pochází ze stránky HTTPS, bude odkazovač odstraněn, takže se na tento systém zabezpečení nemůžete spolehnout.

Může například http://vulnerable.example.com/použít následující bezpečnostní kontrolu:

if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable.example.com/') !== 0) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier

Ověřte, že jsou během relace konzistentní další informace

Jedním ze způsobů, jak dále zlepšit zabezpečení, je zajistit, aby se uživatel jevil jako stejný koncový uživatel (klient). Díky tomu je o něco těžší provádět fixaci relace a další útoky.

Jak stále více sítí začíná odpovídat RFC 3704 a dalším postupům proti spoofingu , stává se IP adresa spolehlivější jako identifikátor „stejného zdroje“. Zabezpečení webových stránek lze proto zlepšit ověřením, že zdrojová adresa IP je v celé relaci konzistentní.

To lze provést tímto způsobem:

if ($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

Před použitím tohoto přístupu je však třeba zvážit několik bodů.

• Několik uživatelů může sdílet jednu IP adresu. Není neobvyklé, že celá budova sdílí jednu IP adresu pomocí NAT .
• Jeden uživatel může mít nekonzistentní IP adresu. To platí pro uživatele za proxy (například zákazníci AOL ). Platí to také pro některé mobilní/roamingové uživatele a uživatele, kteří stojí za internetovým připojením s vyrovnaným zatížením. Uživatelé s povoleným rozšířením soukromí IPv6 mohou také kdykoli změnit své adresy IPv6 pro ochranu osobních údajů.
• S klienty se dvěma zásobníky nebude fungovat spolehlivě, protože požadavky se budou pohybovat mezi IPv4 a IPv6.
• S mobilními uživateli to nebude fungovat spolehlivě, protože mobilní uživatelé se také toulají mezi adresami.

U některých webů přidané zabezpečení převažuje nad nedostatkem pohodlí, u jiných nikoli.

Uživatelský agent

Prohlížeče se identifikují pomocí hlaviček HTTP „User-Agent“. Tato hlavička se během používání běžně nemění; bylo by krajně podezřelé, kdyby k tomu došlo. Webová aplikace může využívat detekci User-Agent ve snaze zabránit uživatelům se zlými úmysly krást relace. Toto je však triviální obejít, protože útočník může snadno zachytit uživatelského agenta oběti svým vlastním webem a poté jej během útoku zfalšovat. Tento navrhovaný bezpečnostní systém spoléhá na zabezpečení prostřednictvím nejasností .

if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) {
    session_destroy(); // Destroy all data in session
}
session_regenerate_id(); // Generate a new session identifier
$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];

Před použitím tohoto přístupu je však třeba zvážit několik bodů.

• Několik uživatelů může mít stejný prohlížeč User Agent v internetové kavárně .
• Několik uživatelů může mít stejný výchozí prohlížeč (např .: Internet Explorer 6 v systému Windows XP SP3 nebo mini prohlížeč v mobilním telefonu).

Ale User Agent se může v několika případech legálně změnit. Následující příklady jsou stejní uživatelé.

• Smartphone, jehož obrazovka se otáčela od posledního požadavku
  • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
  • Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2
• Režim kompatibility aplikace Internet Explorer:
  • Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
  • Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
• Uživatel přistupující na webové stránky prostřednictvím serveru proxy distribuovaného na více serverech, z nichž ne všechny jsou upgradovány na nejnovější verzi softwaru proxy
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
  • Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)

Obrana do hloubky

Hloubková obrana spočívá v kombinaci několika protiopatření. Myšlenka je jednoduchá: pokud je jedna překážka triviální k překonání, několik překážek by bylo velmi těžké překonat.

Strategie hloubkové obrany by mohla zahrnovat:

• Povolit HTTPS (pro ochranu před jinými problémy)
• Správná konfigurace (nepřijímat externí SID, nastavit časový limit atd.)
• Proveďte relaci_regenerace, odhlášení podpory atd.

Doporučovatelé HTTP nejsou předáváni pomocí SSL/TLS (HTTPS).

Následující skript PHP ukazuje několik takových protiopatření kombinovaných do hloubky obrany:

if (isset($_GET['LOGOUT']) ||
    $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] ||
    $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) {
    session_destroy();
}

session_regenerate_id(); // Generate a new session identifier

$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

Tento kód kontroluje aktuální REMOTE_ADDR (IP adresa uživatele) a User-agent proti REMOTE_ADDR a User-agent předchozí žádosti. To může být pro některé weby nepohodlné, jak je uvedeno výše.

Viz také

• Otrava relací
• Zvýšení oprávnění

Reference

externí odkazy

• Bezpečnostní roh: Fixace relace
• Chyba zabezpečení fixace relace ve webových aplikacích (PDF)
• Příklad videa s fixací relace
• Klasifikace hrozeb konsorcia pro zabezpečení webových aplikací