Relace (informatika)
síťové spojení mezi klientem a serverem From Wikipedia, the free encyclopedia
Relace (anglicky a slangově session, méně často sezení nebo seance) v informatice představuje permanentní síťové spojení mezi klientem a serverem nebo úsek práce na počítači zahájený přihlášením a ukončený odhlášením bez ohledu na to, zda se s počítačem komunikuje po síti nebo ne. Relaci je možné chápat jako logické spojení, které může zahrnovat několik fyzických spojení.
Program GNU Screen umožňuje udržet relaci otevřenou i v případě, že dojde k přerušení spojení; po obnovení spojení je možné se k relaci opět připojit a pokračovat v činnosti. Také je možné se odpojit, otevřít další relace, přepínat se mezi otevřenými relacemi a přenášet mezi nimi text jako při použití schránky (clipboard).
U protokolů jako je telnet nebo FTP relace odpovídá spojení na úrovní nižšího protokolu TCP. V případě použití protokolů, které žádnou podporu pro relace nemají (UDP), nebo kde spojení typicky trvají velmi krátkou dobu (HTTP), jsou relace udržovány přímo aplikačním programem, a k tomu nutné informace jsou vkládány do přenášených dat.
Relace v protokolu HTTP dává webovému serveru možnost uložit si libovolné (většinou však ne příliš obsáhlé) informace o uživatelích, kteří k němu přistupují, a to o každém zvlášť. Protokol HTTP ze svého principu (a způsobu komunikace stylem požadavek–odpověď) postrádá kontext o jednotlivých klientech, a právě relace ho webovým aplikacím dokáže dát.
Předávání relace
Relace (přesněji odkaz na data relace) je v HTTP předávána dvěma nejrozšířenějšími způsoby:
- v URL cílové stránky – jako její proměnná
- jako HTTP cookie
Konfigurace relace
To, jakým způsobem se relace bude přenášet a pod jakým názvem, nastavuje webový server (například u Apache se název session ukládá v konfiguraci pod proměnnou nastavení session.name; použití cookies pak nastavují proměnné session.use_cookies a session.use_only_cookies popř. session.cookie_httponly, maximální délka platnosti se nastaví v proměnné session.gc_maxlifetime, která je implicitně 1440 sekund – tzn. pokud uživatel k webovému místu nepřistoupí do 24 minut od posledního požadavku, session ztrácí).
Výhody a nevýhody jednotlivých způsobů přenosu
Nevýhodou přenosu přes cookies je to, že některé archaické internetové prohlížeče je nepodporují (těch je ovšem mizivé procento) a ty soudobé dovolují cookies vypnout (opět, podíl uživatelů s vypnutými cookies je zanedbatelný). Jinou potenciální nevýhodou může být to, že pokud by potenciální útočník získal přístup k adresáři na serveru, do kterého se cookies ukládají, dostal by se i k session. Výhodou je to, že se přenáší v těle požadavku, nikolik jeho URL.
Naopak, session v URL danou adresu znepřehledňují, činí ji příliš dlouhou, nezapamatovatelnou a působí proti principům SEO (mohou dokonce „rozmělňovat“ odkazovatelnost toho kterého odkazu). Při práci s aplikací s tímto způsobem předávání se jednotlivá session navíc ukládají i do historie prohlížeče a záložek. Je-li například (proti bezpečnostním zásadám) hodnota session generovaná na základě přístupových údajů uživatele, může se k nim útočník dostat snadněji než v případě ukládání do cookies. Některé webové aplikace (např. phpMyAdmin) proto při přihlašování vyžadují možnost ukládat cookies.
Relace předávané pomocí HTTP cookie
Typickým příkladem je použití HTTP cookie k uložení jednoznačného identifikátoru (pojmenovaného SESSIONID, SESSID, SID apod., jehož hodnota je při startu session náhodně vygenerována). Podle takto uloženého HTTP cookie pak server ve své paměti najde potřebné informace, například o přihlášeném uživateli, jeho úrovni přístupu a podobně. Podstatné je, že samotná data se již nepřenášejí (ani v URL, ani v samotném požadavku).
Pokud se klient může připojit k libovolnému serveru z clusteru, je třeba mezi jednotlivými servery informace o relacích buď sdílet, nebo zajistit, že se stejný klient vždy připojí ke stejnému uzlu. V opačném případě by se klient mohl spojit se serverem, který o zahájené relaci neví, a tak přijít o přihlášení, stav nákupního košíku a podobně.
V interakci člověk-počítač se správou relací rozumí proces sledování aktivity uživatele napříč relacemi v interakci s počítačem. Typické úlohy na správu relací v desktopovém prostředí obsahují informace o tom, které aplikace jsou spuštěny a které dokumenty jimi byly využity tak, že stejný stav může být obnoven, když se uživatel odhlásí a později přihlásí. Pro webové stránky může správa relací zahrnovat potřebu se znovu přihlásit pokud vyprší platnost relace (tj. uplynula určitá lhůta bez aktivity uživatele). Používá se také k ukládání informací na straně serveru mezi HTTP požadavky.
Desktopová správa relací
Desktop session manager je program, který umožňuje uložit a obnovit relaci plochy. Relací plochy se rozumí všechna spuštěná okna a jejich aktuální obsah. Správa relací v Linux systémech se zajišťuje pomocí X session manageru. V systémech Microsoft Windows není zahrnutý žádný správce relací přímo do systému, ale správa může být poskytována pomocí aplikací třetích stran jako je twinsplay.
Správa relací v prohlížeči
Správa relací je užitečná zejména ve webovém prohlížeči, kde je uživateli umožněno uložit veškeré otevřené stránky a nastavení, které může později obnovit. Pokud dojde k pádu systému nebo aplikace, stránky a nastavení mohou být obnoveny při dalším spuštění, což pomáhá při zotavení. Google Chrome, OmniWeb a Opera jsou příklady webových prohlížečů, které podporují správu relací. Další moderní prohlížeče jako je Mozilla Firefox podporují správu relací pomocí pluginů třetích stran nebo rozšíření. Správa relací je často řízena prostřednictvím cookies.
Správa relací na webovém serveru
HTTP je statický: uživatelský počítač, na kterém je spuštěn webový prohlížeč, musí navázat nové síťové TCP připojení k webovému serveru s každým novým HTTP GET nebo POST požadavkem. Webový server proto nemůže udržovat TCP síťové připojení déle, než je doba jedné HTTP GET nebo POST operace. Správa relací je technika používaná webovými vývojáři k vytvoření statického HTTP protokolu podporující stav relace. Například jakmile je uživatel ověřen na webovém serveru, další uživatelův HTTP požadavek nepožádá znovu uživatele o přihlašovací jméno a heslo.
Informace obsažená v relaci je uložena na webovém serveru pomocí ID relace, které je generované jako výsledek prvního požadavku uživatele (webového prohlížeče). Uchovávání údajů v ID relace (uživatelské jméno, číslo účtu, atd.) na webovém serveru se provádí pomocí různých technik včetně využití lokální paměti a prostých databázových souborů.
V situacích, kde více webových serverů zároveň musí znát stav relace (jak je typické v prostředí clusteru), musí být informace o relaci sdíleny mezi uzly clusteru, které využívají software webového serveru. Mezi metody pro sdílení stavu relace mezi uzly clusteru patří:
- IP multicasting informace o relaci mezi členskými uzly (viz JGroups jako jeden příklad této techniky).
- Sdílení informací o relaci s partnerskými uzly pomocí distribuované sdílené paměti nebo virtualizace paměti.
- Sdílení informací o relaci mezi uzly pomocí síťových soketů.
- Ukládání informací o relaci na sdíleném serveru (jako je síťový systém souborů nebo globální systém souborů).
- Ukládání informací o relaci mimo cluster v databázi.
Z hlediska skriptovacích jazyků pro programování intranetových/internetových aplikací, session představuje množinu proměnných (někde přístupnou přes sadu funkcí, jinde přes globální proměnnou), které dovolují uchovávat hodnoty, které jim byly nastaveny, po dobu připojení (tj. se znovunačtením stránky se neztratí).
Například, v jazycích ASP a ASP.NET jsou přístupné automaticky jako jednotlivé prvky pole Session("klíč"), v PHP pak pod tzv. superglobálním polem $_SESSION["klíč"]. V obou příkladech lze do session ukládat „jednoduché“ typy (celá čísla, racionální čísla, řetězce, null) i z nich složená pole (teoreticky libovolné složitosti). Hodnoty se ukládají tzv. serializované (převedené na řetězec podle formátu, ze kterého jej lze zpětně načíst (přibližně jako třeba JSON)).
Zabezpečení relace funguje na tom principu, že přístup k proměnným konkrétního uživatele je možný přes jeho identifikátor v podobě dostatečně dlouhého, náhodně (nebo aspoň pseudonáhodně) generovaného, a tedy neuhádnutelného klíče. Druhé specifikum je to, že relace má poměrně krátkou dobu platnosti (implicitně [v PHP] bývá 24 minut, není-li nastaveno jinak). Samotné použití relace ovšem automaticky nezaručuje, že se k datům pomocí nich uložených dostane pouze uživatel, jemuž jsou určeny. Webové aplikace – pokud relace využívají – by současně s ním měly zavést konkrétní principy, které riziko zneužití relace minimalizují.
Únos relace (session hijacking)
Následující metody umožňují útočníkovi získat přístup k relaci své oběti. Některé z nich využívají sociální inženýrství. Všechny jsou možné, pokud je cílová webová aplikace proti těmto metodám nezabezpečená. Obecně se nazývají session hijacking.
- Session fixation – útočník na internetu uloží stránku s odkazem na zamýšlenou aplikaci a svou oběť/oběti – např. přes ICQ, e-mail, … – aby na tento odkaz klikly a přihlásily se do aplikace. Daný odkaz v cílové URL adrese již obsahuje (konstantní) HTTP cookie, která se (pokud aplikace není zabezpečena proti tomuto útoku) použije. Útočník poté použije stejný odkaz a získá stejná oprávnění jako před tím přihlášený uživatel.
- Session sidejacking – pokud se SESSIONID přenáší spolu s URL adresou, může útočník využít packet sniffing (sledování packetů), ze kterých hodnotu SESSIONID přečte a (dokud se původní uživatel neodhlásil a jeho relace nevypršela) může se pokusit přihlásit s touto SESSION.
- Pokud se session ukládají v cookies, data z nich jsou uložena na serverovém pevném disku. Dostane-li se tedy útočník k nim, může je (ty z nich, jejichž platnost ještě nevypršela) zneužít.
- Útočník může pro získání session zkombinovat sociální inženýring s útokem typu cross-site scripting, kdy přiměje uživatele již přihlášeného do aplikace spustit odkaz se záškodným kódem, jenž získá SESSIONID oběti a odešle ho útočníkovi.
Prevence
- Nejstarší webové aplikace využívající session si jejich identifikátor často stanovovaly samy. V některých případech jako zašifrované údaje související s údaji daného uživatele. Tento přístup je považován jako bezpečnostní chyba – SESSIONID by vždy měly být zcela nahodilá a dostatečně dlouhá, aby odolaly útokům hrubou silou. Současné skriptovací jazyky toto automaticky nabízejí.
- Dodatečné ověřování – po přihlášení uživatele sledovat též IP adresu klientského počítače a řetězec identifikující webový prohlížeč (označovaný jako User-agent) a v případě, že přijde další požadavek z jiné IP adresy nebo z jiného prohlížeče, session ukončit a její proměnné vymazat. Tato metoda se doporučuje implementovat, přestože nemusí být 100% účinná (v případě, že útočník a oběť mají sdílenou IP adresu (např. ve stejné firmě), a používají stejný typ prohlížeče). Nicméně řeší více metod ukradení a následného použití SESSIONID a dokáže útočníka zastavit v poslední fázi, ať už se k cizímu session dostal jakkoli.
- Proti session fixation se doporučuje regenerovat po přihlášení hodnotu SESSIONID (např. v PHP funkcí
session_regenerate_id). - Alternativně k tomu některé služby regenerují SESSIONID s každým požadavkem na server. To výrazně redukuje dobu, po kterou má útočník příležitost nabytou hodnotu SESSIONID využít.
- Šifrování přenášených dat, zejména pak SESSIONID – toto je v praxi využíváno v internetovém bankovnictví a jiných e-commerce aplikacích.
Reference
V tomto článku byly použity překlady textů z článků Session hijacking na anglické Wikipedii a Session (computer science) na anglické Wikipedii.
