Relace (informatika): Porovnání verzí

'''Session''' (v překladu ''relace'', méně častěji ''sezení'' nebo ''seance'') v [[informatika|informatice]] představuje permanentní [[Počítačová síť|síťové]] spojení mezi [[Klient (počítače)|klientem]] a [[server]]em, zahrnující výměnu [[paket]]ů.

 

U protokolů jako je [[telnet]] nebo [[File Transfer Protocol|FTP]] session odpovídá spojení na úrovní nižšího protokolu [[TCP]]. V případě použití protokolů které žádnou podporu pro sessions nemají ([[UDP]]), nebo kde spojení typicky trvají velmi krátkou dobu ([[HTTP]]), jsou session udržovány přímo aplikačním programem, a k tomu nutné informace jsou vkládány do přenášených dat.

 

Session 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ě session ho webovým aplikacím dokáže dát.

 

Session je v HTTP předáváno dvěma nejrozšířenějšími způsoby:

* v [[URL]] cílové stránky – jako její proměnná

* jako [[HTTP cookie]]

 

To, jakým způsobem se session bude přenášet a pod jakým názvem, nastavuje [[webový server]] (například u [[Apache HTTP Server|Apache]] se název session ukládá v konfiguraci pod proměnnou nastavení <tt>session.name</tt>; použití cookies pak nastavují proměnné <tt>session.use_cookies</tt> a <tt>session.use_only_cookies</tt> popř. <tt>session.cookie_httponly</tt>, maximální délka platnosti se nastaví v proměnné <tt>session.gc_maxlifetime</tt>, 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í).

<!--tady by to chtělo doplnit konfiguraci session na IIS-->

 

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 nepř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.

 

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 [[Výpočetní cluster|clusteru]], je třeba mezi jednotlivými servery informace o sessions 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é session neví, a tak přijít o přihlášení, stav nákupního košíku a podobně.

 

Z hlediska [[skriptovací jazyk|skriptovacích jazyků]] pro programování [[intranet]]ových/[[internet]]ový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 <code>Session("klíč")</code>, v [[PHP]] pak pod tzv. superglobálním polem <code>$_SESSION["klíč"]</code><!--můžete uvést i další jazyky-->. 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í session 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ě generovaného, a tedy neuhádnutelného klíče. Druhé specifikum je to, že session má poměrně krátkou dobu platnosti (implicitně bývá 24 minut, není-li nastaveno jinak). Samotné použití session 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 session využívají – by současně s ním měly zavést konkrétní principy, které rizko zneužití session minimalizují.

 

Následující metody umožňují útočníkovi získat přístup k session své oběti. Některé z nich využívají [[Sociální inženýrství (bezpečnost)|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'''.

 

* Ú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.

 

* 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 [[Brute force|ú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 adresa|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.

* Šifrování dat přenášených mezi jednotlivými stranám, zejména pak SESSIONID – toto je v praxi využíváno v [[internetové bankovnictví|internetovém bankovnictví]] a jiných [[e-commerce]] aplikacích.

 

=== Zdroje ===

{{překlad|en|Session hijacking|360241235}}

[[fi:Istunto (tietotekniikka)]]

[[fr:Session (informatique)]]

[[hy:Սեսիա (ինֆորմատիկայի ոլորտ)]]

[[it:Sessione]]