getprotected

Transkript

getprotected

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
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 <PLAINTEXT>.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"><br>
<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
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
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
Date: Wed, 1 Aug 2001 20:30:29 GMT
WWW-Authenticate: Basic realm="chranena oblast"
Unauthorized
----------------------------------------------GET /protected.html HTTP/1.1
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
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 /
odesílá
Strana 45
Kapitola 4: Cookies
Prohlížeč
Výchozí Path
Neplatné Path
Nekompl. adresář
Navigator 4.03
k poslednímu /
odesílá
Mozilla 1.8a2
k poslednímu /
neodesílá
MSIE 2.0
celá adresa
odesílá
MSIE 3.0
k poslednímu /
odesílá
MSIE 6.0
k poslednímu /
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á
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
Strana 46
Kapitola 4: Cookies
Prohlížeč
Cizí doména
Přípustná doména
Opera 7.54
nepřijme a umí varovat
Lynx 2.8.4
nepřijme
Konqueror 3.2
přijme jako výchozí
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
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
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
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
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
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
[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 <[email protected]>: 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
[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
[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
[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]

getprotected

Transkript

Podobné dokumenty

AOL