Metody udržování stavových informací v protokolu HTTP

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství

Metody udržování stavových informací v protokolu HTTP Bakalářská práce

Michal Hauzírek

Vedoucí práce: PhDr. Otakar Pinkas Září 2004

Poděkování Rád bych tímto poděkoval vedoucímu své práce PhDr. Otakaru Pinkasovi za podporu při její tvorbě a mnohé cenné podněty.

Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal. V Praze dne 2. září 2004 Michal Hauzírek

Abstrakt Tato bakalářská práce se zabývá metodami udržování stavových informací v prostředí služby WWW za užití protokolu HTTP. Jejím cílem je v teoretické části zejména zmapovat nejpoužívanější metody udržování stavových informací a jejich výhody a nevýhody. V úvodní části je jednak v souladu s technickými specifikacemi dokumentů RFC popsán samotný protokol HTTP a také důvody, proč v něm není přítomna podpora práce se stavy. Po historickém shrnutí vývoje služby World Wide Web a protokolu HTTP je diskutována potřeba přenosu stavových informací v prostředí WWW. Je konstatováno, že při udržování stavových informací na serveru je rovněž nutno udržovat na straně klienta a přenášet informaci identifikační. Základní metody přenosu informací tak mají opodstatnění v obou případech. Následuje přehled těchto metod. Ty jsou rozděleny do tří skupin. V první jsou ty, které využívají pouze vlastností protokolu HTTP. Sem patří zejména různé způsoby zakódování informací do URI či jejich odesílání metodou POST. Druhá reprezentuje rozšíření protokolu HTTP a v jejím rámci jsou popisovány tzv. cookies. Práce se zabývá jak jejich technologickými záležitostmi, jako jsou jejich jednotlivé varianty a obecná funkčnost, tak také některými dalšími okolnostmi zejména ochrany soukromí. Ve třetí skupině jsou pouze krátce naznačeny některé ostatní metody. V závěru teoretické části je v souvislosti s udržováním stavových informací na serveru a nutností ochrany identifikátoru naznačeno několik typů možných bezpečnostních problémů a některých protiopatření. Praktickou část tvoří jednak testy podpory cookies v různých prohlížečích, ale zejména tvorba aplikace, s jejíž pomocí je možné lépe analyzovat metody užité k přenosu stavových informací na konkrétních serverech.

Abstract This bachelor thesis concerns with methods of maintaining state information in the WWW environment using the HTTP protocol. Its aim in its theoretical part is to show the most frequently used methods of maintaining state information and their advantages and disadvantages. In the first part, I describe the HTTP protocol itself (according to the technical specifications in RFC documents) and I also note there some reasons for its statelessness. After historic summary of evolution of the World Wide Web service and the HTTP protocol, there is a discussion about need of maintaining states on the web. I note there the fact, that even when state is maintained on the server side, there must be some piece of information for identification purpose maintained on the client side. So there is always need for methods of transporting state information in both cases. The next text provides overview of those methods. I divided them into three groups. In the first group there are methods, that use only properties of the HTTP protocol. Those are in particular various ways of encoding information in URI or sending it via POST method. The second group represents extension of the HTTP protocol, and there I describe so-called cookies. That part concerns not only with their technological details (such as types of them and their general function), but also some other consequences especially concerning privacy. In the third group I briefly note some other methods. I suggest a few of potential security problems and some countermeasures the end of the theoretical part in connection with server-side state management and need of protection of the IDs. Practical part consists of my tests of cookies support in various browsers, and especially of implementing an application that makes it easier to analyze various methods of state information transport on particular web servers.

Obsah

Obsah Úvod................................................................................................................................................... 8 1 Protokol HTTP................................................................................................................................. 9 1.1 Základy HTTP........................................................................................................................... 9 1.2 HTTP 0.9................................................................................................................................. 10 1.3 HTTP 1.0................................................................................................................................. 11 1.3.1 Stavový řádek...................................................................................................................11 1.3.2 Hlavičky........................................................................................................................... 12 1.3.3 Metody............................................................................................................................. 13 1.4 HTTP 1.1................................................................................................................................. 14 1.4.1 Perzistentní spojení.......................................................................................................... 15 1.4.2 Podpora pro virtuální servery........................................................................................... 15 1.4.3 Určení délky..................................................................................................................... 16 1.4.4 Vyjednávání o obsahu...................................................................................................... 16 1.4.5 Spolupráce s proxy a cache.............................................................................................. 17 1.4.6 Další změny......................................................................................................................17 1.4.7 RFC 2616......................................................................................................................... 18 1.5 Shrnutí......................................................................................................................................18 2 Stavové informace.......................................................................................................................... 19 2.1 Bezstavovost protokolu HTTP.................................................................................................19 2.2 Potřeba udržování stavových informací v protokolu HTTP.................................................... 19 2.3 Stavové informace v prostředí WWW.....................................................................................20 2.3.1 Metody přenosu stavových informací.............................................................................. 20 2.3.2 Stavové informace dle významu...................................................................................... 21 2.4 Práce se stavovými informacemi v prostředí WWW mimo rámec HTTP...............................21 3 Přenos stavových informací prostředky HTTP...............................................................................23 3.1 Data zakódovaná do URI......................................................................................................... 23 3.1.1 Obecná východiska.......................................................................................................... 23 3.1.2 Data za názvem dokumentu............................................................................................. 24 3.1.3 Data před názvem dokumentu..........................................................................................25 3.2 Formulářová pole..................................................................................................................... 26 3.3 HTTP autentizace.................................................................................................................... 27 3.4 IP adresa...................................................................................................................................28 3.5 Hlavička From......................................................................................................................... 29 4 Cookies........................................................................................................................................... 30 4.1 Základní funkce cookies.......................................................................................................... 30 4.2 Specifikace Netscape............................................................................................................... 30 4.2.1 K původu termínu „cookie“............................................................................................. 31 4.2.2 Hlavička Set-Cookie........................................................................................................ 31 4.2.3 Chování klienta a hlavička Cookie.................................................................................. 33 4.3 RFC 2109.................................................................................................................................33 4.3.1 Okolnosti vzniku.............................................................................................................. 33 4.3.2 Nedostatky specifikace Netscape..................................................................................... 34 4.3.3 Neověřitelné transakce a cookies třetích stran................................................................. 34 4.3.4 Hlavní změny v RFC 2109...............................................................................................35 4.4 RCF 2965 a 2964..................................................................................................................... 36 Strana 6

Obsah

4.4.1 Nekompatibilita Internet Exploreru................................................................................. 37 4.4.2 Další diskutovaná témata................................................................................................. 37 4.4.3 Změny v RFC 2965.......................................................................................................... 38 4.4.4 Velké zpoždění a neúspěch RFC2965..............................................................................38 4.5 Cookies a ochrana soukromí....................................................................................................39 4.5.1 Cookies třetích stran a reklama........................................................................................ 39 4.5.2 P3P................................................................................................................................... 41 4.5.3 Mýty okolo cookies.......................................................................................................... 42 4.6 Test podpory v prohlížečích.....................................................................................................43 4.6.1 Testované prohlížeče........................................................................................................43 4.6.2 Základní možnosti uživatelského nastavení práce s cookies........................................... 43 4.6.3 Podpora cookies dle specifikace Netscape.......................................................................45 4.6.4 Podpora cookies dle RFC 2109........................................................................................47 4.6.5 Podpora cookies dle RFC 2965........................................................................................48 4.6.6 Shrnutí výsledků...............................................................................................................49 5 Udržování stavových informací na serveru.................................................................................... 50 5.1 Ukládání stavových informací ................................................................................................ 50 5.2 Ohrožení identifikátorů relací.................................................................................................. 50 5.2.1 Odhadnutí.........................................................................................................................51 5.2.2 Odposlechnutí z komunikace........................................................................................... 51 5.2.3 Hlavička Referer.............................................................................................................. 51 5.2.4 Některé možnosti ochrany před zneužitím identifikátoru................................................ 51 5.3 Shrnutí......................................................................................................................................52 6 A.S.I.A.T........................................................................................................................................ 53 6.1 Uživatelské rozhraní................................................................................................................ 53 6.2 HTTP klient............................................................................................................................. 53 6.3 Práce se stavovými informacemi............................................................................................. 54 6.3.1 Cookies.............................................................................................................................54 6.3.2 Formuláře......................................................................................................................... 55 6.3.3 Odkazy a URI...................................................................................................................55 6.4 Návrh aplikace......................................................................................................................... 56 Závěr................................................................................................................................................. 57 Rejstříky vložených tabulek a obrázků.............................................................................................58 Seznam použité literatury................................................................................................................. 59 Seznam použitých zkratek a termínů................................................................................................62

Strana 7

Úvod

Úvod Služba WWW (World Wide Web) postavená mimo jiné na protokolu HTTP1 se stala bezesporu nejpopulárnější službou internetu vůbec. Zdaleka již neslouží pouze několika málo vědcům a zdaleka již také neslouží pouze pro publikování statických dokumentů. Jejím prostřednictvím je rovněž přistupováno k rozsáhlý aplikacím a bývá také užívána jako brána k některým ostatním službám internetu. S tím je však v rozporu od prvopočátků bezstavový charakter protokolu HTTP. S tím mám také vlastní zkušenosti i proto, že jsem také já osobně v minulosti s tvorbou webových aplikací již také několikrát přišel do styku a byl tak nucen se problematikou stavových informací do jisté míry prakticky zabývat. To byl také jeden z hlavních důvodů, proč jsem si právě tuto problematiku zvolil jako téma své bakalářské práce. Stavové informace je v takových případech nezbytné pro správné fungování těchto dynamických aplikací za pomoci protokolu HTTP nebo některých jeho rozšíření udržovat a přenášet. Právě metody udržování stavových informací v protokolu HTTP jsou tématem této práce. Jejím cílem je na vymezeném prostoru na pozadí vzniku a postupného vývoje protokolu HTTP popsat základní metody pro udržování a přenos stavových informací v prostředí služby WWW. V základním pohledu budou rozděleny na metody udržování na straně klienta a na straně serveru. Jak bude ukázáno, v praxi je ovšem při obou způsobech nutné zajistit přenos určitých informací mezi klientem a serverem. Zmíním se proto zejména o metodách přenosu. A to jak o těch velmi často užívaných, tak i o těch, jejichž použití připadá do úvahy spíše pouze teoreticky. U každé z metod se pokusím upozornit na její nevýhody a nedostatky a naproti tomu také na přednosti, kterými vyniká nad ostatními. Přitom budu do značné míry abstrahovat od otázek spojených s problematikou cacheování a omezím se zejména na otázky přímé komunikace výchozího klienta s cílovým serverem. Poměrně rozsáhle se v teoretické části hodlám zejména ve 4. kapitole věnovat rozšíření protokolu HTTP právě pro udržování a přenos stavových informací (tzv. cookies). Chtěl bych se tomuto tématu věnovat nejen z čistě technologického hlediska, ale také se dotknout souvislostí, které jednak vedly k praktickému ustrnutí jeho dalšího vývoje a také k relativně velké publicitě této problematiky mezi širší veřejností. Tomuto tématu bude věnována i menší část praktického příspěvku této práce – totiž otestování několika významných prohlížečů právě na podporu cookies. Zásadní podíl na praktické části si však vyžádá tvorba aplikace, která by měla usnadnit právě analýzu stavových informací na konkrétních serverech zejména co do metody jejich přenosu.

1 Jsem si vědom toho, že 'P' v této zkratce znamená protocol (tedy česky protokol) a užití tohoto slova spolu s ní je tak logicky nadbytečné. Toto spojení však nejen lépe zní, ale hlavně se takto objevuje i samotné originální specifikaci [43]. Budu jej tedy užívat v této práci i nadále.

Strana 8

Kapitola 1: Protokol HTTP

1 Protokol HTTP Protokol HTTP je spolu s jazykem HTML a schématem URI2 jedním ze tří základních pilířů dnes zřejmě celosvětově nejpoužívanější internetové služby WWW (World Wide Web). Služba WWW se postupně vyvinula z prostředku pro sdílení zejména textových informací mezi vědci ve zcela nové médium, které slouží jako brána pro přístup k jiným službám a to již zdaleka ne pouze internetovým. Je to nyní mimo jiné také specifický marketingový kanál, kterým je možno oslovit široké spektrum zákazníků. Tato poměrně velice výrazná změna jak kvantitativní (počet serverů a koncových uživatelů), tak zároveň i kvalitativní (z toho se odvozující požadavky na funkce a vlastnosti) musely v průběhu času vést k určitým změnám a vylepšením v samotných základech WWW – tedy i v protokolu HTTP.

1.1 Základy HTTP Základní filosofie a funkčnost protokolu HTTP zůstala ve všech verzích stejná. Proto ji ukážeme na prvním místě a v dalších subkapitolách potom uvedeme pouze změny a dodatky, které byly k těmto základním principům dodatečně přidány. HTTP je bezstavovým (viz kapitolu 2) aplikačním protokolem. V prostředí internetu tedy tvoří nejvyšší vrstvu nad vrstvou transportní (tvořenou zejména protokolem TCP) a vrstvou síťovou (protokol IP). Komunikace je založena na principu klient/server. HTTP klient (často prohlížeč ale například i proxy server) naváže spojení s HTTP serverem a otevře přenosový kanál. Standardně je pro protokol HTTP na serveru vyhrazen port 80. HTTP neslouží pouze ke komunikaci s WWW servery, ale i ke komunikaci s některými dalšími typy serverů – například proxy. Samotná komunikace protokolem HTTP je založena na principu požadavek/odpověď (request/response). Klient po otevření přenosového kanálu odešle serveru požadavek, kterým mu sdělí, jaký dokument po něm vyžaduje. Server odešle klientu odpověď obsahující požadovaný dokument (resp. zprávu o chybě, pokud takový dokument z libovolného důvodu nemůže poslat3). Server po odeslání odpovědi přenosový kanál uzavře a spojení ukončí. Pokud si chce klient vyžádat od serveru další dokument, celý postup (včetně otevření nového přenosového kanálu4) se opakuje. Komunikace, jak byla popsána nemusí probíhat přímo mezi koncovým klientem (webovým prohlížečem uživatele) a cílovým serverem, na kterém se nachází požadovaný dokument. Mezi nimi může existovat několik prostředníků či zprostředkovatelů. Ti mohou, například v podobě proxy serveru, fungovat jako server ve vztahu k prohlížeči a jako klient ve vztahu k cílovému serveru (případně dalšímu prostředníkovi). Je také možné, že některý z prostředníků má požadovaný dokument uložený z některého z předchozích požadavků, které jím procházely. V takovém případě ho za daných podmínek5 může vrátit klientu (koncovému uživateli nebo předcházejícímu prostředníkovi) jako odpověď (tzv. caching). Popsané situace znázorňují následující obrázky. Obrázek 1 ukazuje situaci několika dotazů přímo na cílový server. Obrázek 2 požadavky několika koncových klientů, které procházejí přes proxy server. 2 Dříve se v souvislosti s WWW častěji užívalo v témž smyslu spíše termínu URL K této problematice viz [54] a [42]. 3 Může jít o prostý případ, kdy se požadovaný dokument na serveru nenachází, ale také například když k jeho získání nemá server (nebo klient) potřebná oprávnění. Nastat může i situace, kdy dojde na straně serveru k chybě apod. 4 S výjimkou tzv. perzistentního spojení definovaného v HTTP 1.1 (viz subkapitolu 1.4.1) případně v některých rozšířených implementacích HTTP 1.0. 5 Například stáří takového dokumentu, to, zda si jeho autor přeje, aby byl po cestě ukládán, zda koncový uživatel chce přijmout uloženou verzi dokumentu apod.

Strana 9

Kapitola 1: Protokol HTTP

Na obrázku 3 je zachycena situace, kdy je prostředníkem na cestě mezi koncovým klientem a cílovým serverem (CS) jiný proxy server, který pracuje také jako cache. V zobrazeném případě má tento server k dispozici dostatečně čerstvou uloženou kopii požadovaného dokumentu a proto ji může klientovi odeslat místo cílového serveru a ušetřit tak přenosové kapacity.

Obrázek 1: Opakovaný požadavek v HTTP s vyznačením otevíraných spojení

Obrázek 2: Použití proxy serveru

Obrázek 3: Použití cache v HTTP

1.2 HTTP 0.9 První verze protokolu HTTP (v současnosti se o ní mluví jako o verzi HTTP 0.9 ač se tak původně nenazývala) byla velmi jednoduchá[5]. Pro původní účely tj. přenos hypertextu (textových dokumentů provázaných odkazy) protokol docela dobře postačoval. Základní struktura již byla naznačena výše. Formát požadavku sestával z jediné řádky textu. Na začátku bylo klíčové slovo GET, následovala mezera, potom adresa dokumentu bez jména serveru a portu tedy pouze její část s cestou tj. od znaku /. Celý požadavek byl zakončen znaky pro konec řádku (CR LF). Odpověď serveru tvořil samotný dokument v jazyce HTML. Jiný formát se nepředpokládal a ani nebyl dovolen. Prostý text měl být odesílán rovněž jako HTML dokument v tagu . Případnou chybu měl server oznámit stejným způsobem – odeslat HTML dokument s popisem chyby. V této verzi protokolu tedy nebylo možné nijak automatizovaně rozeznat úspěšný přenos od chyby, neboť jediný kdo mohl rozeznat výsledek, byl člověk, který si získaný dokument přečetl. Následuje jednoduchý příklad požadavku a odpovědi v HTTP 0.9 (požadavek je kurzívou): GET /index.htm <html> ... </html> Strana 10 Kapitola 1: Protokol HTTP 1.3 HTTP 1.0 Výše popsaný velice jednoduchý protokol si s sebou nesl několik problémů. Jedním z nich bylo to, že jediný způsob, kterým se klient mohl dozvědět délku získávaného dokumentu, bylo ukončení spojení se serverem6. S rozšiřováním požadavků na WWW (a vylepšováním jazyka HTML) vyvstal také problém s přenosem jiných typů dokumentů (zejména obrázků). Obrázky vložené v HTML dokumentech jsou samostatné soubory s vlastním URI – získávají se tedy samostatným HTTP požadavkem. Bylo proto žádoucí, aby klient mohl dopředu rozpoznat typ získávaného dokumentu a mohl ho odpovídajícím způsobem interpretovat7. Dalším problémem raných verzí tohoto protokolu je již zmiňovaná nemožnost automaticky detekovat chybu v komunikaci. Objevila se také potřeba určité interaktivity – tj. schopnosti zasílat serveru data pro další zpracování. Původní jednoduchý koncept HTTP 0.9 tak byl rozvinut do komplexnějšího protokolu označovaného jako HTTP 1.0. Tato verze je popsána v dokumentu RFC 1945[38] vydaném v únoru 1996. Tento dokument však není standardem ve smyslu, že by předepisoval správné postupy a metody práce HTTP 1.0. Jde o ex-post sepsaný dokument, který reflektoval soudobý stav implementace HTTP. Hlavní změny oproti HTTP 0.9 spočívají zejména v rozšíření odpovědi serveru z pouhého těla dokumentu o stavový řádek a hlavičky s meta informacemi. Také požadavek lze rozšířit o hlavičky, které jsou však nepovinné. 1.3.1 Stavový řádek Jeden z dříve nastolených problémů původní verze HTTP – totiž nerozlišitelnost chybového hlášení od dokumentu je od této verze řešena zavedením stavového řádku. Odpověď serveru již není pouze samotný dokument, předchází mu stavový řádek a většinou ještě hlavičky. Stavový řádek je první řádek odpovědi, který má přesně danou strukturu. Začíná označením použité verze HTTP tj. znaky HTTP/ s číslem verze v desetinném formátu (zde tedy 1.0). Následuje mezera a trojciferný kód, který udává výsledek operace. Stavový řádek pokračuje mezerou odděleným slovním popisem kódu a končí znaky konce řádku (CR LF). Klient tedy může automaticky podle kódu zjistit, jaký byl výsledek požadavku. Programu je srozumitelný číselný kód a uživateli může být zobrazen slovní popis8. Stavové kódy jsou rozčleněny do pěti tříd. Kódy začínající číslicí 2 (tedy čísla v rozmezí 200 až 299) značí úspěch. Počáteční číslice 3 potom uvádí přesměrování na jinou adresu. Čtvrtá třída znamená neúspěch způsobený chybou na straně klienta a poslední pátá chybu na straně serveru. Stavové kódy začínající jedničkou jsou vyhrazeny jako informativní a v HTTP 1.0 není žádný definován. Jinak RFC 1945 uvádí význam celkem patnácti kódů z ostatních tříd. Kódy dělitelné stem jsou obecné a reprezentují celou třídu. Pokud klient nerozumí některému konkrétnímu kódu, může jej interpretovat tak, jako by to byl právě tento obecný. Problém identifikace chyb byl tedy vyřešen stavovým řádkem. Další problémy, týkající se typu dokumentu a jeho délky řeší hlavičky. 6 Teoreticky by přicházela v úvahu kontrola obsahu a hledání tagu </HTML>, který značí konec HTML dokumentu. Tento způsob je však nevhodný hned z několika důvodů: zasahuje o úroveň níže pod samotný protokol. Navíc je použitelný pouze pro HTML dokumenty (a to ještě pouze ty se správnou strukturou). 7 Podobně jako GOPHER klient rozlišuje menu, textový soubor, binární soubor apod. 8 Případně může program podle kódu zobrazit jiný vysvětlující text například v jazyce uživatele. Strana 11 Kapitola 1: Protokol HTTP 1.3.2 Hlavičky Mechanismus hlaviček byl přebrán z podobného konceptu hlaviček internetové pošty. Hlavičky se odesílají před samotným dokumentem a každá je tvořena jedním řádkem textu. Hlavička sestává z názvu a hodnoty. Název a hodnota jsou odděleny dvojtečkou a celá hlavička je zakončena znaky pro konec řádku (CR LF). Od těla odpovědi respektive požadavku9 se hlavičky oddělují jedním prázdným řádkem (tedy kombinací znaků CR LF). Hlavičky poskytují dodatečné informace k přenášenému dokumentu a k požadavku respektive odpovědi. RFC 1945 uvádí základních šestnáct hlaviček10. V příloze D, kde jsou uvedeny některé další vlastnosti podporované pouze v několika implementacích, je jich potom dalších deset11. Podle toho, ke které části komunikace se váží, lze hlavičky rozdělit do čtyř skupin. Obecné hlavičky (General-Header) se váží pouze k danému spojení. V hlavičce Date je uvedeno datum jeho uskutečnění a hlavička Pragma byla určena pro případné prostředníky při spojení (konkrétně cache). Další skupinu tvoří hlavičky požadavku (Request-Header). Ty odesílá klient a týkají se tohoto konkrétního požadavku12. Kromě autentizačních údajů, identifikace klientského programu a hlavičky pro podmíněný požadavek jsou pro další kapitoly zajímavé zejména následující dvě hlavičky z této skupiny. První z nich je Referer13, která jako svou hodnotu obsahuje URI dokumentu, ze kterého byl uživatel na požadovaný dokument odkázán. Totéž platí i pro požadavky na vložené objekty (například obrázky), v tomto případě se jako referer odešle URI dokumentu obsahujícího tento objekt. Autor či správce webu tak může analýzou těchto údajů zjistit, odkud na jeho stránky návštěvníci přicházejí a v případě změny struktury webu může autory příslušných odkazujících stran informovat. Zároveň však může tato hlavička znamenat v jistých případech a při nesprávně navrženém zabezpečení webové aplikace určité riziko – viz kapitolu 5. Některé prohlížeče (také s přihlédnutím k určitému stupni „narušení soukromí“) umožňují tuto hlavičku neodesílat, případně odesílat ji v pozměněné podobě. Hlavička From by měla obsahovat elektronickou adresu uživatele zodpovědného za odeslaný požadavek. Původně měla zřejmě sloužit pro případné upozornění uživatelů, kteří zasílali určitým způsobem nesprávné požadavky. Dnes je ale používána jen v minimu případů (například automatické programy pro indexování apod.). V běžných případech není prohlížeči odesílána, neboť by tím docházelo k obdobné situaci jako u cookies třetích stran – viz dále (navíc zhoršené tím, že by byla odesílána s úplně všemi požadavky). A nejen to – internetová poštovní adresa může do jisté míry identifikovat konkrétního uživatele, navíc by na ni v důsledku takovéhoto rozšiřování začalo velmi rychle přicházet velké množství nevyžádané reklamní pošty. Třetí skupinou jsou hlavičky odpovědi (Response-Header). Ty umožňují serveru představit svůj software, přesměrovat klienta na jinou adresu, případně ho vyzvat k zadání autentizačních údajů. A konečně poslední skupinou jsou hlavičky, které se váží k tělu odpovědi respektive požadavku (Entity-Header). Ty popisují přenášený dokument – tedy jeho typ (Content-Type), dále datum poslední úpravy (Last-Modified), případné transformace (například komprimace) (Content9 10 11 12 13 Jak bude uvedeno dále, HTTP 1.0 umožňuje pomocí metody POST odesílat data také v požadavku. 2 general, 5 request, 3 response a 6 entity – viz dále rozdělení hlaviček 1 general, 4 request, 1 response a 4 entity – viz dále rozdělení hlaviček V případě hlavičky Referer jde však jistým způsobem spíše o požadavek předcházející – viz dále. Správný název by dle anglického pravopisu měl zřejmě být Referrer (tedy s dvěma 'r'), tato „chyba“ je však již vžitá a hlavně implementovaná v mnoha HTTP klientech i serverech Strana 12 Kapitola 1: Protokol HTTP Encoding) a samozřejmě délku v bytech (Content-Length). V případě, že délka není uvedena, platí nadále, že dokument končí ukončením spojení. 1.3.3 Metody HTTP ve verzi 1.0 rozšiřuje možnosti také tím, že zavádí dvě nové metody, kterými lze komunikovat se serverem. Kromě metody GET již známé z předchozí verze, to jsou metody POST a HEAD. V již jednou zmiňované příloze D dokumentu RFC 1945 jsou popsány mj. ještě metody pro vytváření a mazání souborů na serveru (PUT a DELETE). Odlišná metoda v požadavku způsobí odlišné zpracování tohoto požadavku serverem. Jméno metody tvoří první část prvního řádku požadavku. Pomocí metody HEAD klient serveru sděluje, že nechce získat tělo dokumentu ale pouze příslušné hlavičky. Odpověď na tuto metodu je tedy stejná (co se týče hlaviček a stavového řádku), jako kdyby požadavek přišel metodou GET, ovšem bez samotného těla dokumentu. To je výhodné například při testování platnosti odkazů, kdy je potřeba pouze zjistit, zda cílový dokument existuje a není třeba si vyžadovat jeho obsah. Oproti tomu metoda POST umožňuje klientu odeslat spolu s požadavkem (v jeho těle) data, která server zpracuje. Může jít například o data odeslaná z HTML formuláře. Jejich délka však musí být výslovně uvedena v hlavičce Content-Length a to z toho zřejmého důvodu, že zde nelze použít pro určení jejich délky konec spojení. Pokud by totiž klient během odesílání svého dotazu uzavřel přenosový kanál, nemohl by jím server vrátit svou odpověď. Pro odlišení požadavku verzí 0.9 a 1.0 se ve verzi 1.0 za adresu dokumentu vkládá mezerou oddělené označení verze ve stejném formátu, jaký je použit ve stavovém řádku odpovědi (tedy HTTP/1.0). V HTTP 1.0 totiž musí server počkat ještě na případné hlavičky. Opět následují dva jednoduché příklady požadavků a odpovědí ve verzi HTTP 1.0: GET /index.html HTTP/1.0 (prázdný řádek ukončující hlavičky) HTTP/1.0 200 OK Date: Wed, 1 Aug 2001 10:56:00 GMT Server: Apache/1.3.7 (FreeBSD) Content-Length: 29644 Content-Type: text/html; charset=iso-8859-2 (...) --------------------------------------------POST /index.php HTTP/1.0 Content-Length: 10 1234567890 HTTP/1.0 404 Not Found Date: Wed, 1 Aug 2001 11:00:29 GMT Server: Apache/1.3.7 (Win32) Content-Length: 301 Content-Type: text/html; charset=iso-8859-1 (...) Strana 13 Kapitola 1: Protokol HTTP 1.4 HTTP 1.1 Rychlý růst popularity služby WWW jak mezi koncovými uživateli, tak mezi poskytovateli obsahu, kteří se stále více rekrutovali z řad obchodníků (které samozřejmě lákal rostoucí počet uživatelů jako potenciálních zákazníků) s sebou přinášel, co se týče protokolu HTTP, zejména dva další problémy. Nebyly to problémy nové, oba lze snadno vystopovat již od počátků, ovšem dokud bylo uživatelů poměrně málo a přenášené HTML dokumenty relativně jednoduché, nijak výrazně se neprojevovaly. Prvním problémem je to, že jak již bylo řečeno a jak to dobře ukazuje Obrázek 1 na straně 10, během jednoho spojení je možné přenést pouze jeden dokument. Poměrně náročná operace navázání spojení tak musí být mnohokrát opakována v případech, kdy je k jednomu HTML dokumentu připojeno několik dalších dokumentů (zejména obrázků, ale i skriptů, souborů stylů, animací a podobně). Pokaždé je přenesen pouze jeden takový objekt a spojení je opět uzavřeno. Tímto způsobem se prohlížení takových graficky bohatých dokumentů stává pomalým a náročným na výkon. Další problém souvisí s tím, že v požadavku se nikde neobjevuje jméno serveru, které je součástí adresy dokumentu. HTTP klient si z úplné adresy dokumentu (například dotazem na DNS server) zjistí IP adresu koncového serveru a naváže s ním spojení. V požadavku se pak objevuje pouze část adresy za jménem serveru (a případným portem). Tato situace tedy předpokládá, že pro každé jméno serveru použité v URI, existuje jiná IP adresa14. Takto byl původní protokol skutečně koncipován. Problém však nastal v době, kdy se vlastnictví vlastního lukrativního doménového jména (samozřejmě spolu s na něm běžícím HTTP serverem) stalo prestižní či ještě o něco později módní záležitostí. Navíc se stále rostoucí oblibou WWW si chtěly společnosti vytvářet WWW servery nejen s názvy svých firem, ale rovněž s názvy značek svých výrobků. Někteří lidé zase toužili po doménovém jménu odpovídajícím jejich jménu skutečnému. Tato fakta ještě více zhoršila situaci, kdy začalo hrozit brzké vyčerpání dostupných 32-bitových IP adres15. Bylo tedy žádoucí umožnit na jedné IP adrese (na jednom portu) provozovat více oddělených virtuálních serverů s odlišnými doménovými jmény. Jinými slovy bylo potřeba do samotného protokolu HTTP nějakým způsobem dodat podporu pro doménová jména. Tyto dva důvody patřily mezi hlavní impulsy pro další verzi protokolu – HTTP 1.1. První z problémů byl vyřešen zavedením perzistentních spojení, druhý potom povinnou hlavičkou požadavku Host. Kromě toho byly do protokolu zakomponovány některé další vlastnosti jako například podpora vyjednávání o obsahu a částečných přenosů. V neposlední řadě do specifikace přibylo velké množství textu týkajícího se spolupráce s proxy a cache servery a rovněž jejich správným chováním. První schválenou a uveřejněnou verzí protokolu HTTP 1.1 je dokument RFC 2068 z ledna roku 1997 [39]. Ten byl nahrazen dalším dokumentem RFC 2616 uveřejněným v červnu 1999 [43]. Změny mezi těmito dvěma dokumenty nejsou zdaleka tak výrazné (číslo verze také zůstalo stejné tedy 1.1) a ještě o nich bude řeč. Oba dokumenty byly (na rozdíl od RFC 1945) vydány jako standardy IETF. 14 Pokud abstrahujeme od jiných portů, než výchozího tj. 80. 15 Tento problém nebyl způsoben pouze protokolem HTTP, ale má hlubší kořeny v samotném systému fungování a přidělování adres. Blíže k tomuto problému a jeho řešením, která se netýkají protokolu HTTP viz např. [34] Strana 14 Kapitola 1: Protokol HTTP 1.4.1 Perzistentní spojení V předchozích odstavcích naznačený koncepční nedostatek způsoboval při mnohonásobných opakovaných požadavcích potíže jak na straně klientů, tak na straně serverů a snižoval výkonnost na obou stranách (k dané problematice viz například [52]). Dobrým řešením se ukázalo být perzistentní spojení. Tím se myslí ta skutečnost, že server po odeslání odpovědi neuzavře ihned přenosový kanál, ale ponechá jej po nějaký (krátký) časový interval otevřený. Klient jím posléze může poslat další svůj případný požadavek16. Odpadá tím nákladné ukončování a znovunavazování spojení. Dle slov autorů standardu nebylo zejména kvůli možným problémům se staršími proxy servery možné identifikovat užití perzistentního spojení nějakou speciální hlavičkou. Ty by je totiž (jakožto jim neznámé) mohly přeposílat dál, přestože tento způsob práce sami nepodporují. Pokud by se potom spojily se serverem, který takto pracovat umí, mohly by s odesláním odpovědi čekat teprve do uzavření spojení s koncovým serverem, což by práci s nimi výrazně zpomalilo. Perzistentní spojení tak bylo zvoleno za výchozí stav pro verzi protokolu HTTP 1.1. Pokud kterákoli ze stran komunikace nechce použít perzistentního spojení, odešle ve své zprávě hlavičku Connection: close. V případě popsaném výše (starší proxy server) koncový server perzistentní spojení neužije, neboť požadavek na něho bude ve verzi HTTP 1.0, kde toto není implicitní. Perzistentní spojení je možné využít také k odeslání více požadavků bez nutnosti čekat na jednotlivé odpovědi (tzv. pipelining). Tím je možné také do jisté míry zlepšit efektivnost přenosu, nicméně ne všechny HTTP servery tuto možnost (korektně) podporují a to v některých případech může vést namísto ke zrychlení a zefektivnění komunikace k pravému opaku. Obrázky 4 a 5 znázorňují perzistentní spojení a pipelining (srov. s obrázkem 1 na straně 10). Obrázek 4: Opakovaný požadavek v HTTP při perzistentním spojení Obrázek 5: Opakovaný požadavek v HTTP při perzistentním spojení a pipeliningu 1.4.2 Podpora pro virtuální servery Druhý ze zásadních problémů, které se k předchozí verzi protokolu HTTP vázaly, byl vyřešen pomocí nové hlavičky požadavku17. Ta nese název Host a jejím obsahem je doménové jméno serveru (včetně případného portu), ze kterého klient požaduje zaslat odpověď. Tato nová hlavička je, na rozdíl od všech ostatních hlaviček požadavku, ve verzi 1.1 povinná. Pokud server obdrží HTTP 1.1 požadavek, který ji neobsahuje, musí odpovědět chybovým hlášením s kódem 400 – tj. „chybný požadavek“. Tak je možné úspěšně provozovat na jedné IP adrese velké množství virtuálních serverů. Pokud na konkrétní IP adrese není provozováno více virtuálních serverů, pracuje vše tak, jak bylo naznačeno dříve. Jestliže jich tam více existuje, software serveru podle hlavičky Host, kterou si 16 Tím se ovšem nic nemění na tom faktu, že každý z požadavků je nezávislý a s každým se zachází tak, jako by byl první. Protokol i tak zůstává bezstavový, jedinou změnou je, že se v jednom přenosovém kanálu „vyřídí“ více požadavků. 17 Jinou možností řešení, která se nabízela bylo přidání doménového jména přímo adresy požadavku resp. přechod na absolutní adresy v požadavku. Strana 15 Kapitola 1: Protokol HTTP přečte v požadavku, zvolí dokument například z odpovídajícího adresáře a ten vrátí. Standard RFC 2068 rovněž požaduje, aby s požadavky, které obsahují úplnou URI adresu (tedy včetně doménového jména), uměly pracovat nejen proxy18, ale také ostatní servery. V některé z potenciálních budoucích verzí HTTP by tak mohlo dojít k případnému úplnému přechodu na absolutní URI ve všech požadavcích. 1.4.3 Určení délky Již dříve bylo řečeno, že délka odpovědi se určovala nejprve uzavřením spojení ze strany serveru (což nebylo zcela vyhovující), později potom pomocí hlavičky Content-Length. Ta musí být samozřejmě odeslána již před samotným dokumentem. U statického obsahu není pro server problém zjistit velikost souboru, který bude odeslán. S příchodem dynamicky generovaných dokumentů však může nastat potíž. Ta spočívá v očividném faktu, že server nemusí předem vědět, jak dlouhý obsah bude (například externí aplikací či CGI skriptem) vygenerován. Pokud se jedná o poměrně malý objem dat, jehož generování navíc trvá velmi krátkou dobu, může server, na jeho skončení „počkat“ a odeslat jej celý najednou s příslušnou hlavičkou označující délku. Naproti tomu probíhá-li vytváření obsahu pomalu, nebo je-li dat velké množství, vznikají nepříjemné prodlevy. V takovém případě by určitým řešením byl jakýsi krok zpět, totiž neodesílat hlavičku s údajem o velikosti a data posílat postupně tak, jak jsou vytvářena. Klient by potom jejich délku určil koncem spojení. Tento přístup však není možný, bude-li využito výhod perzistentního spojení (viz výše). Po odeslání dokumentu se totiž spojení po nějakou dobu neuzavírá. HTTP 1.1 proto přichází s jiným řešením nastíněného problému. Tím je „chunked encoding“19 tj. jistý způsob zakódování přenášených dat tak, že jsou posílána po částech a každá z těchto částí je uvozena svou vlastní délkou. Délka kažné takové části se uvádí na samostatném řádku odpovědi jako hexadecimální číslo vyjadřující počet bytů této části. Následuje řádek s příslušnými daty. Úplný konec dokumentu je signalizován řádkem oznamujícím nulovou délku. Za ním mohou ještě následovat některé HTTP hlavičky týkající se přenášeného dokumentu (tzv. footer20). Použití tohoto způsobu přenosu se označuje hlavičkou Transfer-Encoding: chunked. Na rozdíl od předchozí verze, kdy byla délka určována hlavičkou Content-Length a v případě její nepřítomnosti ukončením spojení, v HTTP 1.1 je spektrum možností, jak určit délku mnohem pestřejší. Standard stanovuje následující pořadí. Odpovědi, u kterých nikdy není přenášeno žádné tělo dokumentu (např. odpovědi na HEAD či některé stavové kódy), končí ihned za hlavičkami. Pokud je použito výše popsané kódování, určí se délka podle něho. Jinak platí hlavička ContentLength a až poté ukončení spojení21. 1.4.4 Vyjednávání o obsahu V této verzi protokolu se objevuje několik hlaviček, které umožňují implementovat tzv. vyjednávání o obsahu (content negotiation). S rozvojem a rozšířením internetu a jeho globálním působením může být žádoucí, aby jeden zdroj byl dostupný v různých svých verzích (například jazykových). Kromě toho, pro přístup k WWW je možné používat různé prohlížeče na různých zařízeních, jejichž zobrazovací schopnosti nejsou stejné. Pomocí vyjednávání o obsahu mohou klient a server 18 Požadavek posílaný přes proxy server musí samozřejmě obsahovat doménové jméno cílového serveru. Toho je dosaženo právě uváděním absolutních URI v požadavcích. 19 z anglického chunk – kus, odřezek 20 V novější verzi HTTP 1.1 tj. RFC2616 je nazýván trailer. 21 Ve skutečnosti v této posloupnosti ukončení spojení předchází ještě přenos pouze určené části dokumentu (rozmezí bytů), kde je délka dána explicitně. Strana 16 Kapitola 1: Protokol HTTP poskytnout uživateli nejvhodnější podobu požadovaného zdroje (jazykovou mutaci, složitost grafiky apod.). RFC 2068 popisuje tři způsoby vyjednávání. Prvním je vyjednávání řízené serverem (serverdriven). V tomto případě server analyzuje hlavičky, které získal od klienta22 a na jejich základě (případně i z dalších informací23) se rozhodne, kterou z dostupných reprezentací vrátí. V případě klientem řízeného vyjednávání (agent-driven) server vrátí seznam dostupných reprezentací a klient automaticky jednu vybere, či umožní výběr přímo uživateli. Posledním způsobem je transparentní vyjednávání (transparent), které je kombinací obou předchozích. Blíže k této problematice viz [41]. Obrázek 6 ukazuje příklad vyjednávání o obsahu řízeného serverem24 způsobem, jakým je například použito ve vyhledávači Google <http://www.google.com/>. ... Obrázek 6: Příklad vyjednávání o obsahu v HTTP 1.4.5 Spolupráce s proxy a cache Nově je ve specifikaci HTTP 1.1 věnováno mnoho prostoru spolupráci klientů a serverů s proxy a zejména cache. Je zde definován model pro práci s uloženými dokumenty25 a mnoho hlaviček pro popis jejich vlastností užívaných právě k těmto účelům. Dále jsou uvedena standardní pravidla pro chování proxy a cache serverů a další hlavičky, které umožňují tato výchozí pravidla pro konkrétní dokumenty či požadavky měnit. Toto téma je zpracováno skutečně podrobně a svým rozsahem přesahuje okruh zájmu této práce. 1.4.6 Další změny Výše popsané nebyly ani zdaleka veškeré změny a novinky, které se v nové verzi objevily. HTTP 1.1 je poměrně velmi rozsáhlým a komplexním protokolem. Pro představu snad uveďme, že zatímco RFC 1945 má bez příloh 54 stran (s přílohami 60), tak RFC 2068 jich bez příloh má celých 150 (a s přílohami ještě o dvanáct více). I z těchto počtů je tedy zřejmé, že jsme zcela jistě nemohli vyčerpat kompletní přehled změn. Výše zmíněné jsou však těmi nejpodstatnějšími. Z těch zbývajících zde okrajově zmíníme ještě několik. Jak jsme již naznačili, byla zavedena podpora pro vyžádání a přenos neúplných dokumentů (pouze určité rozmezí bytů) například pro navázání stahování již částečně stažených dokumentů. Dále přibyly čtyři nové metody – již zmiňované PUT a DELETE a k nim nově ještě OPTIONS umožňující zjistit vlastnosti určitého dokumentu a TRACE, kde je jako odpověď vrácen požadavek tak, jak došel na cílový server. Celkový počet stavových kódů byl rozšířen na 37 a přibylo na třicet nových hlaviček. 22 HTTP 1.1 pro tento účel definuje zejména hlavičky Accept, Accept-Charset, Accept-Encoding a Accept-Language 23 Příkladně IP adresa klienta může být použita pro odlišení „domácích“ a „cizích“ návštěvníků. 24 Pro přehlednost jsou uvedeny pouze Accept- hlavičky a chybí povinná hlavička Host. 25 založený na expiraci (vypršení) platnosti či čerstvosti dokumentu a jeho validaci (ověření) Strana 17 Kapitola 1: Protokol HTTP 1.4.7 RFC 2616 V červnu roku 1999 byl vydán nový RFC dokument s číslem 2616 (164 stran bez příloh 176 s nimi), který nahradil předchozí specifikaci. V samotném protokolu nebyly provedeny zásadnější změny, šlo spíše o precizaci některých formulací (zejména ve vztahu k požadavkům na implementaci) a upřesnění několika detailů. Mezi metody přibyla jedna nová pro použití s proxy servery, která však nebyla blíže specifikována (jde tedy spíše o rezervování jejího názvu). Přibylo několik málo nových stavových kódů zejména mezi těmi ze třetí třídy26. Výchozí název kódu 302 byl pro lepší odlišení významu od kódu 301 přejmenován27. Několik málo nepříliš používaných hlaviček bylo zrušeno, a přibylo několik nových. Následuje souhrnný příklad užití protokolu HTTP 1.1. GET /index.html HTTP/1.1 Host: www.example.net Accept: text/html, image/png, image/jpeg, image/gif, */*;q=0.1 Accept-Language: cs;q=1.0, en;q=0.9, sk;q=0.5, de;q=0.1 Accept-Charset: iso-8859-2, utf-8, iso-8859-1;q=0.6, *;q=0.1 HTTP/1.1 200 OK Date: Wed, 1 Aug 2001 18:30:29 GMT Server: Apache/2.0.49 (Win32) Content-Type: text/html Transfer-Encoding: chunked Last-Modified: Wed, 1 Aug 2001 12:01:18 GMT 1c <html> <head><title>Doc</tit 1a le></head> <body>text</bod a y> </html> 0 1.5 Shrnutí V současnosti je tedy platným standardem ve zmiňované oblasti HTTP verze 1.1 dle specifikace v dokumentu RFC 261628. Ve svém celku se jedná o protokol poměrně komplexní29, přesto v něm zůstává velmi silně zakořeněný jeho původní účel – totiž jednorázový přenos dokumentů. Stále je protokolem bezstavovým, ovšem zejména díky popularitě služby WWW je dnes používán pro přístup ke službám a aplikacím, které jsou ze své podstaty stavové. Tento rozpor musí být samozřejmě určitým způsobem řešen a stavové informace je nutno mezi jednotlivými požadavky nějak udržovat. 26 Včetně kódu 306, u kterého stojí, že byl používán v dřívějších specifikacích a nyní je nevyužit a rezervován. V žádné z jmenovaných předchozích specifikací se však neobjevuje. Pochází pravděpodobně z některého z pracovních dokumentů, jak lze vysledovat např. z [8]. Odtud také vyplývá, že původní význam tohoto kódu zněl „switch proxy“. 27 301 – Moved Permanently (trvale přesunuto) 302 – původně Moved Temporarily (dočasně přesunuto) nyní Found (nalezeno) navíc přibyl nový kód 307 – Temporary Redirect (dočasné přesměrování) 28 Některá rozšíření protokolu jsou obsažena v dalších dokumentech například HTTP autentizace v RFC 2617[44]. 29 Některým zainteresovaným se kolem roku 1997 (i když první impulsy pochází již z roku 1995) začal zdát možná až příliš komplexní a složitý, navíc s malou možností rozšíření. Začali pracovat na návrhu HTTP-ng (next generation) [53]. Nemělo jít pouze o revizi stávajícího HTTP, ale o kompletní vícevrstvou architekturu, která by mimo jiné podporovala RPC (Remote Procedure Call – vzdálené volání procedur). Tato snaha však nebyla dotažena do konce (snad přišla příliš brzy) a byla ukončena na sklonku roku 1999. Strana 18 Kapitola 2: Stavové informace 2 Stavové informace 2.1 Bezstavovost protokolu HTTP Jak bylo již řečeno, protokol HTTP je protokolem bezstavovým. Klient ani server tedy po vznesení požadavku a transportu odpovědi nepřechází do jiného vnitřního stavu. Nepamatují si žádné informace, týkající se uskutečněného spojení30. To je výhodné zejména kvůli možné jednodušší implementaci jak klientů, tak i serverů. Není nutno řešit případné problémy s obnovením těchto informací při neočekávaném ukončení spojení nebo softwarové chybě. Konečným důsledkem tohoto přístupu je, že s každým požadavkem je ze strany serveru nakládáno tak, jako by byl prvním. Zde je na místě znovu připomenout, že (na logické úrovni) toto platí rovněž při perzistentním spojení, zmiňovaném v souvislosti s HTTP 1.1. Spojení sice zůstane otevřeno pro další požadavky, ovšem týká se to pouze nižších vrstev (transportní, síťové, …). Ostatní chování vnitřní logiky protokolu HTTP je nezměněné, jako kdyby spojení bylo uzavřeno a znovu navázáno. 2.2 Potřeba udržování stavových informací v protokolu HTTP Popsaná situace je zcela postačující pro původní poslání protokolu – přenos statických dokumentů na základě požadavku. Postupem času se však služba WWW stala zcela jistě nejpopulárnější ze služeb internetu. Poměrně mnoho nezkušených uživatelů s ní dokonce celý internet ztotožňuje [59]. Navíc skutečnost, že se díky konkurenčnímu boji staly nejrozšířenější webové prohlížeče z původně placeného softwaru bezplatnými (či přímo předinstalovanými v operačním systému), tento trend ještě urychlila. Služba WWW se tak zejména v polovině devadesátých let začala stávat mimo jiné i novým marketingovým médiem a mnoho (později velmi neúspěšných) společností založilo své obchodní strategie z velké části právě pouze na ní31. Kvůli vysoké míře dostupnosti, relativně dobré vybavenosti softwarem (prohlížeči) a poměrně nízkým potřebným výchozím znalostem32 se „pod křídla“ WWW začaly přesouvat i další služby internetu. Jmenujme například elektronickou poštu či vyhledávání v katalozích a informačních databázích. V poslední době se rovněž poměrně silně rozmohlo využití webového rozhraní pro přístup zaměstnanců k podnikovým informačním systémům. Zde je výhodou mj. zejména snadná změna verzí, neboť není nutné všem zaměstnancům instalovat nový software, změna se provede pouze na serveru. Všechny výše zmíněné operace – nákupy, práce s poštou, vyhledávání v databázích i práce v informačním systému – ovšem vyžadují pro svou plnohodnotnou funkčnost přes WWW přenos stavových informací. Takové nároky však protokol HTTP přímo může jen těžko uspokojit, neboť na ně není uzpůsobený. Jak bylo již řečeno, každý požadavek je ze strany serveru brán jako by byl první. Aby server (případně na něm běžící obslužný skript či aplikace), mohl takovéto informace získávat, je proto nutné, aby byly obsaženy přímo v požadavku. Toho lze dosáhnout několika možnými metodami. Každá z nich má své výhody a nedostatky, které se v následujícím textu budeme snažit zohlednit. 30 Myšleno vzhledem k následujícím spojením a k protokolu HTTP. Samozřejmě je pravděpodobné, že server zapíše informaci o uskutečněném požadavku do logu, či klient zaznamená čas přístupu tak, aby mohl potenciální budoucí požadavky na tentýž dokument učinit podmíněnými (např. hlavičkou If-Modified-Since). 31 tzv. dot-com se koncem devadesátých let ukázaly jako tragicky neúspěšné, společně se tzv. „splasknutím technologické bubliny“ čili vystřízlivěním investorů, obchodníků a konec konců i zákazníků z původního téměř bezbřehého nadšení a opojení informačními a komunikačními technologiemi. 32 Výchozí nastavení prohlížeče většinou umožňuje jeho přímé použití, kdežto kupříkladu nastavení poštovního programu pro příjem a odesílání zpráv vyžaduje jisté úsilí a určité znalosti. Strana 19 Kapitola 2: Stavové informace 2.3 Stavové informace v prostředí WWW Existuje několik možností, jak lze stavové informace během komunikace v prostředí WWW udržovat a pracovat s nimi. V základním pohledu mohou být informace buď přenášeny přímo s každým požadavkem a nebo mohou být udržovány na serveru. I v druhém případě, jak si ukážeme v úvodu kapitoly 5, která mu bude věnována a kde se zmíníme i o některých otázkách bezpečnosti přenosu stavových informací, je ovšem nutný přenos odpovídajících identifikátorů mezi serverem a klientem. V obou případech je tedy legitimní hovořit o metodách přenosu stavových informací. Tyto metody jsme se rozhodli pro přehlednost rozčlenit do několika skupin. Kritériem byl samotný způsob přenosu informací mezi oběma komunikujícími stranami. Dále jsme se rozhodli rozčlenit samotné přenášené informace na dva druhy a to podle jejich významu (viz již zmiňované identifikátory). Zde abstrahujeme od způsobu přenosu a zabýváme se tím, jaké informace jsou přenášeny. Ne všechny způsoby přenosu jsou totiž vhodné pro oba tyto druhy informací. 2.3.1 Metody přenosu stavových informací V nejhrubším pohledu lze metody pro přenos stavových informací v prostředí WWW rozdělit na tři velké skupiny. První, početně největší, skupinu tvoří metody využívající přímo vlastností protokolu HTTP. Patří k nim zejména různé způsoby zakódování informací do URI požadavku případně využití některých dalších informací dostupných z protokolu HTTP. Těmito metodami se bude zabývat kapitola 3. Druhá skupina obsahuje fakticky jedinou, ovšem co do technologie a také historie svého vzniku a vývoje velmi zajímavou metodu – tzv. cookies. Ta je jistým rozšířením protokolu HTTP určeným právě výslovně pro uchovávání stavových informací a také proto jí bude věnována samostatná kapitola 4. Třetí skupina obsahuje řešení, která se netýkají přímo protokolu HTTP či jeho rozšíření. Sem byla zařazena řešení, která jej jistými způsoby obcházejí. Z důvodu této specifičnosti se jim budeme věnovat pouze okrajově v závěru této kapitoly. Pro přehlednost zde uvádíme hierarchický soupis metod. Detailně k jednotlivým metodám viz následující kapitoly. Metody přenosu stavových informací v prostředí WWW • • • Prostředky protokolu HTTP • URI požadavku • za otazníkem (query) • virtuální adresář za dokumentem (path info) • virtuální adresář před dokumentem • skrytá formulářová pole • HTTP autentizace • IP adresa • hlavička From Rozšíření protokolu HTTP (cookies) • dle specifikace Netscape • dle RFC 2109 • dle RFC2965 Zcela mimo protokol HTTP • klientské skripty • vložené samostatné aplikace Strana 20 Kapitola 2: Stavové informace 2.3.2 Stavové informace dle významu Zde nám půjde zejména o to, jaký typ informací je shora popsanými způsoby přenášen. Přecházíme tu jaksi o úroveň výše – z úrovně přenosu dat v komunikačním kanálu v rámci HTTP, na úroveň logiky aplikace, která s takto přenášenými daty (zde již spíše informacemi) pracuje. Z hlediska významu nás budou zajímat dva druhy informací. První z nich jsou informace identifikační – tedy takové, které napříč přes několik HTTP požadavků identifikují jednotlivé uživatele (často je pro takový typ informace užíván termín session-id či česky – identifikátor relace). Tam, kde je požadováno důsledné odlišení uživatelů (například u rozhraní elektronické pošty, ovládání bankovního účtu apod.), je nutno brát v úvahu zejména bezpečnost použití takových identifikátorů. Tímto tématem a na jisté obecné úrovni ochranou před možnými útoky se zabývá kapitola 5. Druhou uvažovanou skupinu informací, které je také nutno přenášet prostředky protokolu HTTP tvoří informace jiné než identifikační. Nazvěme je transakčními, neboť se často váží k transakcím v dané konkrétní aplikaci. Může jít o identifikace transakcí, tak aby bylo víceúčelovému skriptu dáno najevo, kterou akci má provést, případně se může jednat o data poskytnutá aplikaci ke zpracování. Ve většině dynamických aplikací je také nutné tento typ informací udržovat. Často však pouze po relativně krátkou dobu po několik málo dalších požadavků. Udržované a přenášené informace jsme si tedy pro vlastní potřeby rozdělili na identifikační – ty, podle kterých aplikace rozlišují uživatele a transakční – ty ostatní, které je nutné udržovat a přenášet (nejčastěji se týkají uskutečňovaných transakcí). 2.4 Práce se stavovými informacemi v prostředí WWW mimo rámec HTTP Na tomto místě je velmi obecně pojednáno o možných způsobech práce se stavovými informacemi v prostředí služby WWW, které pro svou činnost neužívají protokolu HTTP či jeho rozšíření. Tato práce se těmito způsoby detailně nezabývá a uvádíme je zde pouze pro úplnost možností udržování stavových informací v prostředí WWW. S použitím klientských skriptů Je možné, že se autor webové aplikace rozhodne, že není potřeba (nebo to není možné33) odesílat stavové informace serveru, ale postačí pokud tyto budou uchovávány a zpracovávány přímo na klientském softwaru – tedy v prohlížeči. Toho lze dosáhnout použitím některého ze skriptovacích jazyků implementovaných v prohlížečích (nejčastěji různé verze JavaScriptu). Takové jazyky však z pochopitelných bezpečnostních důvodů samozřejmě nemají přístup k souborovému systému klientského počítače34. Data je proto nutné uložit jiným způsobem. Jeden z nich ač je poměrně funkční, má celou řadu nevýhod. Je jím ukládání dat dynamicky do dokumentu nahraného v „neviditelném“ HTML rámci (frame resp. iframe). Tento způsob je podrobně popsán např. v [24]. K zásadním nevýhodám patří již samotné použití skriptů, které je nutné velmi pečlivě odladit v různých verzích různých prohlížečů. Druhým zásadním nedostatkem je použití rámů. Je totiž nutno zabránit uživateli dosažení dokumentu jinak, než v tomto rámu. Toto je velmi problematické zejména pokud se uživatel na web dostává z externího odkazu (například z vyhledávače). Teoreticky je možné toto kontrolovat opět s použitím klientských skriptů, je to však způsob nanejvýš nevhodný. Navíc utvořit odkaz tak, aby 33 Například na serveru není nainstalována podpora pro skriptování. 34 nepočítaje v to různé chyby v implementaci Strana 21 Kapitola 2: Stavové informace se do prohlížeče nahrála stránka obsahující rámy a v nich požadované dokumenty (odlišné od výchozích pro dané rámy) je téměř nemožné. Jiným, na implementaci relativně snadnějším způsobem je použití klientských skriptů k ukládání do a čtení z cookies (k nim blíže viz kapitolu 4). Ty je ale zase možno v prohlížeči vypnout či omezit. Všechny tyto metody mají zásadní nevýhodu – ne všechny prohlížeče podporují klientské skriptování (resp rámy), případně je možné tyto funkce omezit či zcela deaktivovat. Záleží potom na konkrétní aplikaci, jak se takovou situací vyrovná. Pro zde popsané metody proto nelze vidět širší možnosti použití. Absence komunikace se serverem vylučuje jejich užití pro identifikační i transakční informace ve smyslu výše uvedených definic. Jedna z mála představitelných možností by byla personalizace vzhledu (např. nastavení barvy pozadí či textu35) na webech tvořených množinou statických stránek. Pomocí samostatných vložených aplikací Zcela jiný přístup k tvorbě webových aplikací představuje použití relativně samostatných často binárních programů, které jsou vloženy do webové stránky. Může jít o applety v jazyce Java, objekty Active-X, Flash či jiné. Takové programy jsou pomocí protokolu HTTP pouze přenášeny a fungují jako víceméně samostatné plnohodnotné aplikace. Z toho plyne, že mohou v rámci určených pravidel36 také navazovat síťová spojení a komunikovat pomocí nich. Tato komunikace se již nemusí řídit protokolem HTTP (a většinou se jím také neřídí). Spojení tedy může probíhat pomocí nějakého stavového protokolu a potřebná data mohou putovat oběma směry. Veškeré detaily záleží na konkrétní aplikaci. HTTP je v takovém případě použit pouze k distribuci, případně vyvolání spuštění (pokud jsou již staženy a uloženy na klientském počítači) samostatných aplikací. Proto zde nelze hovořit o udržování stavových informací v protokolu HTTP. Obrázek 7: Přenos informací mezi vloženým objektem a serverem mimo rámec protokolu HTTP 35 V dokonalejší formě by potom mohlo jít kupříkladu o uložení adresy kaskádového stylu popisujícího zvolený vzhled sady stránek. 36 Například u Java appletů je standardně z bezpečnostních důvodů možné komunikovat pouze se stejným serverem, ze kterého byl applet stažen; pro Active-X obdobné omezení neexistuje. Strana 22 Kapitola 3: Přenos stavových informací prostředky HTTP 3 Přenos stavových informací prostředky HTTP V této kapitole se budeme věnovat technikám užívaným k přenosu stavových informací a to pouze s využitím standardních vlastností protokolu HTTP v aktuální verzi (tedy 1.1). Kromě zakódování těchto informací do URI nebo těla požadavků metodou POST je to především využití některých specifických hlaviček. 3.1 Data zakódovaná do URI První reprezentant této skupiny metod využívá toho, že s každým požadavkem je na server odesílána část adresy (bez jména serveru a portu). Vhodnou úpravou této adresy je možné předat serveru či na něm běžícímu skriptu požadované informace. 3.1.1 Obecná východiska Tento způsob je velmi často používaným. Mezi jeho nesporné výhody patří skutečnost, že URI je skutečně podstatnou součástí požadavku a proto jej musí podporovat všechny prohlížeče a není jej tedy možné vyřadit z činnosti deaktivací některých funkcí (na rozdíl od například cookies, či některých hlaviček). Aplikace, která spoléhá čistě na tento způsob tedy bude fungovat ve všech prohlížečích na všech platformách37. Navíc je možné tímto způsobem přidat stavové informace do libovolného hypertextového odkazu (na rozdíl od dále uváděných formulářových polí). Právě proto, že je tento způsob tak těsně spjat se samotným jádrem HTTP, má bohužel také řadu nevýhod. Jednou z nich je, že požadované URI je na serveru a na případných prostřednících (proxy) velmi často zapisováno do logovacích souborů. V URI tak rozhodně není vhodné přenášet nejen důvěrná data (což v prostředí internetu platí obecně o jakémkoli přenosu, pokud není zajištěn spolehlivými kryptografickými postupy), ale tento způsob není bez dalších opatření zcela vhodný ani pro přenos informací identifikačních (ve smyslu identifikátorů relace). Problém ještě komplikuje zmiňovaná hlavička Referer, která může způsobit odeslání aktuálního URI (včetně v něm zakódovaných informací) na cizí server (viz kapitolu 5). Další nevýhody spočívají na straně klientů. Protože URI je původně určen k identifikaci umístění dokumentu a jeho získání nejčastěji metodou GET, zachází s ním prohlížeče odpovídajícím způsobem. Tím je myšleno mimo jiné například ukládání do historie navštívených stránek. Pokud jsou v URI přenášeny transakční informace (viz subkapitolu 2.3.2), může mít v případě nedokonalého návrhu opětovné vyvolání URI z historie na chování aplikace neočekávané důsledky38. Situace není z tohoto pohledu o mnoho lepší ani v případě identifikačních informací. Pokud má být aplikace bezpečná a zahrnuje v sobě automatické vypršení platnosti relace, uživatel bude nemile překvapen, pokud si takovou adresu uložil mezi své oblíbené adresy. Po určité době (dle konkrétní aplikace) bude odkaz neplatný, respektive bude ukazovat na zcela jiný dokument – v lepším případě informující o nastalé situaci. Kombinace předchozích případů (tj. buď vypršení nebo použití identifikátoru jiným uživatelem s případnou kontrolou např. IP adresy) nastane, pokud se uživatel rozhodne o daném dokumentu informovat jiného uživatele a takovéto URI mu pošle. S tím souvisí i další – na první pohled možná spíše úsměvný, ale rovněž relevantní argument proti zakomponovávání stavových informací do 37 V extrémních případech by bylo lze uvažovat omezení spočívající v maximální délce URI. 38 Ačkoli ve specifikaci HTTP se uvádí, že požadavek metodou GET by neměl mít žádné jiné vedlejší účinky než pouhé odeslání požadovaného dokumentu, v praxi se tak ale nezřídka děje. Jazyk HTML rovněž poskytuje možnost nechat data z formuláře odesílat pomocí metody GET. Strana 23 Kapitola 3: Přenos stavových informací prostředky HTTP URI. Totiž, že tam jsou „moc na očích“. Dlouhá URI plná mnoha zdánlivě nesmyslných znaků se těžko pamatují, těžko opisují (rozuměj na papír, kam je nelze zkopírovat) či diktují39. Kromě toho někdy mohou taková snadno viditelná data lákat k úmyslné modifikaci a pokusu o primitivní útok na zabezpečení aplikace. Tento obecný popis charakterizoval veškeré způsoby přenosu informací v URI, v praxi se užívají nejčastěji následující dva: za prvé, data jsou za adresou dokumentu (v části query – za otazníkem) a za druhé, data tvoří název virtuálního adresáře za názvem skriptu. Zajímavým řešením je také umístění dat sice také do názvu virtuálního adresáře, ale před samotný název dokumentu. 3.1.2 Data za názvem dokumentu za otazníkem Tento případ bývá užíván nejčastěji, neboť nevyžaduje žádné náročnější nastavení webového serveru a funguje vlastně stejně jako odesílání HTML formulářů metodou GET. Požadovaná data se buď přímo umístí na konec URI a od názvu dokumentu (resp. skriptu) se oddělí otazníkem, nebo jsou zakódována tak, jak se odesílají formulářová data tj. název proměnné, znak rovnítka, hodnota proměnné a případný další název proměnné oddělený znakem ampersandu (&). Je samozřejmě možné používat jiný způsob kódování40, ale tento je velmi rozšířený a je přímo podporován (zejména extrakcí dat do proměnných) mnoha implementačními prostředími pro webové aplikace. Tento způsob je velice vhodný zejména pro transakční informace, bývá ale velmi často užíván zároveň pro informace identifikační a to zejména pro svou plnou kompatibilitu s HTML formuláři a vestavěnou podporou v prostředích. Následuje několik příkladů, jak je možné data tímto způsobem do URI zapsat: http://www.example.net/uriquery1.php?quido http://www.example.net/uriquery2.php?user=quido&lang=cs http://www.example.net/uriqyery3.php?97f9e7af1bc95c766e8b0e6be0e31a76 jako součást cesty Druhým způsobem přenosu dat za názvem dokumentu je jejich zapsání jako virtuální adresářové cesty ovšem až za názvem skriptu. Jednotlivé proměnné je potom možno oddělovat jako samostatné adresáře. Správně nastavený server pak v URI rozezná existující dokument a další virtuální cestu neinterpretuje jako adresářový strom, ale předá ji spuštěnému skriptu v proměnné, která dle specifikace CGI nese název PATH_INFO. Skript potom může s touto proměnnou snadno dále pracovat. Zmiňovaný přístup se již tolik nehodí pro informace transakční (obtížnější převod na proměnné), bývá však užíván pro přenos identifikátorů. Zde je opět krátký příklad znázorňující popsaný způsob (resp. kombinaci obou): http://www.example.net/uripinfo1.php/quido http://www.example.net/uripinfo2.php/quido/cs http://www.example.net/uripinfo3.php/f7712875b0bb78f1d743331bfcad61dd http://www.example.net/urimix1.php/quido?lang=cs Nevýhodou obou předchozích řešení je, že každý dokument na celém webu, v rámci něhož chceme udržovat stavové informace, musí být dynamicky generován. Důvodem této podmínky je 39 Jak se píše ve specifikaci [42], URI není posloupnost oktetů, ale posloupnost znaků neboť může být přenášeno mnoha různými způsoby (po síti, na papíře, hlasem, …). 40 Například takové, kdy je k oddělení proměnných použito jiného znaku. Znak & je totiž v HTML užíván pro označení entit a v odkazech by se tedy měl nahrazovat sekvencí &. Strana 24 Kapitola 3: Přenos stavových informací prostředky HTTP skutečnost, že je nutné informace uchované v URI jednoho dokumentu zanést také do odkazů na další dokumenty. Ztráta těchto informací v jednom požadavku by totiž znamenala jejich ztrátu i pro všechny následující požadavky. Dynamicky tak musí být upravovány všechny hypertextové odkazy uvnitř daného webu a také URI ukazující na cíl odeslání dat z HTML formulářů41. Nutnost takového neustálého přegenerovávání dokumentů může vést ke snížení výkonu celé aplikace. Navíc u jinak zcela statických dokumentů (klasickým příkladem je nápověda k systému42) se může takováto činnost zdát jako zbytečné plýtvání43. 3.1.3 Data před názvem dokumentu Jiný způsob, jak pomocí URI udržovat stavové informace, využívá podobného principu, jako výše popsaná technika s PATH_INFO. Na rozdíl od ní, je ale virtuální adresář umístěn před samotný název dokumentu. Ač se to na první pohled nezdá o mnoho výhodnější, jedna nesporná výhoda tu je. Pokud totiž v dokumentu použijeme v odkazech relativní adresy, není nutné jejich přegenerovávání. Protože data tvoří virtuální adresář vyšší úrovně, ten při použití relativních odkazů, které nad tuto úroveň nezasahují, zůstane zachován. Zpracování adresy skriptem je zde lehce obtížnější. Celá adresa požadavku může být získána například z proměnné REQUEST_URI, odkud lze poté dotyčná data extrahovat. Tento způsob je vhodný pouze pro přenos identifikátoru, který není příliš často měněn, neboť jinak by se jeho výhoda ztrácela. Častá změna během relace by nutně musela vést opět k přegenerovávání odkazů. Pro správnou funkci je zde nutný zásah do konfigurace serveru44 tak, aby virtuální adresáře nebyly považovány za součást stromové struktury. Požadovaná URI si tak musí server správně přeložit na interní adresy existujících dokumentů. K tomu složí například v HTTP serveru Apache[1] modul mod_rewrite. Následující příklad ukazuje jeho možnou jednoduchou konfiguraci (jedná se o fragment z konfiguračního souboru httpd.conf serveru Apache), která zaručí, že dokumenty v adresáři /store budou přístupné také o jeden libovolně nazvaný adresář hlouběji. Alias /store/ /var/www/store/ RewriteEngine On RewriteCond %{REQUEST_URI} /store/ RewriteRule /store/[^/]+/(.*)$ /store/$1 Tedy všechny následující URI budou ukazovat na stejný dokument: http://www.example.net/store/urivp.php http://www.example.net/store/quido/urivp.php http://www.example.net/store/--host--/urivp.php Je možné použít více podadresářů v adresáři /store. Ty budou v adrese za virtuálním adresářem. Následující dvě URI opět ukazují na stejný dokument. http://www.example.net/store/goods/urivp.php http://www.example.net/store/quido/goods/urivp.php 41 Pokud to není řešeno například skrytými formulářovými poli. Přesto se tento způsob vzhledem k tomu, že je tak jako tak nutno upravit odkazy, zdá výhodnější. 42 Ač je nutno poznamenat, že nápovědy obecně nebývají (bohužel) uživateli příliš často čteny. 43 Jistým řešením by bylo otevírání takových dokumentů v novém okně prohlížeče tak, aby v původním okně zůstaly vygenerované odkazy zachovány. Takovéto vynucené otevření nového okna se však nemusí setkat s přízní uživatelů a v některých (zejména textových) prohlížečích ani není proveditelné. 44 Což může být jedna z nevýhod této metody, neboť takový zásah není vždy možný (například na hostingových serverech externích poskytovatelů). Strana 25 Kapitola 3: Přenos stavových informací prostředky HTTP 3.2 Formulářová pole Ač takovéto pojmenování vede spíše k jazyku HTML než protokolu HTTP, nesporným faktem je, že data z formulářů jsou tímto protokolem odesílána. Nebudeme se zde podrobněji zabývat problematikou formulářů. Zmíníme se jen, že kromě klasických vstupních polí je možné do formuláře vložit také pole, která sice mají klasicky název a hodnotu, ale nejsou pro uživatele viditelná. Přesněji řečeno nemají v HTML žádnou grafickou reprezentaci. Vidět je lze samozřejmě zapsané ve zdrojovém textu. Formuláře je možné odesílat dvěma způsoby respektive HTTP metodami – GET a POST. Odeslání metodou GET probíhá tak, že do příslušného URI jsou za otazník zakódována formulářová data stejným způsobem, jak je uvedeno v prvním odstavci subkapitoly 3.1.3. V tomto případě jsou data vlastně odesílána zakódováním do URI a platí pro ně veškerá tvrzení tam uvedená. Pokud jsou data odesílána metodou POST, nejsou zapsána do URI, ale poslána (opět ve stejně zakódované podobě) v těle požadavku, jak je to popsáno v subkapitole 1.3.3. To má oproti předchozí metodě jisté výhody. Z těch hlavních to je zejména fakt, že tělo požadavku většinou nebývá zaznamenáváno do logů. Neznamená to však, že se jedná o zcela bezpečný způsob přenosu. Data jsou standardně přenášena po síti v otevřené formě a jsou zachytitelná. Pouze nejsou na tolika místech ukládána. Také prohlížeč uživatele často umí upozornit na případné opakované odeslání dat. Data odeslaná metodou POST se navíc neobjeví ani v hlavičce Referer. Identifikační informace je tedy možné vložit do skrytých polí a ta jsou potom spolu s případnými transakčními informacemi z běžných (či rovněž skrytých45) formulářových polí metodou POST odeslána. Tímto způsobem odeslaná data jsou běžnému uživateli skryta. To, že se taková „neviditelná“ pole nazývají skrytá (hidden), ale neznamená, že se k nim uživatel nemůže relativně snadno dostat a změnit je. Jak již bylo řečeno, jsou zapsaná ve zdrojovém textu, který umí zobrazit snad každý prohlížeč. Zásadním omezením, které limituje nasazení této metody je fakt, že celá oblast webu, kde chceme stavové informace takto udržovat, musí být mezi sebou propojena nikoli běžnými hypertextovými odkazy, ale formuláři. Pro přechod na jiné stránky musí být použito odesílacích tlačítek46. Kromě toho i zde platí nutnost dynamického generování všech stran – nyní nejsou generovány odkazy, ale hodnoty identifikačních skrytých polí. Tato metoda je teoreticky použitelná pro libovolný typ informací47. Ve své čisté podobě (tj. pouze formulářové propojení mezi stranami) je však ve většině případů nevhodná pro informace identifikačního charakteru (ač z hlediska bezpečnosti by byla vhodnější než URI). Užívá se tak spíše pro jednorázový přenos transakčních informací zpravidla získávaných od uživatele a zejména ve větším objemu (např. textové příspěvky, články či celé soubory). <form action="form.php" method="post"> <input type="text" name="hledat"> <input type="hidden" name="id" value="quido"> <input type="submit" name="co" value="Hledat"> </form> Obrázek 8: Fragment HTML kódu s formulářem se skrytým polem a jeho grafická reprezentace v prohlížeči 45 Například kód akce, která má být aplikací provedena může být také uložen ve skrytém poli aby byl uživatel odstíněn od aplikační logiky. Často se též pro takový kód využívá názvu a hodnoty odesílacího tlačítka formuláře, které je specifickým formulářovým polem. 46 případně obrázků 47 Obecně lze takto odesílat data delší než jaká se vejdou do URI, a to včetně souborů. Strana 26 Kapitola 3: Přenos stavových informací prostředky HTTP 3.3 HTTP autentizace Protokol HTTP obsahuje mechanismus, který umožňuje jednoduchým způsobem spolu s požadavkem odeslat také informace sloužící pro ověření přístupových práv k dokumentu[44]. Pokud je server vyžaduje pro zpřístupnění nějakého dokumentu či sady dokumentů, odešle v odpovědi stavový kód 401 (Unauthorized – neautorizováno48) a hlavičku WWW-Authenticate. Uživatel je prohlížečem vyzván, aby vyplnil uživatelské jméno a heslo. Ty jsou potom v hlavičce Authorization odeslány v novém požadavku serveru. Pokud jsou zadané údaje platné tj. klient neobdrží v další odpovědi opět stavový kód 401, údaje si dočasně49 uloží aby je mohl (kvůli bezstavovosti protokolu HTTP) odeslat spolu s dalšími požadavky na tentýž server již bez dalšího dotazování. Tento mechanismus by tedy bylo možné s výhodou použít pro identifikaci uživatelů. Jeho předností je, že je součástí samotného protokolu a je tedy podporován (alespoň ve své základní – Basic verzi50) v jeho mnoha implementacích jak na straně klientů, tak na straně serverů. Autentizační informace jsou odesílány automaticky a to v každém požadavku na dokument z příslušné části serveru. Nehrozí tak obdoba zbytečného přegenerovávání dokumentů. Existují ovšem rovněž nevýhody a to dosti podstatné. Mezi ty nejzásadnější patří skutečnost, že neexistuje jednoduchý způsob, kterým by se bylo možno odhlásit čili ukončit relaci – jinými slovy donutit prohlížeč, aby od určeného okamžiku přestal autentizační informace v požadavcích posílat51. Je tak velmi obtížné například přihlásit dalšího uživatele na stejném prohlížeči. Velkou komplikací je potřeba mít předem (tedy před přihlášením) uděleno uživatelské jméno – identifikátor. Z toho plyne, že není možné tuto metodu použít pro jednorázové odlišení uživatelů ještě před přihlášením (například v elektronickém obchodě). Protože budou uživatelé vypisovat uživatelská jména ručně, nemůže jít například o výstupy hašovacích funkcí. Ty jsou jinak právě pro tvorbu identifikátorů velmi vhodné kvůli konstantní délce a velké složitosti. Kromě toho může docházet ke kolizím mezi požadovanými a již zaregistrovanými jmény a podobně. Další nevýhoda spočívá právě ve faktu, že o zobrazení dialogu se stará prohlížeč. Tvůrce webové aplikace tedy nemůže upravit jeho vzhled tak, aby například odpovídal barevně, velikostí písma, nebo dokonce jazykově. Na rozdíl od webové stránky s formulářovými poli není možné vložit do takovéhoto dialogu ani nějaký vysvětlující text. Všechny tyto skutečnosti a navíc i to, že tato metoda nebývá užívána příliš často, vedou k tomu, že nezkušený uživatel může být odrazen. Popsaná metoda je tedy již ze své podstaty vhodná pouze pro informace identifikačního charakteru tj. uživatelské jméno. Lze ji však použít pouze v případech, kdy je toto vydáno uživateli předem. Již od základů je tento mechanismus navržený a určený pro situace, kdy je vhodné jednoduše zamezit přístupu neautorizovaných uživatelů k některým dokumentům. Jiné využití naráží na mnoho problémů a není proto vhodné. Zde je příklad HTTP komunikace s vyznačením autentizačních hlaviček: GET /protected.html HTTP/1.1 Host: www.example.net HTTP/1.1 401 Unauthorized 48 49 50 51 Často je také užíván popis „Authorization Required“ (požadována autorizace). většinou do uzavření prohlížeče Jméno a heslo jsou odesílána nezašifrovaně pouze v kódování Base64. Jednou z jednodušších možností je ukončení prohlížeče. To však rozhodně není možnost vyhovující. Strana 27 Kapitola 3: Přenos stavových informací prostředky HTTP Date: Wed, 1 Aug 2001 20:30:29 GMT WWW-Authenticate: Basic realm="chranena oblast" Unauthorized ----------------------------------------------GET /protected.html HTTP/1.1 Host: www.example.net Authorization: Basic bWljaGFsOmhhdXppcmVr HTTP/1.1 200 OK Date: Wed, 1 Aug 2001 20:31:05 GMT Content-Length: 315 ... 3.4 IP adresa Adresa IP samozřejmě není součástí protokolu HTTP. V této kategorii je však uváděna proto, že na rozdíl od dříve zmiňované třetí kategorie metod, se nejedná o mechanismus aplikovaný nad (jako klientské skripty), či vedle (jako vložené binární objekty) HTTP. V tomto způsobu uvažování lze říci, že IP adresa je pod HTTP – konkrétně až v síťové vrstvě. Tolik tedy pro upřesnění pozice této metody v tomto přehledu. Samotná IP adresa je 32-bitové číslo a nemůže tedy samo o sobě sloužit pro přenos nějakých dat. Server však má z pochopitelných důvodů k dispozici IP adresu klienta. Bylo by ji tak teoreticky možné použít k identifikaci a rozlišení klientů – tedy jako druh identifikátoru. Takový identifikátor by měl mnoho výhod. Byl by automaticky odesílán s každým požadavkem bez nutnosti nějakých softwarových úprav a byl by v prostředí internetu jen velmi obtížně podvrhnutelný. Nejedná se však (bohužel) ani zdaleka o identifikátor jednoznačný, což jej činí pro tento účel nepoužitelným. IP adresa klienta totiž může měnit – například dynamické přidělování adres s omezenou dobou platnosti domácím uživatelům je běžné. Mnoho klientů se také ke službám internetu připojuje přes proxy servery, a cílový server poté jako IP adresu klienta získá adresu posledního takového proxy serveru. Pokud by byla IP adresa použita jako identifikátor, například ve webovém rozhraní k elektronické poště, k dopisům jednoho zaměstnance by se dostali zaměstnanci celé firmy, která používá jediný proxy server a naopak na takovýmto způsobem řešenou anketu (s jedinou odpovědí na uživatele tedy IP) by mohl odpovědět pouze první z nich. Některé proxy-servery sice posílají hlavičku X-Forwarded-For, která obsahuje IP adresu prvního klienta, ale ani tak se nejedná o spolehlivý identifikátor. Jednak se tak nechovají zdaleka všechny a kromě toho je poměrně jednoduché takovou hlavičku odeslat ručně. O pár odstavců výše v souvislosti s nemožností použití IP adresy jako jednoznačného identifikátoru bylo slovo bohužel uvedeno v závorkách. Na tomto místě je vhodné vysvětlit, proč tomu tak bylo. Pokud by totiž toto bylo hypoteticky možné, čelili bychom zcela jistě problémům profilování uživatelů. Tedy v krátkosti vytváření individuálních profilů týkajících se jednotlivých uživatelů a jejich zájmů za účelem (v nejlepším případě pouze) přesnějšího zacílení reklamy. Blíže se k tomuto tématu vrátíme v souvislosti s tzv. cookies třetích stran v subkapitole 4.5.1. Tyto by ovšem byly mnohem závažnějšího rázu, neboť IP adresa nejen nelze „vypnout“ jako cookies, ale také zdaleka nesouvisí pouze s WWW. Strana 28 Kapitola 3: Přenos stavových informací prostředky HTTP IP adresa tedy (možná by se slušelo říci nyní naopak bohudík) nemůže být použita přímo jako identifikátor, velice dobře je ji ale možné použít ke zvýšení zabezpečení aplikací zejména při ochraně relací (viz kapitolu 5). 3.5 Hlavička From Zatímco předchozí metody byly prakticky použitelné alespoň pro některé případy52, tato mezi ně nepatří. Jedná se o metodu pouze teoretickou, neboť hlavičku From prohlížeče neodesílají. Objevuje se však ve specifikaci protokolu a proto se zde o ní zmíníme. Jak jsme již poznamenali, hlavička From by měla obsahovat adresu elektronické pošty uživatele, který požadavek vyslal respektive je za něj zodpovědný. Pokud by se takto prohlížeče chovaly, bylo by tuto adresu možno brát jako identifikátor uživatele. Oproti IP adrese by mezi výhody patřila unikátnost vzhledem k uživateli a možnost nastavení stejné adresy na více počítačích, pokud je uživatel má k dispozici. Samozřejmě by ale potom nebyl problém vložit do prohlížeče adresu cizí a tak se „za někoho vydávat“, čili spolehlivost by stejně byla velmi nízká. Zároveň by tato metoda trpěla podobnými nedostatky, jako některé z již zmiňovaných. Ohledně ukončení relace zde platí totéž, co bylo řečeno u HTTP autentizace – totiž že by nebyla možná. Stejně tak by se zde nepochybně vyskytly problémy s narušením soukromí obdobné těm již zmiňovaným v souvislosti s IP adresou, které budou ještě dále rozvedeny v kapitole o cookies. Na závěr uvedeme tabulku, která shrnuje vhodnost jednotlivých metod pro dané typy informací. Plyne z ní, že z metod pro přenos stavových informací založených čistě na samotném protokolu HTTP je pro transakční informace vhodné použít zejména jejich zakódování do URI do části query, případně je odesílat v těle požadavku metodou POST. Pro práci s informacemi identifikačními přicházejí v úvahu veškeré způsoby zakódování do URI (s vědomím příslušných problémů) a rovněž skrytá formulářová pole. Tabulka 1: Vhodnost metod přenosu prostředky HTTP pro různé typy informací Metoda Identifikační informace Transakční informace ANO ANO ANO spíše NE ANO NE Formulářová pole ANO (skrytá) ANO HTTP autentizace částečně NELZE spíše jako zabezpečení jiné metody NELZE v praxi NE NELZE za otazníkem Data virtuální adresář za názvem v URI virtuální adresář před názvem IP adresa Hlavička From 52 Použití IP adresy jako identifikátoru je sice z výše zmíněných důvodů krajně nevhodné, ale teoreticky možné. Strana 29 Kapitola 4: Cookies 4 Cookies Jak bylo vidět v předcházející kapitole, udržování stavových informací prostředky protokolu HTTP s sebou nese některé problémy a žádná z tam popisovaných metod není bez nedostatků. Během rozvoje služby WWW a nároků na ní kladených proto byl vyvinut mechanismus, který obohacoval protokol HTTP o jistou podporu práce se stavovými informacemi. Tento mechanismus však začal být také zneužíván k jiným než původním účelům, což vedlo v poslední třetině devadesátých let k vášnivým diskusím a vzrušení nejen v řadách odborníků, ale také u poměrně široké veřejnosti. Tato „aféra“ měla dosah až do vysokých politických kruhů. V této kapitole se budeme zabývat zejména vývojem a technickými detaily popisovaného mechanismu, ale nevyhneme se ani ostatním naznačeným souvisejícím tématům. 4.1 Základní funkce cookies Cookies mají sloužit k překonání bezstavovosti protokolu HTTP a přitom se do něho snaží co nejméně zasahovat. Celý mechanismus je založen na stejném základním principu, který již byl formulován v závěru subkapitoly 2.2 – aby mohly být v protokolu HTTP udržovány stavové informace na straně klienta, musí tyto být uvedeny v každém požadavku odesílaném serveru. V tomto případě se tak děje prostřednictvím zvláštních hlaviček odpovědi resp. požadavku SetCookie a Cookie53. První krok je na serveru, který může klientovi v odpovědi odeslat právě hlavičku Set-Cookie a v ní nějaká data, která si má klient zapamatovat. Ten je poté odesílá na server zpět s každým požadavkem podle definovaných pravidel v hlavičce Cookie. Velmi často se jedná právě o informace identifikačního charakteru, protože ale server může v dalších odpovědích odeslat další hlavičky Set-Cookie, které buď přidají další data, nebo stávající data změní, je možné takto uchovávat i některé typy transakčních informací. Notorickým příkladem (zmiňovaným již ve specifikaci) je zde virtuální nákupní košík obsahující položky vybrané v elektronickém obchodě. Cookie je tedy (většinou velmi krátký) textový řetězec, který HTTP server odešle klientovi a ten si jej uloží a nadále posílá zpět serveru s každým dalším požadavkem. Tolik tedy k základním principům, které schematicky znázorňuje také obrázek, a které jsou platné pro všechny verze cookies. Ty nyní budou postupně popsány a rozebrány. Obrázek 9: Obecné použití cookies 4.2 Specifikace Netscape Mechanismus cookies byl vytvořen společností Netscape Comunications Corporation54, tvůrcem jednoho z prvních komerčně úspěšných webových prohlížečů Netscape Navigator. Jak píše ve svém článku [18] David M. Kristol (jeden ze spoluautorů pozdějších RFC specifikací), z jeho komunikace s jedním z lidí, kteří stáli u zrodu společnosti Netscape Comunications Louem 53 V RFC 2965 jsou to Set-Cookie2, Cookie a Cookie2 54 Původně Mosaic Comunications Corporation Strana 30 Kapitola 4: Cookies Montullim (autorem první specifikace cookies a také spoluautorem dalších RFC specifikací55) vyplynulo, že ač to nebylo obecně známo, podpora cookies byla implementována již v první veřejně dostupné verzi Navigatoru ze září 1994. Údajně měla být tato vlastnost vyvinuta na přání jednoho ze zákazníků Netscape. Původní specifikace[29]56 je relativně stručná, nezachází do přílišných detailů a v některých ohledech je i nepřesná, což mj. vedlo ke snaze o pozdější standardizaci v rámci IETF. 4.2.1 K původu termínu „cookie“ V úvodu specifikace je popsán základní účel – mechanismus, kterým HTTP server může u HTTP klienta ukládat a opět od něho získávat informace napříč jednotlivými spojeními. Objekt který je tímto způsobem odesílán je zde nazýván cookie. Zde bychom rádi uvedli několik poznámek k tomuto pojmenování. Tento termín v angličtině v základním významu označuje sušenku či jiné obdobné sladké pečivo57. Specifikace doslova uvádí, že tento název byl vybrán aniž k tomu byl nějaký zvláštní důvod (for no compelling reason). Naproti tomu, jak uvádí [35] pod jedním z významů hesel cookie respektive magic cookie, jde o termín pocházející z prostředí operačních systémů UNIX, označující jakýsi objekt posílaný jedním programem druhému (zejména se může jednat o určitý typ identifikátoru). Obdobně se též o původu tohoto označení píše v [58]. To je popis, který se velmi dobře hodí také na tyto „internetové“ cookies a zřejmě odtud čerpal jejich autor (Lou Montulli) inspiraci když vybíral název. My budeme v tomto textu nadále užívat anglického termínu cookie (plurál cookies), neboť užívat termín „sušenka“ či jiné slovo obdobného významu se nám nejeví jako vhodné. 4.2.2 Hlavička Set-Cookie Každá cookie má určité vlastnosti a ty jsou definovány právě hlavičkou Set-Cookie, která se skládá z několika parametrů. Většina parametrů má název a příslušnou hodnotu, která se od parametru odděluje znakem rovnítka. Jednotlivé parametry se od sebe oddělují středníkem. Název a hodnota Základním a v této verzi jediným povinným parametrem je název a obsah informace, která má být uložena. Obojí se zapisuje jako jeden parametr ve formátu NAZEV=OBSAH. Je tak možné v rámci jednoho serveru uložit více cookies s různými názvy. Platnost Druhý parametr nese název Expires a udává, platnost cookie. Jde o to, jak dlouho má být daná informace uchovávána a odesílána zpět serveru. Cookies totiž umožňují udržení platnosti relace také po ukončení (a případném dalším nastartování) prohlížeče. V takovém případě se většinou ukládají do zvláštního souboru58, ze kterého jsou po novém spuštění prohlížeče načteny. V parametru Expires je uvedeno datum ve tvaru Wdy, DD-Mon-YYYY HH:MM:SS GMT59. To udává vypršení platnosti konkrétní dané cookie. Jestliže tento parametr uveden není, cookie je 55 Tento muž se na svém osobním webu[27] přiznává k podílu na autorství také dalších kontroverzních součástí WWW jako je HTML tag <blink> či implementace animovaných GIF obrázků do prohlížeče, ale také HTTPS či proxy. 56 Dodnes je tento dokument označen jako předběžný (preliminary) s varováním „užívat obezřetně“ 57 Není vyloučeno, že i tento fakt přispěl k tomu, že se kolem cookies šířilo tolik fám a mýtů zejména v anglicky psaném v tisku. Možná pokud by nebylo tohoto známého „kulinářského“ názvu , debata by se v takové míře nerozšířila za hranice odborných periodik. 58 tzv. cookie file V prohlížeči Netscape to byl soubor cookies.txt; Internet Explorer ukládá cookies do více souborů podle jednotlivých serverů. 59 Někdy jsou uváděny a akceptovány i mírně jiné formáty (např. s dvojciferným označením roku), ale ve specifikaci se uvádí tento. Strana 31 Kapitola 4: Cookies platná jen do okamžiku ukončení prohlížeče60 (tzv. session cookie). Někdy bývají tyto označovány termínem dočasné a ty, které přetrvávají po uzavření prohlížeče potom jako permanentní či trvalé. Toto označení však není přesné, neboť i ony jsou svým způsobem dočasné (do stanoveného času). Jde zřejmě buď o nepřesnost, nebo nevhodný překlad anglického termínu persistent. Doména Třetí parametr nese název Domain a umožňuje použití cookies na rozsáhlejších serverech velkých společností, které mají více domén nižších řádů. Pokud tento parametr není v hlavičce přítomen, cookie je odesílána pouze na ten server (s tím přesným doménovým jménem), který ji poslal. V opačném případě je odeslána na servery s takovým doménovým jménem, které končí (tail-match) hodnotou tohoto parametru61. Samozřejmě server nesmí do parametru nastavit cizí doménu. K dalšímu omezení možného příliš širokého spektra doménových jmen slouží podmínka, která stanoví minimální počet teček (čili oddělovačů doménových úrovní). To proto, aby nebylo možno nastavit parametr například na .com nebo .co.uk. Pro sedm zvláštních domén nejvyšší úrovně62 to byly dvě tečky, pro ostatní národní domény potom tři tečky63. Cesta Předposlední parametr Path je jistou obdobou předchozího, ovšem netýká se doménové hierarchie, ale adresářové struktury. Když není uveden, cookie je možné odeslat (po aplikaci pravidel týkajících se domény) pouze na stejnou adresu, ze které přišla příslušná hlavička Set-Cookie64. Jinak je odesílána se všemi HTTP požadavky, kde je parametr na začátku adresy. Zde již není výslovně uvedeno, že by bylo nutné, aby parametr odpovídal adrese dokumentu, se kterým je odesílán (jako u domény). Server tak může při požadavku na dokument z adresáře /neco vrátit cookie s parametrem Path nastaveným na hodnotu /jiny a ta projde a bude přijata. Bezpečné spojení Poslední parametr nemá žádnou hodnotu a zapisuje se tedy případně pouze jeho název. Ten zní Secure a označuje cookies, které (pokud je přítomen) smí být posílány pouze po zašifrovaném spojení. Cookies jsou totiž (jako ostatně všechny HTTP hlavičky) přenášeny po síti v otevřené textové podobě a to může být pro některá jejich potenciální využití nevhodné. Následující dva příklady ukazují nastavení cookie serverem. První z nich je minimální příklad, kdy je odeslána cookie s platností do konce relace (uzavření prohlížeče) odesílatelná pouze na stejnou adresu, odkud byla přijata (doména i adresář). V druhém případě jde naopak využito všech parametrů. Set-Cookie: jmeno=michal Set-Cookie: prijmeni=hauzirek; expires=Sun, 15-08-2004 11:23:00 GMT ; path=/; domain=.example.com; secure 60 Navigator ve verzi 1.1 a nižší údajně obsahoval chybu, kdy byly ukládány pouze cookies, které měly nastaven parametr Path (viz dále) na /. 61 Ač se dá předpokládat úmysl (zřejmý také z tam uvedených příkladů), že má jít pouze o domény nižší úrovně a ne tedy například example.com a anotherexample.com, výslovně to však uvedeno není. Navíc u parametru Path se tento princip uplatňuje a cookies s Path nastaveným na /foo mají být odesílány i do adresáře /foobar. Bylo by možné argumentovat počtem dvou nutných teček v parametru, kdy jedna z nich by byla na začátku (.example.com). Takový příklad ale ve specifikaci není. Z provedených pokusů s ranými verzemi Navigatoru však vyplývá, že akceptují i cookies které mají v Domain o jednu tečku méně než vyžaduje specifikace (tedy 1 resp. 2). 62 COM, EDU, NET, ORG, GOV, MIL a INT 63 Tato myšlenka zřejmě vychází z předpokladu, že veškeré národní domény budou obdobně členěny o úroveň níže dle charakteru. Například com.cz, edu.cz apod. 64 Není přesně specifikováno, zda má jít o kompletní adresu (tedy tentýž dokument), což by z textu spíše vyplývalo, nebo pouze tentýž adresář. Navigator od počátku aplikuje druhý přístup. Strana 32 Kapitola 4: Cookies 4.2.3 Chování klienta a hlavička Cookie Jak již bylo řečeno, klient odesílá serveru hodnoty cookies v hlavičce požadavku s názvem Cookie. Ta obsahuje pouze název a hodnotu oddělené opět rovnítkem. Je možné odeslat také více těchto dvojic najednou, v tom případě se oddělují stejně jako parametry, tedy středníkem65. Ze všech cookies, které má klient uložené před odesláním požadavku, vybere ty, které jsou stále ještě platné a odpovídají doménou, adresou a případně parametrem Secure a ty následně odešle. Podle specifikace by klient měl být schopen uložit celkem alespoň tři sta cookies. Limit pro jeden server (či doménové jméno) je dvacet. Přitom je počítáno, že jedna cookie by neměla mít velikost přesahující čtyři kilobyty. Cookies se stejnými názvy se při přijetí přepisují pouze za předpokladu, že mají také stejnou doménu a cestu (path). Jinak zůstávají jako dvě různé cookies vedle sebe. Protože tak pro jeden server může být uloženo více cookies se stejnými názvy, měl by je klient posílat seřazené podle konkrétnosti parametru Path (konkrétnější dříve). Za předpokladu, že klient obdržel obě cookies z předzházejícího příkladu ze a adresy jiné, než pouze /, obsahoval by další požadavek následující hlavičku. stejné domény Cookie: jmeno=michal; prijmeni=hauzirek 4.3 RFC 2109 Předchozí subkapitola popisovala první specifikaci cookies, která byla svým způsobem proprietární a v některých ohledech poměrně nepřesná. Skutečný formální standard to nebyl a proto bylo nutné jej vytvořit. Prvním z nich byl v únoru 1997 dokument RFC 2109. Zde si popíšeme nejen rozdíly oproti specifikaci Netscape, ale také některé okolnosti jeho vzniku. 4.3.1 Okolnosti vzniku Jak píše David M. Kristol[18], kolem roku 1995 bylo kromě mnoha dalších témat (popsání HTTP 1.0 či řešení jeho zásadních problémů zmiňovaných v úvodu subkapitoly 1.4) bylo mezi zainteresovanými diskutovaným tématem také rozšíření HTTP o určitou podporu udržování stavových informací. Původně se přemýšlelo o tom, že by byla začleněna přímo do další verze protokolu HTTP. V průběhu diskusí o ní byla ale tato snaha vyčleněna do samostatné podskupiny (jejímiž členy byli jak Kristol, tak i již zmiňovaný Montulli). Původně bylo plánováno, že až bude tato problematika samostatně vyřešena, bude opět zařazena zpět a objeví se jako součást protokolu HTTP. V této skupině se od původních návrhů66 postupně dospělo k názoru, že nový mechanismus by neměl být konkurentem výše zmiňovaných cookies od Netscape a měl by s nimi být kompatibilní. Nakonec bylo rozhodnuto vycházet přímo z této původní specifikace ovšem s tím, že musela být v mnoha ohledech precizována a upřesněna (v souladu s požadavky na standardy). 65 Již v HTTP 1.0 se uvádí, že v jednom požadavku či odpovědi je možné uvést více hlaviček stejného jména, pokud je možno jejich hodnoty beze změny významu zkombinovat dohromady oddělené čárkou. Z tohoto pohledu by se tedy jevilo lepší užít jako oddělovače čárku. 66 Jedním z nich byly například jakési jednorázové identifikátory, které by byly platné pro jedno spuštění prohlížeče a odesílány spolu s požadavky. Strana 33 Kapitola 4: Cookies 4.3.2 Nedostatky specifikace Netscape Originální specifikace trpěla některými zásadními nedostatky. Bylo nutno například doplnit přesnou syntaxi hlaviček Set-Cookie a Cookie včetně toho, zda u parametrů záleží na velikosti písmen. Protože hlavičky se stejným názvem je v HTTP možné spojovat pomocí čárky, mohlo být datum v parametru Expires které čárku obsahuje nesprávně interpretováno. Řešením by byla možnost uvádění hodnot v uvozovkách, ani to však původně nebylo zavedeno. Algoritmus pro ověřování domén (dvě resp. tři tečky) nebyl vyhovující a zcela jasná nebyla výchozí hodnota parametru Path, pokud není explicitně uveden. Problematické také bylo to, že server na jedné doméně mohl obdržet zpět cookies pocházející z jiného serveru na jiné doméně (pokud se oba nacházely ve stejné doméně vyšší úrovně). Pokud měly tyto cookies stejná jména, nemohl server poznat, která z nich je „ta jeho“. Za určitých okolností tak útočník mohl zmást server a podstrčit mu neočekávaná data. (Cookie Spoofing). Tuto situaci znázorňuje následující příklad s malými změnami převzatý z [40]. 1. Klient odešle požadavek na server victim.cracker.edu a obdrží cookie session_id=1234 pro niž nastaví výchozí doménu victim.cracker.edu. 2. Tentýž klient odešle požadavek na server spoof.cracker.edu a obdrží cookie session_id=1111 s doménou explicitně nastavenou na .cracker.edu. 3. Týž klient opět odešle požadavek na victim.cracker.edu a spolu s ním odešle Cookie: session_id=1111; session_id=1234 Server tak obdrží dva různé identifikátory a nemá možnost poznat, který z nich je „ten pravý“. Jak se zachová, tedy zda zpracuje první, druhý, případně vypíše chybu závisí na konkrétní aplikaci. K dalším diskutovaným tématům patřila otázka, jak pracovat s cookies, které přicházejí z různých portů tj. brát různé porty téhož serveru tak, že představují stejnou společnou doménu, nebo ne. Tato otázka ale ještě v této specifikaci vyřešena nebyla. 4.3.3 Neověřitelné transakce a cookies třetích stran Z pozdějšího pohledu se ale jako mnohem zásadnější ukázala diskuse o takzvaných neověřitelných (unverifiable) transakcích později v této souvislosti spíše známých jako cookies třetích stran (thirdparty). K méně technické stránce problémů, které jsou s nimi spojeny se detailně vrátíme v subkapitole 4.5.1. Prozatím alespoň poznamenejme, že jejich použitím v rozporu s původním účelem tohoto mechanismu, je za určitých podmínek možné sledovat, po kterých serverech se uživatel při používání služby WWW pohybuje. Problém spočívá v tom, že prohlížeč služby WWW poměrně často zasílá HTTP požadavky i na jiné servery, než si je uživatel přímo vědom. Děje se tak zejména pokud získává dokumenty, které jsou nějakým způsobem vloženy do uživatelem požadovaných dokumentů. To se týká (jak již bylo zmiňováno v subkapitole 1.4 v souvislosti s nutností znovuotevírání přenosového kanálu) zejména obrázků či skriptů. Ty nemusejí pocházet ze stejného serveru jako původně požadovaný dokument a prohlížeč se tak připojuje i k jiným serverům, než které uživatel „objektivně navštívil. Jestliže cookie (resp. hlavičku Set-Cookie) je možné poslat s jakoukoli HTTP odpovědí obsahující libovolný dokument, je možné, že ji prohlížeč obdrží také při podobném požadavku. Pokud bude ze stejného serveru někdy v budoucnu získávat další dokument (například opět jako kamsi vložený obrázek), odešle spolu s požadavkem na tento „cizí“ server také hodnotu cookie. Takovéto objekty ukazující na tentýž server (nebo jejich skupinu dle nastavení parametru Domain) Strana 34 Kapitola 4: Cookies mohou být vloženy v dokumentech na mnoha jiných serverech (což je například běžné u poskytovatelů reklamních služeb, či služeb pro měření počtu přístupů). Po dobu platnosti dané cookie tak dotyčný server může (například z hlavičky Referer, která je při této příležitosti také odesílána, ale i jinak) sledovat, z kterého serveru byl klient k požadavku nasměrován. Jestliže mají cookie odesílané na tento server dlouhou dobu platnosti a obsahují jedinečný identifikátor (jak tomu zpravidla bývá), lze také k uživateli (prostřednictvím tohoto identifikátoru) přiřazovat servery, které navštívil a tvořit tak jeho profil. Proto byl do nové specifikace zaveden termín neověřitelné transakce. To jsou takové požadavky, u kterých si uživatel nemůže předem ověřit jejich URI. Klasicky jde o požadavky na vložené objekty, ale také například automatická přesměrování stavovými kódy67. Celý proces schematicky znázorňuje obrázek 10, kde klient postupně navštíví dva HTTP servery (example.net a another.com), ze kterých získá různé HTML dokumenty ovšem z obou s vloženým obrázkem ze serveru ad.com. V odpovědi na první požadavek je z něho klientovi odeslána identifikační cookie, kterou ten odesílá v následujících požadavcích. Na serveru ad.com je pro klienta na základě identifikátoru vytvářen profil dle navštívených serverů. Zmiňované neověřitelné transakce (požadavky) jsou znázorněny čárkovaně. Obrázek 10: Neověřitelné transakce a užití cookies třetích stran k profilování 4.3.4 Hlavní změny v RFC 2109 Podpora stavových informací nebyla nakonec implementována přímo do protokolu HTTP, ale byla vydána jako samostatný standard až v únoru 1997 (na rozdíl od lednového RFC 2068 – HTTP 1.1) jako dokument RFC 2109[40]. Ten obsahuje mimo jiné precizně popsaná pravidla pro syntaxi hlaviček (např. hodnoty parametrů mohou být uzavírány do uvozovek) a také několik podstatných změn a vylepšení ve funkčnosti oproti specifikaci Netscape. Kvůli kompatibilitě s původní verzí byl do hlavičky Set-Cookie přidán nový povinný parametr Version=1 označující cookie podle RFC 2109. Cookies které ho neobsahují, jsou pokládány za původní cookies dle Netscape. Dále bylo stanoveno, že prvním parametrem musí být název a hodnota68 a na dalším pořadí parametrů nezáleží. Problematické Expires s čárkou, která mohla způsobovat potíže, bylo nahrazeno parametrem s názvem Max-Age, jehož hodnotou byl počet sekund, po který má být daná cookie platná. Přibyl ještě jeden nový parametr a sice Comment, který umožňuje uživatele například informovat o účelu ke kterému je cookie zasílána. 67 V to nejsou zřejmě počítána kliknutí na odkaz (většinou prohlížeč zobrazí cílové URI) či odeslání formuláře. 68 To bude důležité v souvislosti s nekompatibilitou Internet Exploreru o které se zmíníme dále. Strana 35 Kapitola 4: Cookies Upřesněno bylo, že výchozí hodnotu atributu Path, pokud není uveden, tvoří nikoli celá cesta k požadovanému souboru, ale pouze její adresářová část (po poslední znak / ovšem bez něho). Je-li uveden, musí již jeho hodnotou začínat také cesta k požadovanému dokumentu. Změn se dočkalo také zacházení s doménovými jmény. Pokud je v této verzi cookies explicitně uveden parametr Domain, musí začínat tečkou. Jinak je doplněno jméno serveru bez tečky na začátku. Pro porovnávání doménových jmen byla zavedena nekomutativní operace „domainmatch“. Pomocí té se určuje, zda má být na server s daným doménovým jménem odeslána ta která cookie. V podstatě jde opět buď o tutéž doménu nebo domény nižších úrovní. Jisté omezení je však v tom, co je možné zapsat do parametru Domain. Předešlý „tečkový“ algoritmus byl nahrazen sofistikovanějším a také více omezujícím. Cookie má být odmítnuta mimo jiné, pokud je v parametru Domain uvedeno doménové jméno výše než o jednu úroveň nad jménem serveru. Kvůli hodnotám jako .com musí také obsahovat alespoň jednu tečku uvnitř. Podstatnou změnou prošla také hlavička Cookie, kterou klient vrací hodnoty. Povinně je teď uvozena znaky $Version=1; označujícími použitou verzi. Následuje tradiční seznam párů název-hodnota, ovšem s dalšími proměnným. Pokud totiž byla cookie přijata s explicitně nastavenými parametry Path či Domain, jsou tyto serveru odeslány také zpět. Předchází se tak podstrčení cookies (cookie-spoofing) naznačenému v příkladu na straně 34. Jeho třetí řádek by nyní vypadal následovně. 3. Týž klient opět odešle požadavek na victim.cracker.edu a spolu s ním odešle Cookie: $Version=1; session_id=1111; $Domain=.cracker.edu; session_id=1234; Server tak nyní může poznat, která z hodnot byla nastavena cizím serverem. Jak je vidět, pro pomocné údaje se užívají názvy začínající znakem $. Ty jsou vyhrazené a nemají být používány pro názvy vlastních proměnných užívaných v aplikacích. Servery, které podporují pouze Netscape cookies s nimi, díky jejich způsobu zápisu, budou zacházet jako s běžnými cookies a nehrozí tak tedy z této strany nekompatibilita. Velmi významný byl také požadavek na prohlížeče, že v případě neověřitelných transakcí, nesmí odesílat žádné cookies na cizí servery69, respektive mohou tak činit pokud to uživatel povolí. Jako výchozí stav ale musí mít prohlížeč nastaveno v takových případech neodesílat. Následují příklady stejných cookies jako v předchozí subkapitole. Set-Cookie: jmeno=michal; Version=1 Set-Cookie: prijmeni=hauzirek; Max-Age=864000; path=/; Version=1; domain=.example.com; secure; comment=testovaci Cookie: $Version=1; jmeno=michal; prijmeni=hauzirek; $Domain=.example.com; $Path=/ 4.4 RCF 2965 a 2964 Po vydání RFC 2109 se rozběhla obsáhlá a vášnivá diskuse zejména ze strany internetových reklamních společností, které protestovaly proti zakázání cookies třetích stran či přesněji jejich deaktivování v základním nastavení. Tomuto tématu je věnována subkapitola 4.5.1. Objevily se ale také další – techničtější problémy. 69 Přesně tu je napsáno, že je smí odeslat pouze, pokud je odeslal či obdržel také při té transakci, které vedla k vyvolání neověřitelné transakci (tedy při získání hlavního dokumentu). Toto omezení je až nečekaně přísné a autoři jej také v další verzi upravili tak, že není nutné, aby v původní transakci došlo k odeslání, či příjmu cookie. Omezení je tam řešeno přes doménová jména. Strana 36 Kapitola 4: Cookies 4.4.1 Nekompatibilita Internet Exploreru Po schválení (ale ještě před definitivním vyhlášením) RFC 2109 byla objevena nečekaná a poměrně závažná nekompatibilita v tom, jak s novým formátem hlaviček zacházel Microsoft Internet Explorer ve verzi 370. Tržní podíl tohoto prohlížeče byl v té době podíl zastoupení třiceti procent a stále rostl. Hlavní problém spočíval ve faktu, že zatímco Netscape jako název cookie chápal v pořadí první neznámý parametr, Internet Explorer takto zacházel s neznámým parametrem posledním. Pokud se jednalo o hlavičku podle původní specifikace, výsledné chování bylo stejné. Jestliže však přijal hlavičku novou s novými parametry Max-Age či Version, místo požadovaného názvu a hodnoty cookie byly uloženy právě tyto parametry. Příčinou byla mimo jiné nedokonalá specifikace Netscape cookies, kdy nebylo výslovně specifikováno, kolikátý parametr v pořadí obsahuje název a hodnotu a jak přesně má prohlížeč zacházet s neznámými parametry. Jako možná řešení tohoto problému se objevovaly zejména dva návrhy. Prvním z nich bylo zavedení jiné hlavičky pro „nové“ cookies, než té, která byla použita u Netscape. To by s sebou přineslo sice úplnou nekompatibilitu (ne zcela pokud by byly odesílány vedle sebe obě hlavičky) se starými prohlížeči, ale bylo by možné oprostit se od problémů s ní spojených. Hrozil však začarovaný kruh, kdy by kvůli v té době již poměrně velkému rozšíření „starých“ cookies na mnoha serverech musela být tato varianta stále ještě podporována i v novějších prohlížečích. Z toho důvodu by pak provozovatelé serverů neměli závažnější důvod přejít na novou specifikaci (což by s sebou přineslo náklady). Po podpoře nového mechanismu v prohlížečích (opět náklady tentokrát pro vývojáře) by tedy také nebyla poptávka71. Druhý, velmi vtipný, návrh vycházel přímo z popsané situace a myšlenky asi ve smyslu: „Pokud jeden prohlížeč potřebuje název a hodnotu na začátku a druhý na konci, proč ho nedat na oba konce?“ Dvojice název-hodnota by tak byla klasicky na začátku hlavičky a zopakovala by se ještě jednou na jejím konci. Tato myšlenka byla jednoduchá a zdála se funkční. Zvedly se však některé hlasy proti tvrdící, že je to nesystémové řešení, které vede téměř ke zdvojnásobení délky přenášených dat. Navíc se ukázalo, že ji nebylo možné uplatnit v Internet Exploreru verze 272 a tak byla definitivně opuštěna. 4.4.2 Další diskutovaná témata V diskusích se objevovaly také další návrhy na novou specifikaci cookies. Protesty reklamních společností proti zákazu cookies třetích stran a na druhé straně různých ochránců práv (viz subkapitolu 4.5.1) vedly k úvahám o jakémsi druhu „certifikovaných cookies“, které by byly digitálně podepsány důvěryhodnou autoritou, která by garantovala, že data takto získaná nebudou zneužita. Tyto práce ale nebyly dotaženy do konce a zmiňované myšlenky se tak staly pouze inspirací pro některé další protokoly sloužící k ochraně soukromí uživatelů (viz dále). Opět se otevřela diskuse nad tím, pro které porty má být cookie platná a na jaký rozsah serverů má být zasílána. Také se objevily požadavky na poskytnutí detailnější informace uživateli. Tyto a některé další připomínky se odrazily v konečném znění specifikace, která byla jako RFC 2965[46] vydána až v říjnu 2000 (!). Zároveň s ní byl také vydán dokument RFC 2964[45], který popisoval 70 Mně se níže popsané chování při testech podařilo docílit pouze u testované verze 2.0. Dostupná verze 3.0.1152 zacházela s hlavičkami správně. 71 K této situaci nakonec také došlo a cookies dle RFC 2965 nejsou podporovány ani v nejnovějších verzích dnes dominantního Internet Exploreru, ani Mozilly. Svůj podíl na tom měla jistě také neúměrně dlouhá doba předcházející vydání finální podoby dokumentu. 72 Tento přístup na mnou testované verzi MSIE 2.0 fungoval. Strana 37 Kapitola 4: Cookies některé doporučené a naopak nedoporučené způsoby použití cookies také s ohledem na ochranu soukromí. 4.4.3 Změny v RFC 2965 Jak již bylo naznačeno, původní hlavička Set-Cookie byla nahrazena a sice hlavičkou s názvem Set-Cookie2. Její formát zůstal stejný jako v RFC 2109, ale přibylo několik nových parametrů. Kromě existujícího parametru Comment byl zaveden parametr CommentURL, který může obsahovat URI dokumentu, kde je detailně (a například pomocí vyjednávání o obsahu i v jazyce uživatele) popsán účel, k němuž jsou cookies používány. Další nový parametr je Port. Ten může být uveden buď samostatně bez hodnoty, v takovém případě je cookie klientem odesílána pouze na port, ze kterého přišla. Může také obsahovat hodnotu, kterou tvoří seznam portů a v takovém případě je odesílána pouze na tyto porty. Pokud parametr Port přítomný není, lze cookie odeslat na libovolný port. Poslední nový parametr také nemá hodnotu a nese jméno Discard. Jestliže je přítomen, je cookie vždy smazána po ukončení prohlížeče i když její platnost dle parametru Max-Age ještě nevypršela. Je tedy smazána buď po vypršení platnosti, nebo po zavření prohlížeče podle toho, co nastane dříve. Dalších parametrů se týkají některé dílčí změny. Výchozí hodnotou pro Path je nyní opět cesta k adresáři požadovaného dokumentu, ale včetně koncového lomítka. Doména již nemusí povinně začínat tečkou. Pokud je explicitně nastavena a tečkou nezačíná, prohlížeč tečku doplní. S parametrem Domain souvisí i další změna – pro podporu sdílení cookies v intranetovém prostředí je vyhrazena speciální doména nejvyšší úrovně .local. Jako označení verze zůstává číslo jedna, některé další formulace byly zpřesněny. Přibylo zakomponování nového parametru Port do pravidel pro odmítání cookies (pokud cookie přijde z jiného portu, než který je tam explicitně uveden, je odmítnuta). Také bylo napraveno příliš přísné pravidlo pro příjem cookies pomocí neověřitelných transakcí. Nicméně stále platí, že z cizích serverů nesmí být při výchozím nastavení prohlížeče přijímány. Hlavička, kterou jsou cookies odesílány serveru zůstala stejná tj. Cookie. Ke speciálním parametrům přibyl v celku očekávaně $Port. Definována byla také nová hlavička Cookie2, kterou má klient odeslat v případě, že obdrží starou hlavičku Set-Cookie, aby tím dal serveru najevo, že umí pracovat s vyšší verzí. 4.4.4 Velké zpoždění a neúspěch RFC2965 Práce na nové specifikaci začaly prakticky ihned po vydání té předchozí (tedy na počátku roku 1997). Přestože nový dokument RFC 2965, který novou specifikaci obsahuje není až tolik odlišný od toho předchozího, trvalo jeho vydání z mnoha důvodů (viz [18]) tři a půl roku. Během této doby se nejen vyměnila podstatná část vedení IETF, ale zejména se internet ještě dále rozrostl a rozvinul. Obrovský nárůst uživatelů mezi léty 1997 a 2000 s sebou nesl také rychlý rozvoj služeb. Jedním ze způsobů, jak na internetu vydělávat, se stala reklama vkládaná do internetových stránek. Z níže popsaných důvodů byla často spojena právě s využitím cookies třetích stran. Mezitím se také Internet Explorer stal z velké části dominujícím prohlížečem a ustalo velmi rychlé vydávání nových verzí prohlížečů, běžné dříve právě z důvodu silné konkurence. Ač se již v prvním RFC říkalo, že podpora pro cookies třetích stran má být v základním nastavení zakázána, žádný z hlavních producentů prohlížečů (míněno Microsoft a Netscape) tak neučinil. Spíše než na stranu uživatelů, kteří již od jisté doby za prohlížeč nemuseli platit, postavily se tyto Strana 38 Kapitola 4: Cookies firmy za zájmy reklamních společností a provozovatelů serverů vůbec. Kromě prohlížečů (v té době již zdarma) totiž dodávaly také serverová řešení (ta samozřejmě zdarma nebyla). Zákazníky z řad těch platících si samozřejmě předcházely více. Tyto faktory mimo jiné přispěly k tomu, že standard RFC 2965 nebyl dodnes implementován do žádného z vedoucích prohlížečů73. Ačkoli některé ostatní minoritní prohlížeče jej implementují velmi přesně74, tato skutečnost prakticky brání většímu rozšíření cookies dle RFC 2965 na serverech. Opět následují příklady hlaviček. Set-Cookie2: jmeno=michal; Version=1 Set-Cookie2: prijmeni=hauzirek; Max-Age=864000; path=/; domain=.example.com; secure; comment=testovaci; Version=1; commentURL="http://www.example.com"; discard; port="80,81,8080" Cookie2: $Version=1 Cookie: $Version=1; jmeno=michal; prijmeni=hauzirek; $Domain=.example.com; $Path=/; $Port="80,81,8080" 4.5 Cookies a ochrana soukromí Jak bylo již na několika místech zmíněno, s cookies jsou spojeny otázky týkající se ochrany soukromí a anonymity na internetu. Tento mechanismus se za poměrně krátkou dobu své existence stal velice diskutovaným tématem a to nejen mezi odbornou veřejností, ale také v obecném tisku a dokonce v mezinárodní politice. Zejména různá neodborná vyjádření tak přispěla k šíření silně zkreslených informací, které byly silně zavádějící. Také proto se nyní není možné při návrhu aplikací zcela spoléhat právě na tento mechanismus přenosu informací a je nutné počítat s možností, že jeho podpora bude v prohlížeči uživatele deaktivována. Mnohem větší vinu na tom ale nese samozřejmě jeho zneužívání k jiným účelům, než pro které byl původně určen. To totiž přišlo jako první a posloužilo jako impuls k dalším akcím. 4.5.1 Cookies třetích stran a reklama Výše jsme v souvislosti s neověřitelnými transakcemi hovořili o tom, že cookies třetích stran s dostatečně dlouhou dobou platnosti mohou být užívány pro sledování uživatelova pohybu po webových serverech. Oproti jiným možným způsobům této činnosti mají cookies dvě nesporné výhody. Je totiž možné je udržovat dlouhou dobu i po zavření prohlížeče a navíc pro běžného uživatele nejsou vidět. Nyní se dostáváme k tomu, proč vůbec je takováto činnost někým provozována. Nejčastěji jde o takzvané profilování uživatelů – tedy snahu vytvořit pro jednotlivé uživatele individuální profily tak, aby byly zjištěny jejich záliby a zájmy. Tyto (stále anonymní) profily jsou potom užívány pro přesnější zacílení reklamy. Zacílená reklama je vždy úspěšnější (a přináší tedy vyšší zisky) než prostá celoplošná, kdy jsou potenciální zákazníci oslovováni náhodně či hromadně. Oproti hromadné reklamě jsou rovněž náklady na jednoho získaného zákazníka mnohem nižší. V internetovém prostředí, kdy jsou reklamní společnosti často placeny v případě klasických reklamních bannerů nejen za pouhé zobrazení, ale zejména za kliknutí na reklamu uživatelem, je také v jejich zájmu, aby co nejvíce reklamy bylo správně zacíleno. 73 Pro přesnost, z předchozího RFC 2109 se implementace dočkal pouze parametr Max-Age v Mozille (viz testy dále). 74 Z dále testovaných to je téměř vzorovou implementací Lynx a s jistými výhradami též Konqueror a Opera. Strana 39 Kapitola 4: Cookies Když uživatel odešle na reklamní server svůj požadavek (nejčastěji právě jako neověřitelnou transakci) spolu s příslušnou cookie, která jej identifikuje, je na základě tohoto identifikátoru a doposud zjištěných oblastí zájmu vybrána příslušná reklama, která by jej mohla zaujmout75. Profily jsou také obohacovány informacemi o tom, na které reklamy uživatel skutečně klikl, které pomáhají dalšímu zpřesňování. Profilování zákazníků jako takové je s nástupem výkonných informačních technologií do obchodu obecně poměrně rozšířené76 a provádí jej řada větších podniků. Zásadní rozdíl tu však je ten, že se většinou jedná o jejich zákazníky, kteří se jimi stali z vlastní vůle. Taková situace nastává například pokud zákazník v supermarketu užívá věrnostní kartu (která slouží jako jeho identifikátor). Ačkoli je možné, že o tom neví, umožňuje tak supermarketu zjišťovat, jaké zboží kdy nakupuje, případně jak reaguje na nabízené slevy apod. K tomu ale při vystavení této karty dal svůj souhlas. Něco jiného je, když jsou pro tvorbu profilů používány cookies. Ty jsou pro většinu běžných uživatelů skryté a navíc užívání služby WWW je obecně spojeno s jakýmsi pocitem anonymity. Vehementní protesty reklamních společností proti ustanovením v RFC 2109, která se týkala výchozího nastavení prohlížečů byly vyvolány zejména obrovským podílem nezkušených uživatelů pohybujících se internetu. Takoví totiž nejen nevědí, co to cookies jsou, ale také jen velmi zřídka mění výchozí nastavení svého prohlížeče. Toto opatření by se tak téměř rovnalo úplnému zákazu cookies třetích stran (neboť zkušenější uživatelé by rozhodně neměli důvod jej povolovat). Odtud tedy vychází základní zdroj protestů ochránců soukromí. Hlasy proti tomuto způsobu užívání cookies se začaly objevovat zejména v době po zveřejnění RFC 2109, ale již i předtím [7]. Vzniklo několik serverů věnujících se výlučně této problematice (např. [10], [11] či [60]). Pro přesnost jen doplňme, že profilování je možné nejen používáním cookies třetích stran, ale také za pomoci klasických cookies. V tomto případě ale není informace o uživateli zdaleka tak přesná, neboť pochází pouze z jeho chování na jediném serveru77. DoubleClick a Abacus-Direct Další mediální pozdvižení způsobila zejména aféra okolo největší americké webové reklamní společnosti DoubleClick. Ta totiž v roce 1999 ohlásila spojení se společností Abacus[19], která vlastnila velkou databázi obyvatel obsahující jména i adresy. Objevilo se tak podezření, že obě společnosti chtějí své databáze (webových profilů a adres) spojit[20] a získat tak velkou databázi konkrétních lidí a jejich zájmů. Jako možné klíče ke spojení měly být použity například jména a adresy, které uživatelé zadali na webových stránkách některých zákazníků DoubleClick (těch, kterým poskytoval reklamu) třeba v rámci internetových obchodů. Proti tomu okamžitě začali protestovat ochránci práv a se společností DoubleClick bylo zahájeno vyšetřována americkou Federal Trade Commission. Evropská komise Cookies však nebyly horkým tématem pouze ve Spojených státech, ale také v Evropě. Na půdě Evropské Komise byly v rámci ochrany soukromí občanů členských zemí mimo jiné také hojně diskutovány. O nepříliš dobrém pochopení jejich původního významu svědčí také to, že původně 75 V primitivnějších verzích jsou identifikátory užívány pouze k zamezení opakovanému zobrazení stejné reklamy. 76 Viz celá široká oblast ICT nazývaná CRM – Customer Relationship Management. 77 Ani tak to ale v některých případech nemusí být zbytečné. Běžně je takto zjišťován obvyklý pohyb uživatele po webu a jeho případné další návraty z důvodů vylepšení navigace či hodnocení úspěšnosti reklamy. Na některých typech serverů (zejména portálového typu) je klasické profilování také možné, neboť je zde zastoupeno relativně široké spektrum zájmů. Navíc je možné do něho zahrnout také termíny zadané do vyhledávačů. Bez zajímavosti v této souvislosti není, že v současnosti vyhledávací server Google posílá identifikační cookies s dobou platnosti do roku 2036. Strana 40 Kapitola 4: Cookies s nimi mělo být zacházeno jako s nevyžádanou reklamní poštou – tedy bez výslovného souhlasu adresáta (v tomto případě uživatele prohlížeče) neměly být povoleny. Nakonec (velmi se o to zasloužila lobby právě on-line reklamních společností) je vyžadováno pouze důsledné informování uživatele. P3P v MSIE 6 Všechny tyto okolnosti vedly postupně k tomu, že v prohlížečích začala přibývat nastavení, která umožňovala uživateli bránit se takovým cookies. Stále však zůstávala ve výchozím nastavení zpravidla deaktivovaná. Jistý zlom v tom přinesl až Internet Explorer ve verzi 6, který implementoval standard P3P a ve výchozím nastavení odmítal cookies třetích stran, které neměly definovány příslušné politiky. 4.5.2 P3P První zásadní průlom do výchozího zacházení s cookies přinesl v roce 2001 Internet Explorer ve verzi 6.0. Ten měl totiž zcela nově implementovánu podporu standardu P3P78. P3P[57] (The Platform for Privacy Preferences79) se zdaleka netýká pouze cookies, ale jde o iniciativu, která se zabývá ochranou soukromí v rámci služby WWW jako celkem. Jde o jednu z reakcí na zmiňované problémy s ochranou soukromí, které celé internetové prostředí v očích široké veřejnosti diskreditovaly. Krátce k P3P obecně Standard P3P byl vyvíjen poměrně dlouho a spolupracovalo na něm mnoho lidí z různých oborů. Představuje jakýsi kompromis mezi obavou o soukromí uživatelů a obchodními zájmy reklamních a dalších společností. Stručně řečeno definuje pravidla, kterými je možno ve strojově čitelné podobě popsat politiku zacházení s osobními údaji návštěvníků webových serverů. K jejím základním částem patří údaje o totožnosti provozovatele serveru a případný kontakt na něho. Dále je uváděno spektrum informací, které jsou získávány (v různých třídách – anonymní statistiky, skutečně osobní informace apod.) a zásady práce s nimi (jak jsou získávány – s výslovným souhlasem nebo bez, jak dlouho jsou uchovávány, k jakým účelům, komu mohou být dále poskytnuty). Patří sem také údaje o tom, zda má subjekt informací možnost zjistit, jaké informace jsou o něm uchovávány a případně požadovat jejich vymazání. Znalý návštěvník s příslušným softwarem se tak může rozhodnout, zda daný server navštíví a případně, jaké osobní informace mu poskytne a to bez zdlouhavého pročítání složitých bezpečnostních politik. Samozřejmě nelze tímto způsobem zaručit, že takto popsaná politika bude také dodržena. Politiky jsou zapisovány jako XML soubory s přesně definovanou strukturou. Je rovněž možné je ve zjednodušené verzi zasílat v HTTP hlavičce s názvem P3P. Oproti původnímu plánu standard neobsahuje kontroverzní mechanismus pro automatický přenos osobních informací na server. To byl totiž také jeden z návrhů v souvislosti s profilováním uživatelů – namísto aby společnosti zjišťovaly záliby uživatelů, ti si měli z údajů, které o sobě chtěli zveřejnit, sestavit vlastní profil a ten jim potom poskytovat (viz Open Profiling Standard[30]). Blíže k celému standardu P3P viz velice obsáhlou specifikaci [57] a přidružené dokumenty [55], [56], či v českém jazyce například články [48], [50]. 78 Paradoxně to ale nemohla být jeho finální verze, neboť ta nese datum až z dubna 2002. 79 Tomu by spíše odpovídalo označení P3, která také iniciativa původně skutečně nesla. Kvůli sporům o ochranou známku ovšem bylo do označení přidáno ještě jedno 'P' – označující Project[56]. Strana 41 Kapitola 4: Cookies Implementace P3P v MSIE 6 Internet Explorer ve verzi 6 má pro práci s cookies jako výchozí (a tedy většinou uživatelů používanou) úroveň zabezpečení nazývanou Medium. Nejdůležitější pravidlo je, že jsou blokovány cookies třetích stran, které nemají nastavenu P3P politiku. Dále jsou blokovány cookies třetích stran z těch serverů, které mají v P3P politice uvedeno, že jsou jimi sbírány osobní údaje konkrétně identifikující osobu bez jejího výslovného souhlasu. Zásadní zlom tu nastává právě kvůli prvnímu pravidlu. To, vezmeme-li v potaz rozšíření Internet Exploreru, nutí servery, které využívají pro svou činnost cookies třetích stran, aby alespoň definovali vyhovující P3P politiku. To, že ji budou dodržovat a pouze do ní nenaskládají takové značky, aby jejich cookies Internet Explorer propustil, ovšem zaručit nelze. Pouhou implementací standardu P3P do prohlížečů se samozřejmě všeobecnému zneužívání cookies nezabrání. Lze tak možná pouze mírně zvýšit informovanost uživatelů, ovšem v současném stavu opět pouze těch základních principů P3P znalých. Z dalších prohlížečů, které v sobě mají v aktuálních verzích zabudovánu podporu P3P je možno jmenovat například Mozillu, ač tam není zacházení s cookies dle těchto politik jako výchozí nastaveno80. Jakýmsi přídavným modulem do Internet Exploreru, který překládá P3P politiky do srozumitelné angličtiny je PrivacyBird od AT&T[3]. 4.5.3 Mýty okolo cookies Časté (a ne vždy zcela přesné) zmínky o cookies v médiích (viz např. [4]) přispěly k rozšíření mnoha mýtů. Dílem to bylo vinou nepochopení jejich principu a dílem uváděním nepřesných a zkreslujících formulací v médiích. Některé z těch nejčastějších zde na závěr subkapitoly pro zajímavost zmíníme. První mýtus pramení ze situace, kdy někteří uživatelé prozkoumali soubor, do kterého jsou cookies ukládány a zjistili, že obsahuje i záznamy ze serverů, které nikdy vědomě nenavštívili. Šlo právě o cookies získané při neověřitelných transakcích. Tito uživatelé však pojali podezření, že je tam příslušný server uložil bez jejich vědomí a tedy tak, že se do jejich počítače nějakým způsobem „naboural“. Další z dezinterpretací souvisí pravděpodobně s tím, že cookies s dobou platnosti se ukládají na disk. Představa, že někdo může na jejich počítač automaticky a bez jejich vědomí uložit nějaká data, vedla k obavám ze šíření virů tímto způsobem. Týž fakt vedl také k obavě ze zaplnění disku příliš mnoha cookies. Také v českém tisku byl namátkou nepříliš dávno (a to v listu, který bývá považován za poměrně seriozní) uveřejněn článek[26], kde se mimo jiné píše: „(…) různé programy označované jako cookies, které bez vědomí majitele zasílají informace o jeho počítači nebo o jeho činnosti na internetu (…)“. V tomto vyznění je mechanismus pro udržování stavových informací stavěn do světla, jako by byl určen pouze ke špehování a neměl větší význam než viry. Není se co divit, že čtenář-laik po přečtení této formulace vůči této technologii ztratí veškerou důvěru. Všechna tato shora uvedená tvrzení jsou samozřejmě nesmyslná, ale pouze ukazují, jak může neodborná, nepřesná nebo nesprávně interpretovaná informace získat zcela jiný význam a jaké informační šumy mohou vznikat mezi laickou veřejností, pokud se jedná o technologii, kterou není snadné v novinářské zkratce vysvětlit. 80 Uživatelé tohoto prohlížeče ale jistě nepatří mezi ty, kteří by neuměli změnit jeho výchozí nastavení. Strana 42 Kapitola 4: Cookies 4.6 Test podpory v prohlížečích Komplikace s přijímáním standardů pro cookies a některé nejasnosti v jednotlivých specifikacích mne vedly k myšlence prověřit jejich fungování v různých prohlížečích. K dispozici jsem měl jednak nové (stav k 15.8.2004) verze tří základních na platformě Windows. Dále jsem zvolil další dva zástupce platformy Linux. Díky serverům, které uchovávají starší verze prohlížečů ([12] a [28]) jsem mohl otestovat fungování cookies i v některých z nich. Bohužel Internet Explorer je jak známo od verze 4 velmi silně integrován do operačního systému a proto jsem zástupce verzí 4 a 5 otestovat nemohl81. 4.6.1 Testované prohlížeče Do první skupiny tak patřil Microsoft Internet Explorer 6 se všemi k danému datu dostupnými82 opravami včetně ServicePacku 2 pro Windows XP. Na stejném operačním systému byly dalšími účastníky testu Mozilla verze 1.8a2 a Opera ve verzi 7.54. Je zajímavé, že se i v těchto moderních prohlížečích objevily v testované oblasti některé zásadní chyby a nedostatky. Linux zastupoval jednak Konqueror – součást prostředí KDE 3.2 a dále textový Lynx verze 2.85r1. Obojí provozované na Mandrake Linuxu 10. Ze starších verzí prohlížečů jsem zvolil pouze různé verze někdejších dvou velkých rivalů – Internet Exploreru a Navigatoru. U Navigatoru šlo postupně o verze 2.0283 (1995), 3.04 (1996) a 4.03 (1997). Internet Explorer zastupovaly verze 2.0 Build 1380 (1996) a 3.0.1152 (rovněž 1996)84. Vše bylo opět provozováno na Windows XP Professional. Při výběru konkrétních verzí jsem se řídil zejména jejich momentální dostupností a funkčností v daných podmínkách. 4.6.2 Základní možnosti uživatelského nastavení práce s cookies Nejstarší z testovaných verzí Internet Exploreru ani Navigatoru neumožňovaly uživateli jakékoli nastavení cookies. Jejich přijímání prostě bylo aktivováno vždy. V té době byly pro tyto verze neoficiálně doporučovány nestandardní techniky jejich deaktivace spočívající v přepsání souboru, do kterého se ukládaly, případně jeho nastavení pouze pro čtení. Poprvé bylo (z testovaných verzí) možno u Navigatoru zvolit, že se má před přijetím cookie zobrazit dotaz (viz obrázky 12 a 14). Obdobný mechanismus obsahuje Internet Explorer ve verzi 3 (obrázek 11). Úplná deaktivace cookies nebo zákaz cookies třetích stran stále nebyly možné. Situace, kdy servery odesílaly cookies znovu a znovu (a tedy znovu a znovu byl uživatel dotazován) i když byly odmítnuty ale toto řešení degradovala. Vyšší verze Netscape Navigatoru tak již obsahovala možnost cookies zcela deaktivovat, nebo povolit pouze ty vracené na výchozí (originating) server. Právě to je možnost, kterou lze (ač to z názvu nevyplývá zcela jednoznačně) deaktivovat příjem cookies třetích stran (obrázek 13). 81 Ve skutečnosti jsem na výše uvedených serverech nalezl takové, které šlo spustit, ovšem buď nefungovaly vůbec (verze 4), nebo bohužel nefungoval pouze mechanismus zpracování cookies (verze 5). 82 Na serverech WindowsUpdate 83 Původně také 1.1N a 1.22. Jejich chování co se týče zpracování cookies v testovaných případech však bylo zcela totožné jako u 2.02. 84 Původně také 1.5, ovšem ta cookies nepodporovala vůbec a byla tak předem z testu vyřazena. Strana 43 Kapitola 4: Cookies Obrázek 12: Nastavení varování v NN 3.04 Obrázek 11: Nastavení varování v MSIE 3.0 Obrázek 13: Nastavení cookies v NN 4.03 Obrázek 14: Varování v NN 3.04 Nové prohlížeče již (kromě Internet Exploreru) mají v uživatelských rozhraních zabudované sofistikované cookie-managery, kde uživatel může vidět a případně smazat všechny přijaté cookies (ten v Lynxu je na obrázku 16). V nastavení lze potom nalézt různé možnosti kombinací běžných a cookies třetích stran, omezení délek jejich platnosti a podobně (viz např. obrázek 15 znázorňující možnosti nastavení Mozilly buď klasicky nebo podle politik P3P nebo obrázek 17 ukazující možnosti Opery). Obrázek 15: Nastavení cookies v Mozille 1.8 Obrázek 16: Správa přijatých cookies v Lynxu Strana 44 Kapitola 4: Cookies 4.6.3 Podpora cookies dle specifikace Netscape Jako první byly otestovány cookies dle původní specifikace Netscape. Kromě samotného základního faktu, zda s nimi prohlížeče umějí zacházet (původně do testu zařazený Internet Explorer 1.5 neuměl a proto byl vyřazen) jsem se zaměřil zejména na fungování některých sporných či ve specifikaci nedefinovaných otázek. Zejména šlo o ty, které řešily následné RFC dokumenty jako například práce s porty a parametry Path či Domain. Parametr Path První otázkou bylo, jaké je skutečné výchozí nastavení tohoto parametru, pokud není explicitně specifikován. Test byl proveden uložením cookie, která jej neobsahovala a jejím následným přečtením skriptem z jiného dokumentu ve stejném adresáři. Všechny verze Navigatoru (i z něho vycházející Mozilla) nastavovaly jeho hodnotu na adresu končící adresářem (tedy tak, jak to bylo později definováno v RFC). Projevilo se to tak, že cookie bylo možné přečíst (tj. prohlížeč ji zasílal) i v jiném skriptu z téhož adresáře. Stejně se chovali i Lynx (viz dále), Opera, Konqueror a Internet Explorer od verze 3. Jeho starší verze nastavovala výchozí hodnotu tohoto parametru na celou kompletní adresu dokumentu. Stejné chování se mi podařilo objevit i u starší verze Lynxu (2.8.4pre5). Z uvedeného se dá dovodit, že vývojáři, kteří později do svých prohlížečů implementovali cookies dle specifikace Netscape pochopili tam uvedenou formulaci („same path as the document“) jinak, než jak byla Louem Montullim myšlena. Další otázka týkající se cesty byla ta, zda je možné přijímat cookies s parametrem Path nastaveným na adresář, který neodpovídá adresáři ve kterém se nachází požadovaný dokument. Tedy například pokud server při požadavku na dokument /docs/text.html vrátí cookie s path=/images. Specifikace Netscape to totiž dovolovala, či lépe řečeno nezakazovala. Drtivá většina prohlížečů takovéto cookies přijala a následně i (do příslušných adresářů) odesílala. Pouze Lynx v takovém případě zobrazil varování s dotazem, zda cookie přijmout (a to i když byla zvolena možnost přijímat všechny cookies). Ještě bohatší možnosti má v tomto případě Opera. Ta dovoluje předem zvolit, zda uživatel hodlá takovéto cookies přijímat a jestli si předtím přeje být varován. Možnosti nastavení Opery ukazuje obrázek 17. Poslední otázka ohledně cesty v cookies se váže k jednomu konkrétnímu příkladu ve specifikaci Obrázek 17: Nastavení cookies v Opeře 7.54 Netscape. Je tam totiž psáno, že cookies s parametrem Path=/foo mají být zasílány spolu s požadavky na dokumenty s adresou začínající /foo/bar, tak ale také /foobar. Zajímalo mne tedy chování prohlížečů, pokud hodnota parametru nekončila lomítkem. Podle popsaného pravidla se chovaly všechny testované prohlížeče kromě tří. Konqueror, Mozilla a Lynx cookies tímto způsobem neodesílaly. Tabulka 2: Výsledky testů Netscape cookies s parametrem Path Prohlížeč Výchozí Path Neplatné Path Nekompl. adresář Navigator 2.02 k poslednímu / přijme bez varování odesílá Navigator 3.04 k poslednímu / přijme bez varování odesílá Strana 45 Kapitola 4: Cookies Prohlížeč Výchozí Path Neplatné Path Nekompl. adresář Navigator 4.03 k poslednímu / přijme bez varování odesílá Mozilla 1.8a2 k poslednímu / přijme bez varování neodesílá MSIE 2.0 celá adresa přijme bez varování odesílá MSIE 3.0 k poslednímu / přijme bez varování odesílá MSIE 6.0 k poslednímu / přijme bez varování odesílá Opera 7.54 k poslednímu / lze nastavit příjem i varování odesílá Lynx 2.8.4 k poslednímu / varuje neodesílá přijme bez varování neodesílá (starší verze celá adresa) Konqueror 3.2 k poslednímu / Parametr Domain Zde mě zajímalo především reakce prohlížečů na cookies, která mají nastavenu doménu na jinou hodnotu, než se které přicházejí. Míněna je tím zcela jiná doména a ne pouze doména vyšší úrovně. Překvapivě se objevily dva způsoby jejich zpracování. Kromě běžného odmítnutí (čili neuložení), Internet Explorer 3 a Konqueror takovéto cookies přijali, ale tak, jako by žádný parametr Domain neměly. Nastavili jim tedy doménu výchozí. Opera umožňuje pro takové případy nastavit zobrazení varování (obrázek 17), na rozdíl od varování v případě neplatné cesty je toto pouze informativní a není možné takovou cookie přijmout. Druhou otázkou bylo, jaké hodnoty je možno do parametru Domain nastavit v rámci platné domény. Tedy jednalo se o implementaci onoho „tečkového“ algoritmu ze specifikace Netscape. Navigatory všech verzí akceptovaly hodnoty minimálně s dvěma tečkami (a to jak pro „speciální“ com, tak i pro cz). Pro Mozillu, Operu a Internet Explorer 6 stačila jedna tečka (samozřejmě ale neakceptovaly domény typu .com). Konqueror akceptoval vlastně jakoukoli hodnotu, pokud však nebyla vyhovující, pracoval s ní v duchu výsledku předchozího testu – tj. dosadil implicitní doménu. Velmi zajímavá zjištění jsem učinil u Internet Exploreru. Ten totiž ve své verzi 2 přijímal také doménu nastavenou na .com a co víc, takové cookies potom také odesílal. Verze 3 je sice ještě také přijímala, ale zacházela s nimi stejně jako dnes Konqueror tj. dosadila implicitní doménu. U obou těchto verzí jsem také přišel na další zajímavost, pokud byla doména nastavena například na example.com, odesílaly se příslušné cookies také do domény anotherexample.com – čili fungovalo to obdobně jako u porovnávání cesty. Tabulka 3: Výsledky testů Netscape cookies s parametrem Domain Prohlížeč Cizí doména Přípustná doména Navigator 2.02 nepřijme dvě tečky Navigator 3.04 nepřijme dvě tečky Navigator 4.03 nepřijme dvě tečky Mozilla 1.8a2 nepřijme jedna tečka ale platná doména MSIE 2.0 nepřijme jedna tečka i .com a odesílá! MSIE 3.0 přijme jako výchozí jedna tečka ale jako výchozí MSIE 6.0 nepřijme jedna tečka ale platná doména Strana 46 Kapitola 4: Cookies Prohlížeč Cizí doména Přípustná doména Opera 7.54 nepřijme a umí varovat jedna tečka ale platná doména Lynx 2.8.4 nepřijme jedna tečka ale platná doména Konqueror 3.2 přijme jako výchozí jedna tečka ale platná doména Různé porty Debata ohledně portů a konečné začlenění nového parametru do RFC 2965 mě inspirovaly k provedení testu, který by ukázal, jak je s porty zacházeno v implementacích starší verze cookies v jednotlivých prohlížečích. Testoval jsem nejen komunikaci cookies napříč dvěma různými porty, ale také to, zda prohlížeče rozlišují situace, kdy se užívá výchozí port a kdy se uvede port 80 explicitně v URI. Logicky je to sice stejné, nicméně v zápisu to vypadá jinak a tak by to některým prohlížečům mohlo dělat potíže. Všechny Navigatory odesílaly cookies pouze na ten port, ze kterého je přijaly. Navíc přitom rozlišovaly právě mezi „žádným“ portem a explicitně uvedeným portem 80. Internet Explorer 2 odesílá rovněž pouze na stejný port, ale uvedené dvě alternativy nerozlišuje. Stejně se chová i Konqueror. Internet Explorer od verze 3, Mozilla, Lynx i Opera odesílají na všechny porty. Tabulka 4: Výsledky testů Netscape cookies a portů Prohlížeč Odesílá na porty Rozlišuje „žádný“ a 80 Navigator 2.02 původní ano Navigator 3.04 původní ano Navigator 4.03 původní ano Mozilla 1.8a2 všechny - MSIE 2.0 původní ne MSIE 3.0 všechny - MSIE 6.0 všechny - Opera 7.54 všechny - Lynx 2.8.4 všechny - Konqueror 3.2 původní ne 4.6.4 Podpora cookies dle RFC 2109 Druhá sada testů byla již početně menší a týkala se cookies tak, jak je popisoval dokument RFC 2109. Zde mi šlo hlavně o samotnou funkčnost a také o implementaci novinek. Kromě nových parametrů to byla také syntaxe hlaviček umožňující hodnoty uzavírat do uvozovek. Vzhledem k předem požadované kompatibilitě s předchozí specifikací nenastaly u drtivé většiny prohlížečů potíže. Jediný zásadní problém se vyskytl u Internet Exploreru 2 a to ten, který byl zmiňován v subkapitole 4.4.1. Jako název cookie byl interpretován poslední neznámý parametr a proto se místo cookies zprvu objevovaly hodnoty Version=1. Pro další (mimochodem výsledkově velmi zajímavé) pokusy s touto verzí jsem proto zapsal skutečné názvy cookies až na konec hlaviček. Strana 47 Kapitola 4: Cookies Nahrazení parametru Expires parametrem Max-Age v této verzi reflektovaly pouze Mozilla, Lynx a Konqueror. Všechny tři prohlížeče akceptovaly oba parametry. Druhý z nových parametrů – Comment zobrazuje pouze Lynx (ovšem až po přijetí cookie v cookie manageru). Jistým způsobem to také dělá Opera, neboť ta v případném varování zobrazuje kompletní hodnotu celé hlavičky. Verzi cookies a další informativní proměnné v hlavičce Cookie ($Path atp.) odesílaly pouze Lynx a Konqueror. Z toho tedy plyne, že ostatní zřejmě nerozlišují Netscape cookies a RFC 2109 cookies a jejich kompatibilita je spíše dána zpětnou kompatibilitou celého standardu. Jedinou výjimkou tu je parametr Max-Age v Mozille. Velmi zajímavým bylo testování uvozovek. Ty jsem testoval na hodnotách různých parametrů cookies a nejzajímavější výsledky přinesly cesta a doména. Pokud se totiž v některém z nich objevily uvozovky, neuměly si s nimi poradit (tj. odstranit) následující prohlížeče: žádný z Navigatorů, Internet Explorer 3 ani 6 a kupodivu ani Mozilla. Takové cookies tedy potom nebyly na servery odesílány, neboť jejich cesta či doména (včetně uvozovek) neodpovídala. Velmi šokující bylo zjištění, že Internet Explorer 2 parametry v uvozovkách zvládá a zachází s nimi korektně. Tabulka 5: Výsledky testů cookies dle RFC 2109 Prohlížeč Zákl. kompatibilita Max-Age $vars v Cookie Comment Uvozovky Navigator 2.02 ano ne ne ne ne Navigator 3.04 ano ne ne ne ne Navigator 4.03 ano ne ne ne ne Mozilla 1.8a2 ano ano ne ne ne MSIE 2.0 ne ne ne ne ano MSIE 3.0 ano ne ne ne ne MSIE 6.0 ano ne ne ne ne Opera 7.54 ano ne ne celá hlavička ano Lynx 2.8.4 ano ano ano ano, až poté ano Konqueror 3.2 ano ano ano ne ano 4.6.5 Podpora cookies dle RFC 2965 Jak již bylo řečeno v kapitole o cookies, z mnoha různých důvodů v současnosti platný standard tedy RFC 2965 nebyl všeobecně přijat. Vzhledem k datu jeho vydání připadala případná podpora teoreticky v úvahu pouze u nových prohlížečů. Žádný ze dvou hlavních producentů (Microsoft ani Netscape) jej ale do svých produktů nezabudoval. Bohužel ani Mozilla, která vychází ze starších verzí Navigatoru, jej v sobě (zřejmě kvůli v této situaci mizivé poptávce) nemá implementován. Z prohlížečů zahrnutých do testu jej tedy podporují pouze Opera, Lynx a Konqueror. V testech jsem se zaměřil zejména na nové parametry a také na některé další detaily ze specifikace. Opera sice nerozlišuje Netscape a RFC 2109 cookies, ale ty dle RFC 2965 pozná a to včetně u nich uvedeného parametru Max-Age. Správně v tomto případě také posílá v hlavičce Cookie verzi a další proměnné. Jako jediná také rozumí rozšíření domény pro intranety pomocí přípony .local a korektně pracuje s parametrem Discard. Má také rozhraní, které má sloužit k zobrazení obsahů parametrů Comment a CommentURL, ovšem nezachází s nimi bohužel korektně a zobrazuje místo nich nesrozumitelné znaky (čtverečky). Další její slabina spočívá v parametru Port. Pokud je uveden Strana 48 Kapitola 4: Cookies pouze jako název, potom v rozporu se specifikací dále odesílá cookies na všechny porty. Správně se chová, jestliže má jako hodnotu uveden jeden konkrétní port. Pak odesílá skutečně pouze na tento jeden. Jakmile se ale objeví portů více (oddělených čárkami), název cookie je nahrazen číslem posledního portu v seznamu a jako hodnota se uloží prázdný řetězec. Celá cookie tak je znehodnocena a není správně přijata. Lynx má implementováno RFC 2965 téměř vzorově. Jediný jeho nedostatek je, že nepodporuje virtuální doménu nejvyšší úrovně .local používanou pro práci v intranetech. Jisté výhrady snad lze mít k tomu, že jak Comment tak i CommentURL je možno zobrazit až po přijetí cookie. Je to však dáno textovým charakterem tohoto prohlížeče, kdy je pro většinu interaktivních dialogů užito jediného řádku. Konqueror neumožňuje tyto informace zobrazit vůbec a také on nemá podporu pro doménu .local. Dále uchovává cookies se stanovenou dobou platnosti, přestože mají nastaven parametr Discard. Rovněž zde je implementace portu nepřesná. Pokud je uveden pouze název odesílá se jen na výchozí port, jinak na všechny. Toto je také jediný prohlížeč, který přijme cookie, která má port nastaven zcela jiný než ten, ze kterého přišla. Ostatní funkce jsou nicméně implementovány správně. Tabulka 6: Výsledky testů cookies dle RFC2965 Prohlížeč Zákl. kompatibilita Port CommentURL .local Discard Mozilla 1.8a2 ne - - - - MSIE 6.0 ne - - - - Opera 7.54 ano s problémy celá hl.+nefunkční rozhraní ano ano Lynx 2.8.4 ano správně ano, až poté ne ano Konqueror 3.2 ano s problémy ne ne ne 4.6.6 Shrnutí výsledků Z výše popsaných výsledků provedených testů vyplývá bohužel relativně chabá implementace RFC standardů cookies v současných majoritních prohlížečích. V několika málo ostatních je jejich podpora na velmi vysoké úrovni (např. u Lynxu téměř dokonalá). Pro širší použití na straně serveru z toho však (při zachování požadavku na vysokou míru kompatibility) plyne nutnost spolehnout se na původní formát cookies podle Netscape. Je však třeba mít přitom na paměti jeho jistou zranitelnost zejména podstrčením dat z jiné domény (tzv. cookie-spoofing viz stranu 34). Strana 49 Kapitola 5: Udržování stavových informací na serveru 5 Udržování stavových informací na serveru Výše popsané metody přenosu stavových informací85, ať již čistě prostředky protokolu HTTP a nebo pomocí cookies, spoléhaly vesměs na stejný princip. Server poslal informace klientu, ten je určitým způsobem po dobu přerušení spojení udržoval a při dalším požadavku je poslal serveru zpět. Existuje také jiný přístup, kdy některé stavové informace zůstanou uloženy na serveru. Také v tomto případě je nicméně nutné použít některou z předcházejících metod k přenosu identifikátoru. 5.1 Ukládání stavových informací V některých případech není vhodné (či možné) přenášet veškeré stavové informace od klienta na server s každým požadavkem. Může to být z důvodů kapacitních či jiných. V takovém případě je možné je ukládat v datových souborech na serveru. Podmínkou nicméně je, aby množina dat vážící se ke danému uživateli, byla nějak označena a odlišena od množin dat ostatních uživatelů. Server však pouze z čistého HTTP požadavku nepozná, která z těchto množin „patří“ danému uživateli, neboť kvůli bezstavovosti protokolu neodliší požadavky od různých uživatelů. Je proto nezbytné některou z výše popsaných metod spolu s požadavkem odeslat také identifikační stavovou informaci. Nejde tedy o další novou metodu přenosu stavových informací, ale o změnu místa, kde jsou vlastní stavové informace udržovány. Přenášen je pouze identifikátor a případně některé transakční informace, které se váží k prováděným transakcím. Algoritmy zajišťující základní funkce (tj. zejména přidělení identifikátoru, zajištění jeho přenosu, uložení požadovaných informací pod tímto identifikátorem na serveru, přečtení identifikátoru z požadavku, znovunačtení jemu odpovídajících informací a mazání neplatných informací) mohou být implementovány různě. Nejčastěji jsou na serveru informace ukládány do zvláštních souborů případně do databází (nejčastěji relačních). Mnohá prostředí pro vývoj webových aplikací dnes již často mají takovéto funkce přímo připravené a dostupné webovým programátorům (viz např. [21]). Nezřídka jsou tyto funkce uzpůsobeny k několika možným způsobům přenosu identifikátorů. Pokud je například při spojení s klientem zjištěno, že ten nepodporuje cookies, jsou identifikátory automaticky dogenerovány do URI všech odkazů. Je tak vytvořena jakási vložená vrstva mezi protokolem HTTP a samotnou aplikací, která umožňuje programátorovi i v bezstavovém prostředí WWW, pracovat obdobně, jako by se jednalo o prostředí stavové86. 5.2 Ohrožení identifikátorů relací Při používání těchto vestavěných funkcí je ovšem třeba dávat pozor na bezpečnost. Ač jinak jsou vcelku propracované, nejspíše z důvodu maximální kompatibility nemívají zabudována téměř žádná bezpečnostní opatření. Pokud se někomu cizímu podaří získat identifikátor relace, může pak v rámci aplikace přistupovat k informacím náležejícím k tomuto identifikátoru. V následujících několika krátkých subkapitolách se pokusíme upozornit na některé základní možné způsoby úniku identifikátoru relace a možné způsoby ochrany proti nim. Popsané případy se však nevztahují pouze na bezpečnost přenosu identifikátorů při udržování stavových informací na straně serveru. Mají obecnou platnost pro přenos veškerých informací dotčenými metodami. 85 S výjimkou v praxi téměř nepoužitelných identifikátorů v podobě IP adresy, HTTP autentizace a hlavičky From. 86 Identifikátory těchto vestavěných funkcí lze snadno zjistit podle názvů (pokud jim je správce serveru nezmění). V prostředí PHP je to například PHPSESSID, pro ASP názvy začínající ASPSESSID a podobně. Strana 50 Kapitola 5: Udržování stavových informací na serveru 5.2.1 Odhadnutí Pokud je identifikátor relace příliš jednoduchý, například jej představuje pouze pořadové číslo, velice snadno to může lákat případného útočníka ke snaze o odeslání jiného identifikátoru. Jako identifikátory by tedy měly být v těchto případech voleny složitější kombinace znaků. Ideální jsou například výstupy hašovacích funkcí, které mají konstantní délku. Je nutno podotknout, že takováto přílišná jednoduchost identifikátorů není nedostatek, kterým by mechanismy vestavěné v prostředích trpěly. Blíže k požadavkům na složitost identifikátoru viz [32]. Pokud jsou tyto požadavky splněny, mělo by být velmi nepravděpodobné, že by se útočníkovi podařilo cizí identifikátor odhadnout. 5.2.2 Odposlechnutí z komunikace Případné odhadnutí hrozí zejména těm identifikátorům, které jsou od počátku špatně navrženy. I ty ostatní jsou ale během přenosu v mnohem větším ohrožení. Pokud se nejedná o HTTP spojení přes šifrovaný kanál, jsou veškerá data posílána v odkryté a tedy pro kohokoliv „na cestě“ čitelné podobě. Takto je možné získat identifikátor relace přenášený nejen v různých formách zakódovaný do URI (který se navíc bude na mnoha místech ukládat do logů). Úplně stejně se lze dostat k obsahu dat z formuláře odeslaného metodou POST, či k hlavičce obsahující cookie. Zcela zamezit je tomu možné pouze použitím spolehlivého šifrovaného spojení. 5.2.3 Hlavička Referer Další potenciální hrozbou je ona již také několikráte zmiňovaná hlavička Referer. V případě, že je k přenosu identifikátoru použito některé z metod využívajících jeho zakódování do URI, hrozí právě zde asi největší nebezpečí jeho prozrazení. Tato hlavička je totiž mimo jiné odesílána spolu s požadavky na všechny vložené objekty. Pokud se útočníkovi podaří vložit do takové stránky odkaz například na obrázek, který je umístěn na serveru k němuž má přístup, v hlavičce referer získá i požadovaný identifikátor. V aplikacích, kde je možné, že do zdroje stránky bude vložen nějaký cizí obsah (jako jsou kupříkladu elektronická pošta či diskusní fóra), je proto nutné buď zamezit vkládání HTML tagů, případně vložené odkazy přepsat, aby nevedly přímo k cíli. To se řeší tak, že ukazují na nějaký skript, v jehož URI není identifikátor relace a ten teprve provede (většinou automaticky HTTP stavovým kódem) přesměrování na původní cíl. 5.2.4 Některé možnosti ochrany před zneužitím identifikátoru Pokud z nějakého důvodu nelze využít šifrovaného spojení a hrozí tedy nebezpečí prozrazení identifikátoru, je možné použít některé z metod ochrany před jeho zneužitím. Žádná z nich není stoprocentně úspěšná, většina jich však má své opodstatnění a může ztížit jisté typy útoků. Někdy bývá používána kontrola hlavičky Referer. Tu ale jednak některé prohlížeče neposílají, a navíc je ji poměrně snadné podvrhnout87. Gunter Ollmann[32] jako jisté vylepšení navrhuje generování dočasných identifikátorů také pro jednotlivé stránky a kontrolování opět hlavičkou Referer, zda uživatel prochází webem v dovoleném pořadí. Poměrně často užívaným způsobem je vypršení platnosti relace po uplynutí určitého časového intervalu nečinnosti. Na implementaci toto opatření nebývá složité a zabraňuje poměrně účinně možnému pozdějšímu útoku například po dodatečném přečtení identifikátoru z logu. Tak je tomu ovšem pouze za předpokladu, že je implementován přímo v aplikaci na serveru a ne pouze jako 87 Tato metoda zřejmě spoléhá na to, že to je řádově složitější, než pouze zkopírovat URI do prohlížeče. Strana 51 Kapitola 5: Udržování stavových informací na serveru omezení platnosti odesílaných Cookies. Pokud je identifikátor obsažený v cookie platný i po jejím vypršení, nemá toto opatření požadovaný efekt, neboť útočník má tento platný identifikátor stále k dispozici. Jako velmi účinná se ukazuje být kontrola IP adresy, ze které se klient připojuje. Tu je velmi obtížné podvrhnout a útočník tak získaný identifikátor, pokud jej neodešle ze stejné IP adresy jako oprávněný uživatel, nemůže použít. Mohlo by se tak stát, pokud by oba například přistupovali k webu přes stejný proxy server. To již ovšem značně zužuje množinu možných úspěšných útočníků. Je navíc možné použít hlavičku X-Forwarded-For, kterou posílají některé proxy servery. Zdálo by sem, že je tak možné vyřešit situace, kdy jsou jednotlivé požadavky jednoho klienta vyřizovány postupně několika proxy servery. Bohužel situace není tak snadná, neboť nelze jednoduše tuto hlavičku, pokud je přítomna, porovnávat namísto skutečné IP adresy. Hlavičku lze totiž velmi snadno podvrhnout a celý jinak poměrně účinný systém tak snadno ošidit. 5.3 Shrnutí Zmínili jsme také druhý základní princip udržování stavových informací v prostředí WWW. Tím je jejich uchovávání na straně serveru. Kvůli bezstavovosti protokolu HTTP je ovšem i v tomto případě nutný přenos identifikačních informací spolu s požadavkem a tedy platí pro něj většina toho, co bylo řečeno v kapitolách 3 a 4. Kvůli výlučnosti identifikátoru jsme také krátce pohovořili o základních východiscích, která je nutno mít při jeho ochraně na paměti. Samozřejmě jsme zde nevyjmenovali ani zdaleka veškeré možné způsoby útoků88. K některým dalším souvislostem viz např. [49] a [51]. 88 Například jsme vynechali celou bohužel širokou oblast využití bezpečnostních chyb a nedostatků v prohlížečích nejčastěji ve spojení se skriptovacími jazyky. Strana 52 Kapitola 6: A.S.I.A.T. 6 A.S.I.A.T. Jako hlavní praktickou součást této práce jsem se rozhodl vytvořit aplikaci, která by určitým způsobem automaticky rozpoznávala metody přenosu stavových informací v prostředí protokolu HTTP použité na konkrétních URI. Tuto aplikaci jsem pojmenoval A.S.I.A.T. To je zkratka anglických slov Automated State Information Analyzing Tool – tedy česky automatizovaný nástroj pro analýzu stavových informací. 6.1 Uživatelské rozhraní Aplikace A.S.I.A.T. Má velmi jednoduché uživatelské rozhraní (viz obrázek 18). V horní části okna je vstupní pole pro adresu, která má být otestována a tlačítko pro její potvrzení (funguje také Enter ve vstupním poli). Výstupy se vypisují do centrální části okna a to v textové podobě. Ve zcela spodní části okna je potom několik zaškrtávacích políček, kterými je možno ovlivnit výstup aplikace. Zatrhnutí prvního z nich způsobí zobrazení požadavku tak, jak je aplikací odesílán89. Druhé naopak vede k zobrazení hlaviček obdržených s přijatým dokumentem. Následující tři políčka zapínají zpracování samotné analýzy stavových informací (viz dále). Pokud je zvoleno zpracování odkazů, jsou s cílovým serverem uskutečněna dvě samostatná spojení90. Posledním políčkem lze zvolit zobrazení těla obdrženého dokumentu (po případném dokódování chunked encoding). Obrázek 18: A.S.I.A.T.: Uživatelské rozhraní aplikace 6.2 HTTP klient Již od počátku bylo zřejmé, že takováto aplikace bude muset být z podstatné části HTTP klientem. Celý návrh tak vychází z poměrně důsledné implementace základních součástí protokolu HTTP 1.1 (dle RFC 2616). Soustředil jsem se na podstatné základy a v této implementaci se tak vyhnul náročnějším a pro své potřeby nadbytečným vlastnostem. Není tak implementováno například perzistentní spojení (nicméně tato skutečnost je v požadavcích korektně označena hlavičkou Connection: Close), podpora pro přenos neúplných dokumentů (byte range), proxy, či různá kódování dokumentů91 (např. komprimace). Všechny tyto skutečnosti jsou samozřejmě signalizovány příslušnými HTTP hlavičkami v požadavku (resp. jejich absencí). Oproti tomu právě práce s HTTP hlavičkami je velmi důsledná včetně například zpracování kombinovaných hlaviček (spojení více hlaviček stejného názvu do jediné) nebo lomených hlaviček (pokračujících na dalším řádku). Implementovány jsou rovněž korektní postupy pro určení délky dokumentu, včetně zpracování základního přenosového kódování v HTTP 1.1 – totiž chunked encoding. 89 Z implementačních důvodů nemusí být pořadí hlaviček stejné. 90 Kromě případů, kdy dokument neobsahuje žádný odkaz a druhé spojení by tudíž bylo zbytečné. 91 S čestnou výjimkou základního přenosového kódování v HTTP 1.1 totiž chunked encoding. Strana 53 Kapitola 6: A.S.I.A.T. Jako poslední poznámku k tomuto tématu je nutno uvést, že ač jinak jsem se snažil postupy zpracování URI implementovat co možná nejpřesněji podle standardů, v zadaných adresách nejsou v jednotlivých částech URI zakódovávány znaky se speciálním významem (například %, / či mezera). Je to z toho důvodu, že je předpokládáno využití aplikace spolu s klasickým prohlížečem, ze kterého jsou do ní adresy kopírovány. Prohlížeče již toto překódování provádějí a jeho znovuprovedení by bylo kontraproduktivní a vedlo by k jiným než očekávaným výsledkům. 6.3 Práce se stavovými informacemi Kromě čistého HTTP klienta (pro získávání odpovědí na požadavky), bylo pro samotnou analýzu případných takto získaných stavových informací nutno implementovat algoritmy, které by je byly schopny detekovat. Z výše zmiňovaných způsobů přenosu jde o zakódování informací do URI (všechny tři způsoby), skrytá formulářová pole a samozřejmě cookies. Ostatní způsoby jsou velmi zřídka používány a kromě toho je buď obtížné je detekovat (IP adresa jako identifikátor), nebo je jejich užití zřejmé již při použití běžného prohlížeče (HTTP autentizace). 6.3.1 Cookies Opravdu téměř kompletní podpora je implementována pro cookies. Je tomu tak zejména proto, že jde o mechanismus přímo určený k přenosu stavových informací a je tedy velmi snadné jeho použití přesně identifikovat92. Aplikace umí důsledně rozlišovat všechny tři druhy cookies (Netscape, RFC 2109, RFC 2906) a pracovat s jejich parametry. Mimo jiné zobrazuje dobu platnosti a to, zda by daná cookie (dle příslušné specifikace) měla, či neměla být přijata93. Bohužel protože servery, které by pro ukládání stavových informací používaly cookies dle RFC 2965 na internetu prakticky neexistují, musel jsem si skripty, které to dělají napsat sám. Protože tato aplikace nemá v žádném případě nahrazovat prohlížeč, cookies nejsou nijak uchovávány a odesílány s dalšími požadavky94. Výhodou takového řešení je tak jednoduchá možnost otestovat za stejných výchozích podmínek znovu stejné URI. Výstup při přijetí cookie s mnoha parametry dle RFC2616 ukazuje obrázek 19. Obrázek 19: A.S.I.A.T.: Přijetí cookie 92 Na rozdíl od ostatních tak není třeba užívat různých do jisté míry heuristických metod. 93 Zde jsem uplatnil svůj (většinou doslovný) výklad specifikací a chování se proto (i díky striktnímu odlišování jednotlivých typů cookies) může lišit od zacházení klasických prohlížečů. 94 I když architektura aplikace na to připravena je a nebylo by obtížné tuto vlastnosti doimplementovat. Strana 54 Kapitola 6: A.S.I.A.T. 6.3.2 Formuláře Samotná přítomnost nějakého formuláře v dokumentu zpravidla vede k jeho užití při přenosu stavových informací. Aplikace A.S.I.A.T. proto v tělech dokumentů vyhledává také právě formuláře. Ve formulářích může být obecně přenášeno téměř cokoli. Dále rozpoznávány jsou tedy pouze potenciální identifikační informace, pro které bývají využívána skrytá formulářová pole. Ta jsou proto také spolu s metodou, která by byla použita k odeslání formuláře, zobrazována na výstupu aplikace. 6.3.3 Odkazy a URI Poslední detekovanou metodou přenosu stavových informací je zakódování do URI. Zde jsou detekovány pouze případné identifikační informace, neboť o ostatních svědčí například jen přítomnost části query v URI. Detekce probíhá přibližným algoritmem, který nezaručuje jejich jisté odhalení, nicméně ve standardních případech je poměrně úspěšný. Jeho základním principem je opětovné načtení dokumentu z testované adresy a porovnání cílů sobě odpovídajících odkazů. Pokud jsou do odkazů vkládány pouze identifikátory, měly by se URI lišit právě v jedné své části (například adresář v path či proměnná v query). Právě takto je porovnáváno maximálně patnáct prvních odkazů a případné odlišnosti jsou reportovány jako možné stavové informace. Protože velice často bývá stejný identifikátor zakódován ve více odkazech, jsou ignorovány ty, které jsou stejné, jako v předchozím odkazu. Obrázky 20 a 21 ukazují příklady úspěšně identifikovaných stavových informací (jak v path, tak v query) v knihovních systémech Aleph v Národní knihovně a Centru informačních a knihovnických služeb Vysoké školy ekonomické v Praze. Obrázek 20: A.S.I.A.T.: Identifikátor v query odkazů na webu CIKS Obrázek 21: A.S.I.A.T.: Identifikátor v cestě odkazů v Národní knihovně Strana 55 Kapitola 6: A.S.I.A.T. 6.4 Návrh aplikace Vzhledem k jisté vrstevnatosti řešené problematiky (HTTP spojení, pod ním cookies v hlavičkách a tělo s formuláři a odkazy) a také variantám cookies, které jsou v některých detailech odlišné, jsem se rozhodl využít objektový návrh i konečnou realizaci celé aplikace. Nejdůležitější třídy reprezentují základní prvky HTTP spojení – tedy požadavek, odpověď a k nim náležející hlavičky. Ke každé odpovědi se váží zvláštní třídy, které spravují v ní obsažené cookies, formuláře a odkazy. Cookies obecně jsou dohromady reprezentovány abstraktní třídou BaseCookie, jejímiž potomky jsou potom tři konkrétní jejich implementace. Pro jejich různé chování ve stejných situacích je využit princip polymorfismu (konkrétně přetěžování metod). Model tříd základních prvků aplikace (bez grafického rozhraní) představuje obrázek 22. Zejména kvůli dobré podpoře objektového přístupu, přísné typové kontrole a v neposlední řadě nezávislosti na konkrétní platformě jsem pro implementaci zvolil programovací jazyk Java (konkrétně jeho verzi 1.4.1) Obrázek 22: A.S.I.A.T.: Model tříd aplikace Strana 56 Závěr Závěr V bakalářské práci jsem na pozadí historického vývoje služby World Wide Web a protokolu HTTP popsal hlavní metody udržování stavových informací v prostředí WWW. Jejich základem je udržování alespoň části informace na straně klienta a její přenos zpět k serveru prostřednictvím požadavku. K tomu jsou užívány jednak metody spoléhající pouze na protokol HTTP – zejména různé způsoby zakódování do URI a formulářová pole. Dále potom speciální rozšíření protokolu HTTP pro práci se stavovými informacemi – cookies. Ty existují ve třech standardizovaných podobách. Jak vyplynulo z provedených testů, pouze nejstarší z nich je podporována hlavními webovými prohlížeči a tudíž masově používána. Zmínil jsem také některé další způsoby udržování stavových informací. Naznačeny byly některé otázky, týkající se bezpečnosti přenosu informací. Výsledkem praktické části je funkční multiplatformní aplikace, která v sobě spojuje hlavní vlastnosti jednoduchého HTTP klienta s podporou základních funkcí a velice jednoduchého prohlížeče s plně implementovanými třemi verzemi cookies. Tato kombinace může být úspěšně využita pro snadnou detekci nejběžnějších způsobů přenosu stavových informací za pomoci protokolu HTTP použitých na konkrétních adresách. Strana 57 Rejstříky vložených tabulek a obrázků Rejstříky vložených tabulek a obrázků Rejstřík tabulek Vhodnost metod přenosu prostředky HTTP pro různé typy informací.............................................. 29 Výsledky testů Netscape cookies s parametrem Path......................................................................... 45 Výsledky testů Netscape cookies s parametrem Domain................................................................... 46 Výsledky testů Netscape cookies a portů........................................................................................... 47 Výsledky testů cookies dle RFC 2109................................................................................................48 Výsledky testů cookies dle RFC2965.................................................................................................49 Rejstřík obrázků Opakovaný požadavek v HTTP s vyznačením otevíraných spojení...................................................10 Použití proxy serveru..........................................................................................................................10 Použití cache v HTTP.........................................................................................................................10 Opakovaný požadavek v HTTP při perzistentním spojení................................................................. 15 Opakovaný požadavek v HTTP při perzistentním spojení a pipeliningu........................................... 15 Příklad vyjednávání o obsahu v HTTP...............................................................................................17 Přenos informací mezi vloženým objektem a serverem mimo rámec protokolu HTTP.................... 22 Fragment HTML kódu s formulářem se skrytým polem a jeho grafická reprezentace v prohlížeči.. 26 Obecné použití cookies.......................................................................................................................30 Neověřitelné transakce a užití cookies třetích stran k profilování......................................................35 Nastavení varování v MSIE 3.0..........................................................................................................44 Nastavení varování v NN 3.04........................................................................................................... 44 Nastavení cookies v NN 4.03............................................................................................................. 44 Varování v NN 3.04............................................................................................................................44 Nastavení cookies v Mozille 1.8........................................................................................................ 44 Správa přijatých cookies v Lynxu...................................................................................................... 44 Nastavení cookies v Opeře 7.54......................................................................................................... 45 A.S.I.A.T.: Uživatelské rozhraní aplikace..........................................................................................53 A.S.I.A.T.: Přijetí cookie.................................................................................................................... 54 A.S.I.A.T.: Identifikátor v query odkazů na webu CIKS................................................................... 55 A.S.I.A.T.: Identifikátor v cestě odkazů v Národní knihovně............................................................ 55 A.S.I.A.T.: Model tříd aplikace.......................................................................................................... 56 Strana 58 Seznam použité literatury Seznam použité literatury [1] The Apache Software Foundation: Apache HTTP server project [online] <http://httpd.apache.org/> [5.8.2004] [2] Apache Week: HTTP/1.1 [online] <http://www.apacheweek.com/features/http11> [5.8.2004] [3] AT: AT&T Privacy Bird. [online] <http://privacybird.com/> [5.8.2004] [4] BALCAR, Z.: Cookies. Strategie, 2002, s. 51. ISSN 1210-3756. [5] BERNERS-LEE, T.: The Original HTTP as defined in 1991. [online] <http://www.w3.org/Protocols/HTTP/AsImplemented.html> [5.8.2004] [6] BRAIN, M.: How Internet Cookies Work. [online] <http://www.howstuffworks.com/cookie.htm> [5.8.2004] [7] COBB, CH.: Cookies - Are You Ready?. [online] October 1996 <http://www.cheycobb.com/cookies.html> [5.8.2004] [8] COHEN, J <josh@netscape.com>: 305/306 response codes In W3C Public Mailing List Archives. [online] Fri, 6 Jun 1997 <http://lists.w3.org/Archives/Public/ietf-http-wgold/1997MayAug/0236.html> [5.8.2004] [9] CRANOR, L.: Help! IE6 Is Blocking My Cookies. [online] 2002 <http://www.oreillynet.com/pub/a/javascript/2002/10/04/p3p.html> [5.8.2004] [10] EICHELBERGER, L.: The Cookie Controversy. [online] April 1998 <http://www.cookiecentral.com/ccstory/> [5.8.2004] [11] EPIC: Cookies. [online] November 2002 <http://www.epic.org/privacy/cookies/default.html> [5.8.2004] [12] Evolt Browser Archive[online] <http://browsers.evolt.org/> [5.8.2004] [13] FEHLBERG, N.: P3P, Cookies and IE6.0: A Case Study. [online] March 2004 <http://www.sitepoint.com/article/p3p-cookies-ie6> [5.8.2004] [14] FUSCO, P.: The Way the Cookie Crumbles. [online] February 2000 <http://www.ispplanet.com/politics/cookie_crumbles.html> [5.8.2004] [15] KASTL, J.: Informační a komunikační systémy. 1. vyd. Praha, Vysoká škola ekonomická v Praze 1999. 123 s. ISBN 80-245-0001-9. [16] KOPTA, M.: Spam, cookies a šmírování podle Evropské unie. [online] leden 2002 <http://www.lupa.cz/clanek.php3?show=2002> [5.8.2004] Strana 59 Seznam použité literatury [17] KOSEK, J.: PHP - Tvorba interaktivních internetových aplikací. 1. vyd. Praha, Grada Publishing 1998. 492 s. ISBN 80-7169-373-1. [18] KRISTOL, D. M.: HTTP Cookies: Standards, Privacy, and Politic. ACM Transactions on Internet Technology (TOIT), Volume 1, 2001, Issue 2, p. 151-198. ISSN 1533-5399. [také online] <http://doi.acm.org/10.1145/502152.502153> [5.8.2004] [19] MACAVINTA, C.: DoubleClick, Abacus merge in $1.7 billion deal, News.com, 1999. [20] MACAVINTA, C.: Privacy advocates rally against DoubleClick-Abacus merger, News.com, 1999. [21] MACH, J.: Udělejte si sezení (Sesson management v PHP). Connect, roč. 6, 2001, č. 11, s. 32. [22] MATLIS, J.: P3P: Ochrana vašeho soukromí. Computerworld, roč. 13, 2002, č. 43, s. 20. ISSN 1210-9924. [23] MAYER-SCHÖNBERGER, V.: Cookies. [online] <http://www.cookiecentral.com/c_concept.htm> [5.8.2004] [24] MAZUR, J.: Maintaining State Within a Website (w/o Cookies or Server-side Scripting). [online] September 1999 <http://www.webdevelopersjournal.com/columns/stateful.html> [5.8.2004] [25] MIKLE, P.: XDHTML. 1. vyd. Brno, Zoner Press 2004. 208 s. ISBN 80-86815-01-3. [26] MOCEK, M.: Unie chrání mobily a počítače. Mladá fronta Dnes, roč. 14, 2003, č. 258. ISSN 1210-1168 [27] MONTULLI, L.: Lou Montulli: Short Bio. [online] <http://www.montulli.com/lou/> [15.8.2004] [28] Netscape Browser Archive[online] <http://sillydog.org/narchive/> [5.8.2004] [29] Netscape Communications Corp.: Persistent Client State HTTP Cookies. [online] <http://wp.netscape.com/newsref/std/cookie_spec.html> [5.8.2004] [30] Netscape Communications Corp.: OPS Submission request to W3C. 1997 [online] <http://www.w3.org/Submission/1997/6/> [15.8.2004] [31] NEWMARCH, J.: HTTP Session Management. [online] 2000 <http://jan.netcomp.monash.edu.au/ecommerce/session.html> [5.8.2004] [32] OLLMANN, G.: Paper: Web Based Session Management (Best Practices in Managing HTTP Based Client Sessions). [online] <http://www.technicalinfo.net/papers/WebBasedSessionManagement.html> [5.8.2004] Strana 60 Seznam použité literatury [33] PAVLÍČKOVÁ, J.: Úvod do programování v jazyce Java. 1. vyd. Praha, Vysoká škola ekonomická v Praze 2001. 110 s. ISBN 80-245-0238-0. [34] PETERKA, J.: Rodina protokolů TCP/IP, verze 2.0. [online] 1999 <http://www.earchiv.cz/l207/> [15.8.2004] [35] RAYMOND, E. S: The Jargon File (Version 4.4.7).. [online] <http://catb.org/~esr/jargon/html/index.html> [5.8.2004] [36] RFC 1738 Uniform Resource Locators (URL). December 1994. [37] RFC 1808 Relative Uniform Resource Locators. June 1995. [38] RFC 1945 Hypertext Transfer Protocol - HTTP/1.0. May 1996. [39] RFC 2068 Hypertext Transfer Protocol - HTTP/1.1. January 1997. [40] RFC 2109 HTTP State Management Mechanism. February 1997. [41] RFC 2295 Transparent Content Negotiation in HTTP. March 1998. [42] RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax. August 1998. [43] RFC 2616 Hypertext Transfer Protocol - HTTP/1.1. June 1999. [44] RFC 2617 HTTP Authentication: Basic and Digest Access Authentication. June 1999. [45] RFC 2964 HTTP Use of State Management Mechanism. October 2000. [46] RFC 2965 HTTP State Management Mechanism. October 2000. [47] STEIN, L.; STEWART, J: The World Wide Web Security FAQ (Version 3.1.2).. [online] February 2002 <http://www.w3.org/Security/Faq/index.html> [5.8.2004] [48] TILL, M.: Standart ochrany soukromí P3P. [online] <http://www.krypta.cz/articles.php?ID=70> [21.7.2004] [49] TILL, M.: Nástrahy webového programování. Connect, roč. 7, 2002, č. 2, s. 39. [50] TILL, M.: Ochrana osobních údajů na webu. Computerworld, roč. 13, 2002, č. 24, s. 23. ISSN 1210-9924. [51] TILL, M.: Web může být nebezpečnější, než se zdá. Computerworld, roč. 13, 2002, č. 24, s. 21. ISSN 1210-9924. [52] W3C: HTTP Performance Overview. [online] <http://www.w3.org/Protocols/HTTP/Performance/Overview.html> [15.8.2004] Strana 61 Seznam použité literatury [53] W3C: Hypertext Transfer Protocol - Next Generation Overview. [online] December 1999 <http://www.w3.org/Protocols/HTTP-NG/> [15.8.2004] [54] W3C: URIs, URLs, and URNs: Clarifications and Recomendations 1.0. [online] September 2001 <http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/> [5.8.2004] [55] W3C: Make Your Web Site P3P Compliant. [online] 2002 <http://www.w3.org/P3P/details.html> [5.8.2004] [56] W3C: P3P and Privacy on the Web FAQ. [online] 2002 <http://www.w3.org/P3P/p3pfaq.html> [5.8.2004] [57] W3C: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. [online] April 2002 <http://www.w3.org/TR/2002/REC-P3P-20020416/> [5.8.2004] [58] Webopedia.com: Cookie [online] <http://www.webopedia.com/TERM/c/cookie.html> [5.8.2004] [59] Webopedia.com: The Difference Between the Internet and the World Wide Web [online] <http://www.webopedia.com/DidYouKnow/Internet/2002/Web_vs_Internet.asp> [15.8.2004] [60] WHALEN, D.: The Unofficial Cookie FAQ (Version 2.6). [online] August 2002 <http://www.cookiecentral.com/faq/> [5.8.2004] Strana 62 Seznam použitých zkratek a termínů Seznam použitých zkratek a termínů CGI Common Gate Interface standard pro komunikaci HTTP serverů s externími programy HTML HyperText Markup Language značkovací jazyk pro zápis WWW dokumentů HTTP HyperText Transfer Protocol protokol pro přenos hypertextu – základní přenosový protokol WWW IETF The Internet Engineering Task Force mezinárodní komunita zabývající se technologickými standardy internetu path cesta zde součást URI označující umístění dokumentu na serveru query dotaz zde součást URI (za otazníkem) obsahující dodatečné informace RFC Request For Comments typ dokumentu vydávaný IETF; některé RFC specifikují standardy internetu session-id identifikátor relace termín užívaný pro jedinečnou identifikační informaci odlišující uživatele tag obecný název pro značku v jazyce HTML; každá značka má konkrétní význam URI Uniform Resource Identifier jednotný identifikátor zdroje – univerzální schema užívané pro adresování zdrojů URL Uniform Resource Locator jednotný ukazatel na zdroj – podmnožina URI identifikuje dokument místem uložení web zde ve smyslu obsah konkrétního HTTP serveru WWW World Wide Web celosvětová pavučina – služba internetu pro přenos hypertextu (HTML) přes HTTP Strana 63 [25][15][36][37][42][54][40][45][46][29][18][35][47][6][60][23][10][7][14][4][58][32][31][21] [49][51][57][56][55][9][22][13][48][50][38][39][43][2][12][28][34][24][3][17][5][52][41][8][53] [59][1][44][27][19][20][26][16][30][33] </div> </div> </div> </div> </div> </div> </div> </div> <div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true"> <div class="modal-dialog"> <div class="modal-content"> <form role="form" method="post" action="https://adoc.pub/report/metody-udrovani-stavovych-informaci-v-protokolu-http" style="border: none;"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button> <h4 class="modal-title">Report "Metody udržování stavových informací v protokolu HTTP"</h4> </div> <div class="modal-body"> <div class="form-group"> <label>Your name</label> <input type="text" name="name" required="required" class="form-control" /> </div> <div class="form-group"> <label>Email</label> <input type="email" name="email" required="required" class="form-control" /> </div> <div class="form-group"> <label>Reason</label> <select name="reason" required="required" class="form-control"> <option value="">-Select Reason-</option> <option value="pornographic" selected="selected">Pornographic</option> <option value="defamatory">Defamatory</option> <option value="illegal">Illegal/Unlawful</option> <option value="spam">Spam</option> <option value="others">Other Terms Of Service Violation</option> <option value="copyright">File a copyright complaint</option> </select> </div> <div class="form-group"> <label>Description</label> <textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea> </div> <div class="form-group"> <div style="display: inline-block;"> <div class="g-recaptcha" data-sitekey="6LcEnMcZAAAAAFHzKKgaE-Qh57XzUTzpfRElD4dP"></div> </div> </div> <script src='https://www.google.com/recaptcha/api.js'></script> </div> <div class="modal-footer"> <button type="button" class="btn btn-default" data-dismiss="modal">Close</button> <button type="submit" class="btn btn-primary">Send</button> </div> </form> </div> </div> </div> <script> $(document).ready(function () { var inner_height = $(window).innerHeight() - 250; $('#pdfviewer').css({"height": inner_height + "px"}); }); </script> <footer class="footer" style="margin-top: 60px;"> <div class="container-fluid"> Copyright © 2024 ADOC.PUB. All rights reserved. <div class="pull-right"> <a href="https://adoc.pub/about">About Us</a> | <a href="https://adoc.pub/privacy">Privacy Policy</a> | <a href="https://adoc.pub/term">Terms of Service</a> | <a href="https://adoc.pub/copyright">Copyright</a> | <a href="https://adoc.pub/contact">Contact Us</a> | <a href="https://adoc.pub/cookie_policy">Cookie Policy</a> </div> </div> </footer>  <div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel"> <div class="modal-dialog" role="document"> <div class="modal-content"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close">×</button> <h4 class="modal-title" id="add-note-label">Sign In</h4> </div> <div class="modal-body"> <form action="https://adoc.pub/login" method="post"> <div class="form-group"> <label class="sr-only" for="email">Email</label> <input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" /> </div> <div class="form-group"> <label class="sr-only" for="password">Password</label> <input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" /> </div> <div class="form-group"> <div class="checkbox"> <label class="form-checkbox"> <input type="checkbox" name="remember" value="1" /> Remember me </label> <label class="pull-right"><a href="https://adoc.pub/forgot">Forgot password?</a></label> </div> </div> <button class="btn btn-primary btn-block" type="submit">Sign In</button> </form> </div> </div> </div> </div>  <script async src="https://www.googletagmanager.com/gtag/js?id=UA-177279549-1"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-177279549-1'); </script> <script src="https://adoc.pub/assets/js/jquery-ui.min.js"></script> <link rel="stylesheet" href="https://adoc.pub/assets/css/jquery-ui.css"> <script> $(function () { $("#document_search").autocomplete({ source: function (request, response) { $.ajax({ url: "https://adoc.pub/suggest", dataType: "json", data: { term: request.term }, success: function (data) { response(data); } }); }, autoFill: true, select: function( event, ui ) { $(this).val(ui.item.value); $(this).parents("form").submit(); } }); }); </script>  <div id="ADOCPUB_cookie_box" style="z-index:99999; border-top: 1px solid #fefefe; background: #FFC107; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;"> Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://adoc.pub/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_ADOCPUB_cookie_box();return false;">Agree & close</a> </div> <script> function accept_ADOCPUB_cookie_box() { document.cookie = "ADOCPUB_cookie_box_viewed=1;max-age=15768000;path=/"; hide_ADOCPUB_cookie_box(); } function hide_ADOCPUB_cookie_box() { var cb = document.getElementById('ADOCPUB_cookie_box'); if (cb) { cb.parentElement.removeChild(cb); } } (function () { var ADOCPUB_cookie_box_viewed = (function (name) { var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)")); return matches ? decodeURIComponent(matches[1]) : undefined; })('ADOCPUB_cookie_box_viewed'); if (ADOCPUB_cookie_box_viewed) { hide_ADOCPUB_cookie_box(); } })(); </script>  </body> </html>

Metody udržování stavových informací v protokolu HTTP

Recommend Documents