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

Transkript

1 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 David Novák Vedoucí práce: PhDr. Otakar Pinkas Srpen 2006

2 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.

3 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 11. srpna 2006 David Novák

4 Abstrakt Posláním této bakalářské práce je sestavení uceleného pohledu na problematiku spojenou s využíváním interaktivních služeb WWW v rámci internetu. V tomto prostředí probíhá komunikace prostřednictvím protokolu HTTP, ten však ve své podstatě je bezestavový. Znamená to, že neukládá žádné informace mezi jednotlivými spojeními. Dnešní interaktivní webové aplikace ovšem takové prostředky nutně potřebují k zajištění svých funkcí. Proto se tato práce zabývá metodami udržování a přenášení stavových informací. V první části je popsán samotný protokol HTTP s přihlédnutím k historickému vývoji, hlavní zaměření je na jeho aktuální verzi HTTP 1.1. Dále je text věnovaný stavovým informacím, vysvětlení tohoto pojmu, členění a metodám uchovávání a přenosu těchto informací. Následuje oddíl věnovaný prostředníkům v komunikaci protokolem HTTP. Jedná se o proxy a cache servery, jež ukládají záložní kopie dat pro rychlejší opětovné použití a ušetření přenosových kapacit sítě. Tento systém s sebou v praxi přináší také řadu problémů, jež jsou popsány v souvislosti s provozem na internetu. Vyzdviženy jsou také poznatky týkající se rozšíření protokolu HTTP o možnost uchování stavových informací, jímž jsou cookies. Diskutována jsou bezpečnostní rizika s nimi spojená a zhodnocena je též implementace ve vztahu k jiným metodám. V souvislosti s cookies je zde popsána platforma P3P zabývající se ochranou soukromí uživatelů. Praktickou část tvoří jednoduchá aplikace implementující to nejlepší z popsaných metod z hlediska bezpečnosti a ochrany soukromí. Celá práce tedy může posloužit tvůrci webové aplikace k ujasnění zákonitostí a odhalení případných bezpečnostních rizik.

5 Abstract The mission of this batchelor thesis is to give complete view to the problems concerning usage of interactive WWW services in the internet, where the communication is runned by HTTP protocol. This protocol is stateless. It means, that no information is stored between each connection. Nowday s interactive web applications needs state informations for their proper functionality. That s why this thesis considers methods of storing and transmission of state informations. In the first part is HTTP protocol described with mentions to the historical development. Actual version HTTP 1.1 is mainly focused. Next part is addicted to state informations, to the definition explanation, classification and methods of storing and transmitting theese informations. Following section is concerned with communication intermediaries in HTTP protocol. It means proxy and cache servers, which saves backup coppies of data for faster reusing and transmission capacities saving. This system brings along many problems, which are discussed in context of internet activity. References to extension of HTTP protocol for carrying state informations are highlighted. This is cookies. Their security risks are being discussed and also implementation in the relation to other methods is evaluated. In context of cookies is described P3P platform concerning protection of users privacy. Practical part consists of trivial application implementing the best of methods described here from the view of security and protection of privacy. Whole work might serve to the web application builder, it helps to understand patterns and to detect appropriate security risks.

6 Obsah Obsah Úvod Protokol HTTP Obecně Komunikace URL Hlavičky Stavové kódy Metody požadavku Tvorba požadavku Tvorba odpovědi Bezestavovost HTTP HTTP Perzistentní spojení Podpora virtuálních serverů Vyjednávání o obsahu Určení délky Spolupráce s proxy a cache Další změny Cookies Stavové informace Metody uchovávání stavových informací Na straně klienta Na straně serveru Členění z hlediska významu Identifikační informace Transakční informace Metody přenosu stavových informací URL požadavku Skrytá formulářová pole HTTP autentizace Ostatní...26 Strana 6

7 Obsah 3 Proxy a cache Principy kešování Expirační mechanismus Validační mechanismus Kešování statických dokumentů Funkce proxy serverů Kešování dynamicky generovaných dokumentů Stavové informace a cache Cookies Funkce a typy Bezpečnostní rizika Cookies třetích stran Velikost cookie Cookies a SID P3P Platform for Privacy Preference Project Bezpečnostní politika Výroky Implementace Aplikace Model navigace Konfigurace Zabezpečení Challenge-response Kontrola IP adresy Transformace vstupu Další funkce...46 Závěr...47 Rejstřík vložených obrázků a tabulek...48 Seznam použité literatury...49 Seznam použitých zkratek a termínů...51 Strana 7

8 Úvod Úvod Internet pronikl snad do všech sfér lidské společnosti a spojuje miliony uživatelů na celém světě. Během poměrně krátkého časového období došlo k velkému vývoji a nejvíce se rozšířila služba WWW. Nejprve šlo o zprostředkování statických dokumentů, zanedlouho se však začalo také s provozováním interaktivních aplikací, vyžadujících přenos a uchovávání stavových informací. Protože se již několik let osobně věnuji tvorbě takovýchto webových aplikací a tato problematika mne zajímá, vybral jsem si toto téma této pro svou bakalářskou práci. Cílem práce je vysvětlit principy fungování služeb v prostředí internetu, popsat základy jako samotný protokol HTTP používaný při komunikaci a další související pojmy. V souvislosti se zmíněnými interaktivními aplikacemi se práce zabývá používáním stavových informací včetně metod jejich uchovávání. Architektura klient-server umožňuje ukládání jak na straně serveru, tak na straně klienta. Vždy je ale nutné přenášet alespoň část dat sloužících jako identifikátory (uživatelů, relací). Má tedy smysl se zabývat také metodami přenosu stavových informací. Možností je několik a jsou popsány v této práci. Jak je známo, prostředí internetu skýtá široké spektrum možností a aktivit, ať již běžných legálních (nikoho neomezujících), či škodlivých a potenciálně nebezpečných (útoky třetích osob na soukromí a data uživatelů). Otázka bezpečnosti internetu je tedy aktuálním tématem. S rozvojem a příchodem nových technologií přicházejí vždy také nová bezpečnostní rizika, proto je nutné neustále pracovat na ochraně webových aplikací a příslušných dat, tak aby se případnému útočníkovi pokud možno zamezil nebo alespoň ztížil přístup k zmíněným chráněným informacím. V této práci jsem při rozboru jednotlivých témat naznačil možná související bezpečnostní rizika a protiopatření. Je zde také popsán mezinárodní standard W3C zabývající se ochranou soukromí, a sice platforma P3P. Při ochraně informací na webu i samotné komunikace je vhodné držet se známých zásad, z nichž mnohé zde popisované, jsou implementovány v ukázkové aplikaci tvořící praktickou část této práce. Strana 8

9 1 Protokol HTTP Kapitola 1: Protokol HTTP Tato kapitola je věnována vysvětlení pojmu HTTP, popisu vývoje tohoto protokolu se zaměřením na jeho poslední verzi 1.1 popsanou dokumentem RFC 2616 [27]. Zabývat se bude též problematikou bezestavovosti protokolu HTTP (s naznačením různých technik umožňujících toto omezení překonat, o nichž bude psáno v kapitole následující). 1.1 Obecně Protokol HTTP (HyperText Transfer Protocol) je základem nejpoužívanější služby internetu WWW (World Wide Web), zde jsou data zakódována v jazyce HTML 1 a přistupuje se k nim pomocí schematu URI 2, komunikace a přenos dat je zajištěna právě protokolem HTTP. Protokol HTTP je používaný při komunikaci mezi prohlížečem a webovým serverem. Je to tzv. aplikační protokol, který pro přenos po síti využívá protokoly nižších vrstev síťového modelu. Jedná se o protokoly TCP/IP 3. Standardně se pro HTTP používá TCP port 80. Pro přenos dat lze použít i jiný protokol zajišťující spolehlivý přenos dat. Příkladem je protokol SSL, jenž je mezičlánkem mezi HTTP a TCP/IP zajišťujícím šifrování komunikace Komunikace HTTP vychází z architektury klient-server a komunikace je založena na požadavek-odpověď (anglicky request-response). Klient, v tomto případě internetový prohlížeč (browser), vytvoří spojení se serverem a pošle mu požadavek. Server reaguje na klientův požadavek a zasílá odpověď. Přesný formát požadavku a odpovědi lze najít ve specifikaci [27] a mechanismus jejich tvorby je popsán dále. Komunikace neprobíhá vždy přímo mezi koncovým klientem a cílovým serverem (obsahujícím požadovaný dokument). Mezi nimi se mohou vyskytovat prostředníci (zprostředkovatelé), které pak v rámci komunikace vystupují jako server ve vztahu ke klientovi, či klient ve vztahu k cílovému serveru. Jedná se o cache a proxy servery. Jednou z jejich funkcí je uchovávání dokumentů, které již byly různými klienty prostřednictvím cache serveru požadovány. Výsledkem je zrychlení komunikace a ušetření přenosové kapacity v případě, že klient požaduje znovu stejný dokument prostředník ho klientovi odešle přímo bez nutnosti stažení z cílového serveru 4. 1 HyperText Markup Language značkovací jazyk sloužící pro formátování dokumentů v prostředí internetu. Internetové prohlížeče tento jazyk interpretují a požadovaný dokument zobrazí uživateli. 2 Uniform Resource Identifier univerzální schema užívané k adresování zdrojů. V prostředí WWW se používá jeho podmnožina URL (Uniform Resource Locator) schema umožňující každému dokumentu přiřadit přesnou adresu (místo uložení). Bližší informace viz [23]. 3 Transmission Control Protocol over Internet Protocol - nejrozšířenější transportní protokol používaný pro přenos dat mezi počítači v síti internet, využívající síťového protokolu IP. 4 Toto je hodně zjednodušené, tento proces se řídí přesnými pravidly. Prostředník ověřuje, jestli má uloženou aktuální verzi dokumentu atd. Strana 9

10 Kapitola 1: Protokol HTTP Jednotlivé možnosti komunikace znázorňují následující obrázky. Nejprve se podíváme na komunikaci přímo mezi klientem a cílovým serverem, kdy je pro každý požadavek navázáno nové spojení. Obrázek 1: Komunikace klient-server v HTTP - opakované požadavky a nová spojení Při použití proxy serveru jsou požadavky různých koncových klientů dále vůči cílovému serveru reprezentovány jako požadavky jednoho klienta, a sice prostředníka (proxy serveru). Obrázek 2: Komunikace klient-proxy-server v HTTP Následující obrázek znázorňuje zrychlení přístupu k požadovanému dokumentu s využitím uložené kopie na cache serveru. Obrázek 3: Komunikace v HTTP za použití cache URL URL vyjadřuje umístění dokumentu na serveru a každý dokument je jím jednoznačně určen. Existují dva druhy URL absolutní a relativní. Absolutní URL v sobě obsahuje označení metody (protokolu), jméno serveru (příp. použitý port) a cestu k dokumentu nacházejícího se v adresářové struktuře serveru a jeho název. Dokument může být rozdělen na více částí, v tom případě se mnohou použít tzv. kotvy k upřesnění polohy uvnitř dokumentu. Absolutní URL má takovýto tvar: protokol://server [:port]/cesta/soubor [#kotva] Relativní URL se používá ke směrování v rámci jedné webové aplikace na daném serveru. Neobsahuje označení protokolu ani název serveru a tyto parametry se při použití relativní URL určují vzhledem k dokumentu, ve kterém je obsaženo. Pro názornost uvádím příklad absolutní URL při použití protokolu HTTP. Implicitní port 80 se v tomto případě uvádět nemusí, příklad odkazuje na třetí kapitolu dokumentu: Strana 10

11 1.1.3 Hlavičky Kapitola 1: Protokol HTTP Hlavičky v HTTP mají podobný koncept jako hlavičky elektronické pošty, odesílají se před samotným dokumentem každá na jednom řádku. Hlavička má svůj název a hodnotu, jež odděluje dvojtečka a je zakončena řetězcem CR LF 5 označujícím konec řádku. Od těla požadavku/odpovědi se oddělují prázdným řádkem. Specifikace HTTP 1.1 [27] definuje 47 různých hlaviček (oproti 17 v předchozí verzi), některé z nich jsou povinné (Host, Content-Length), většina jich je však nepovinných. Hlavičky obsahují dodatečné upřesňující informace k požadavku, respektive k odpovědi, tedy také k přenášenému dokumentu. Dělí se do čtyř skupin podle toho, čeho se týkají: Obecné hlavičky (anglicky General-Header) se týkají daného spojení. Jedná se o hlavičku Date, jež obsahuje datum uskutečnění spojení a Pragma, určená pro případné prostředníky v komunikaci (cache servery). V souvislosti s proxy byla zavedena také hlavička Via, která v sobě nese záznam o všech prostřednících během komunikace a slouží tak jako prevence zacyklení. Hlavičky požadavku (Request-Header) zasílá klient, týkají se konkrétního požadavku a obsahují zejména autentizační údaje, identifikační údaje aplikace klienta či hlavičky pro podmíněný požadavek. Z hlediska zaměření této práce jsou z této skupiny zajímavé hlavičky Referer, From či If-Modified-Since. Hlavička Referer obsahuje jako hodnotu URL dokumentu, z něhož byl uživatel na požadovaný dokument odkázán. V praxi se dá využít k monitorování pohybu uživatelů v prostředí internetu, což s sebou nese také určitá bezpečnostní rizika 6. Rozporuplná je i hlavička From, neboť dle původního záměru má obsahovat adresu elektronické pošty uživatele zodpovědného za odeslaný požadavek. Toho mělo být využíváno k případnému upozornění uživatelů zasílajících nesprávné požadavky. V praxi se ovšem již skoro nepoužívá, neboť její obsah by vedl spíše ke zneužívání zasílání spamu 7 a identifikaci uživatele na základě jeho ové adresy. Z hlediska dále popsaného kešování je důležitá hlavička If-Modified-Since, pomocí které se zjišťují změny dokumentu od poslední návštěvy. Hlavičky odpovědi (Response-Header) umožňují serveru přesměrovat klienta na jinou adresu, vyzvat ho k zadání autentizačních údajů či identifikovat svůj software. Hlavičky týkající se těla požadavku/odpovědi (Entity-Header) popisují typ přenášeného dokumentu (Content-Type), datum poslední úpravy (Last-Modified), dále případné transformace (Content-Encoding) či délku v bytech (Content-Length). 5 Carriage Return, Line Feed instrukce pocházející z dob psacích strojů. Návrat vozíku a posun papíru. 6 Zejména se jedná o únik identifikátoru session-id. Tento problém a další bezpečnostní rizika jsou předmětem následujících kapitol. 7 Nevyžádaná reklamní pošta rozesílaná na tisíce ových adres. Je to problém celosvětového měřítka zabírající významné procento přenosové kapacity počítačové sítě. Strana 11

12 1.1.4 Stavové kódy Kapitola 1: Protokol HTTP Nedílnou součástí odpovědi serveru jsou trojciferné stavové kódy udávající výsledek provedené operace. Klient díky nim zjistí, jaký byl výsledek jeho požadavku. Na základě kódu může prohlížeč zobrazit uživateli slovní popis 8 (stavové hlášení). Dělení stavových kódů do pěti kategorií ukazuje následující tabulka: Kategorie Rozsah kódů Popis Informační Informativní zprávy. Úspěch Požadavek byl úspěšně zpracován. Přesměrování Přesměrování na jinou adresu. Chyba klienta Problémy na straně klienta. Chyba serveru Problémy na straně serveru. Tabulka 1: Kategorie stavových kódů v odpovědi protokolu HTTP Stavové kódy dělitelné stem jsou brány jako obecné. Uvozují a reprezentují celou třídu. Pokud klient nezná konkrétní kód, může jej interpretovat právě jako by to byl kód obecný. Ve druhé tabulce jsou vypsány nejfrekventovanější stavové kódy a jejich popis: Stavový kód Popis 100 Continue Klient může pokračovat v zasílání požadavku. 200 OK Operace proběhla bez chyby, požadavek je úspěšně splněn. 300 Multiple choices Požadovaný zdroj se dá získat z několika různých míst. 301 Moved Permanently Požadovaný dokument se trvale přesunul na novou adresu URL. 302 Moved Temporarily Požadovaný dokument se dočasně přesunul na jinou adresu URL. 400 Bad Request Server nerozumí požadavku klienta. 401 Unauthorized Požadavek klienta má být autentizován nebo byl odepřen přístup. 403 Forbidden Server nemůže požadavku vyhovět, autorizace nebyla úspěšná. 404 Not Found Server nenašel zadanou adresu URL. 500 Internal Server Error Došlo k vnitřní chybě serveru. Tabulka 2: Výběr často používaných stavových kódů v odpovědi protokolu HTTP Metody požadavku V současném HTTP 1.1 (touto verzí se zabývá subkapitola 1.3) existuje osm základních metod požadavků protokolu HTTP: GET vracející jako odpověď požadovaný dokument včetně hlaviček. Je to základní nejčastěji používaná metoda. Jsou-li touto metodou odesílána data z formuláře, najdeme je zakódované do URL. POST odesílající formulářová data v těle požadavku za hlavičkami. Data mají být zakódována do URL v těle požadavku, lze je ale odeslat i nezakódovaná. Výhodou oproti 8 Případně může zobrazit vysvětlující text v jazyce uživatele. Strana 12

13 Kapitola 1: Protokol HTTP metodě GET je možnost odeslat větší objem dat, než jaký se vejde do URL. Co se týče možností zobrazení (zachycení) zasílaných dat a logování, je o něco bezpečnější než metoda GET. Pokud se ale žádná data v těle neodesílají, je prakticky s metodou GET shodná. HEAD vracející pouze hlavičky. Je možné ji využít při zjišťování změn dokumentu od posledního požadavku. PUT fungující jako metoda GET, uchovává tělo požadavku na místě daném v URL. DELETE odstraňující dokument ze serveru. Cesta k dokumentu určenému k odstranění je v URL požadavku. OPTIONS umožňující zjistit vlastnosti určitého dokumentu (aniž by byl zdroj znovu načten) či možnosti serveru a nastavení komunikace, odpovědi na tuto metodu nelze kešovat. TRACE vracející v odpovědi požadavek ve stejném formátu, jak přišel na server. Používá se pro sledování požadavku přes všechny proxy servery a firewally, přes které probíhá komunikace. CONNECT je ve specifikaci pouze rezervované jméno metody určené pro spolupráci s proxy servery, které umí dynamicky vytvořit komunikační tunel např. při SSL tunellingu. Používá se při průchodu skrze proxy pro ustanovení kanálu SSL. Za každým požadavkem ještě mohou následovat jednotlivé hlavičky, po nich musí následovat prázdný řádek. Známe již princip fungování komunikace pomocí protokolu HTTP, používané stavové kódy, metody a hlavičky. Následuje tedy příklad požadavku a odpovědi: GET / HTTP/1.1 Host: User-Agent: Mozilla/5.0 Accept: text/xml,application/xhtml+xml,text/html;q=0.9 Accept-Language: cs,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive HTTP/ OK Date: Sun, 6 Aug :15:47 GMT Server: Apache Last-Modified: Wed, 19 Jul :27:30 GMT Etag: "f7c136-2c6e-5b985880" Accept-Ranges: bytes Content-Length: Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html V tomto příkladu je vidět několik zajímavých hlaviček a parametrů, kterými se bude zabývat text následujících kapitol. Zvýraznil jsem parametr q využívaný při vyjednávání o obsahu a také Etag sloužící při validačním mechanismu kešování. Strana 13

14 1.1.6 Tvorba požadavku Kapitola 1: Protokol HTTP Požadavek generuje klient na základě akce klienta (zadání adresy URL do prohlížeče, kliknutí na odkaz či odeslání formuláře). Bez zásahu uživatele se požadavek generuje např. jako reakce na odpověď serveru s kódem pro přesměrování. V tomto případě je URL dokumentu obsaženo v HTTP hlavičce Location. Zjednodušený proces tvorby požadavku v prohlížeči: Rozbor URL požadovaného dokumentu zjištění jména serveru, nastavení do hlavičky Host a vyhledání jeho IP adresy pomocí DNS 9, následné použití této adresy pro vytvoření spojení. Přechází-li uživatel z jiné webové stránky, např. kliknutím na odkaz, je do požadavku přidána hlavička Referer obsahující URL předešlé stránky. Díky tomu lze na straně serveru zjistit, odkud uživatel přišel. Existují-li v počítači klienta cookies 10 platné pro cílový server, prohlížeč je přidá k požadavku v hlavičce Cookies. Pokud uživatel odesílá data z formuláře, prohlížeč v případě použití metody GET přidá formulářová data do URL požadavku za otazník jako názvy a hodnoty. Při použití metody POST se tato data předávají v těle požadavku. Veškerá odesílaná data jsou URL encoded, tzn. zakódovaná podle specifikace RFC 1738 [23]. Z každého znaku (kromě alfanumerických) vznikne dvouciferný kód uvozený znakem %. Parametry se od sebe oddělují znakem & a názvy od hodnot znakem =. Po přidání všech potřebných hlaviček je takto sestavený požadavek zaslán serveru. Pokud je dokument tvořen z více objektů, musí prohlížeč pro každý tento objekt vytvořit vlastní požadavek. Jde např. o dokumenty obsahující obrázky, animace, aplety atd Tvorba odpovědi Zjednodušený proces přijetí požadavku serverem, jeho rozboru a následné reakce odpovědi: Z adresy URL požadovaného dokumentu zjistí jeho umístění ve své adresářové struktuře. Podle přípony zjistí o jaký typ dokumentu se jedná, zdali jde spustitelný skript či statickou HTML stránku, obrázek atd. V případě statického dokumentu je proces jednoduchý, server takovýto soubor pouze načte a odešle ho v těle odpovědi klientovi spolu s příslušnými HTTP hlavičkami. Jedná-li se ale o spustitelný soubor (např. PHP, JSP či ASP 11 skript), pak server spustí odpovídající interpret a předá mu parametry z klientova požadavku. Jako odpověď je potom 9 Domain Name System server obsahující doménová jména a k nim náležící IP adresy. 10 Systém souborů uchovávajících stavové informace na straně klienta, podrobněji viz kap. 1.4 a PHP a ASP jsou jedny z nejrozšířenějších programovacích jazyků v prostředí internetu. PHP je na unixové platformě nejčastěji implementován na serveru Apache ve spojení s databází MySQL (tuto kombinaci osobně již několik let využívám), naproti tomu ASP bylo vytvořeno pro platformu Windows, bývá provozováno na serveru Microsoft IIS (Internet Information Server) ve spojení s databází MSSQL. Strana 14

15 Kapitola 1: Protokol HTTP zaslán klientovi výstup z tohoto programu včetně HTTP hlaviček. Tento postup je popsán v specifikaci CGI Bezestavovost HTTP Protokol HTTP je bezestavový. Funguje na principu požadavek-odpověď. Klient ani server nezná a nezaznamenává žádné souvislosti mezi jednotlivými požadavky. Takováto koncepce je výhodná z hlediska snadné implementace klientů i serverů. Dále tak nemohou vznikat problémy v důsledku softwarových chyb či neočekávaných ukončení spojení. Tyto výhody zřejmě převažují omezení plynoucí z bezestavovosti HTTP. Protože je ale velká potřeba uchovávat stavové informace v prostředí internetu, musí tvůrci www stránek toto omezení překonat. Existují proto různé metody, jimiž se zabývá druhá kapitola. 1.3 HTTP 1.1 Za aktuální verzí protokolu HTTP 1.1 stojí dlouhý vývoj. Od vzniku v roce 1990 prošel mnoha úpravami, postupně byly začleňovány nové prvky v souladu s potřebami rychle rostoucího počtu WWW stránek a vylepšováním jazyka HTML. Co se týká samotných internetových prezentací, došlo k posunu od jednoduchých statických stránek k daleko složitějším dynamickým aplikacím. Princip fungování protokolu HTTP však zůstal stejný. Ve verzi HTTP 1.1 byly přidány potřebné funkce, jež překonávaly mnohá omezení předchozích verzí (HTTP 0.9 a 1.0) tak, aby bylo dosaženo optimálnějšího využití přenosových kapacit síťových prvků a komunikace v síti internet se zrychlila. Na mysli mám hlavně zavedení perzistentního spojení, díky kterému již server nemusí otevírat nová spojení pro všechny části složeného dokumentu (např. HTML galerie obrázků) a postačí mu jedno, jež po skončení přenosu zavře. Druhým citelným omezením historických verzí HTTP byla možnost pouze jednoho doménového jména pro jednu IP adresu, což se v praxi ukázalo být nedostačující, a tak se tento problém vyřešil zavedením povinné hlavičky požadavku Host, díky níž může být pod jednou IP adresou provozováno více virtuálních serverů s odlišnými doménovými jmény. Jako další vylepšení zmíním podporu pro vyjednávání o obsahu, částečné přenosy a zpřesnění specifikace týkající se spolupráce i chování proxy a cache serverů. Platným standardem IETF v posledním znění je dokument RFC 2616 [27] uveřejněný v červnu Perzistentní spojení Při tomto spojení nechá server po odeslání odpovědi klientovi po krátký časový interval otevřený přenosový kanál. Klient tedy nemusí v případě navazujících požadavků navazovat nová spojení a může tento kanál opětovně využívat pro veškeré části složeného dokumentu, jež je požadován, dokud některá ze stran neodešle hlavičku Connection: close. Tento model významně urychluje komunikaci mezi klientem a serverem, jsou-li stahované 12 Common Gateway Interface definuje názvy proměnných, kterými server předává programu data. Dále jednoznačně označuje proměnné, které v CGI programu odpovídají HTTP hlavičkám. Např. pro hlavičku User-agent je v CGI proměnná HTTP_USER_AGENT. Strana 15

16 Kapitola 1: Protokol HTTP dokumenty složeny z více dílů. Např. HTML stránky obsahující grafiku, obrázky a kaskádové styly v připojených souborech. Obrázek 4: Perzistentní spojení v HTTP zasílání opakovaného požadavku Tzv. pipelining slouží k ještě mocnějšímu urychlení komunikace, ovšem ne všechny HTTP servery ho podporují a správně implementují. Spočívá v tom, že klient v rámci daného spojení nečeká na odpověď serveru, ale odesílá více požadavků najednou. Obrázek 5: Pipelining zasílání více požadavků najednou při perzistentním spojení v HTTP Podpora virtuálních serverů Pomocí přidané hlavičky Host lze na jedné IP adrese provozovat množství různých virtuálních serverů. Tato hlavička je v HTTP 1.1 povinná, proto pokud ji požadavek neobsahuje, server odpoví chybovým hlášením (kód 400 chybný požadavek). V hlavičce Host je uveden název serveru (příp. číslo portu) z URL požadovaného dokumentu. Pro ilustraci uvádím část požadavku klienta pro stahování dokumentu z adresy na virtuálním serveru GET /doc.html HTTP/1.1 Host: virtual.server.net... Nastavení DNS Pro nastavení virtuálních serverů v DNS se používají tzv. A a CNAME záznamy. A záznam určuje, na jakou IP adresu bude doména nasměrována. Jeho pomocí lze také vytvořit doménu III. řádu k již existující doméně II. řádu. Takto nově vytvořená doména III. řádu poté samostatně odkazuje na jiný www server (jinou IP adresu), nezávisle na nadřazené doméně II. řádu. Následuje příklad možné změny DNS pomocí zákaznického centra hostingu Obrázek 6 zachycuje formulář grafického rozhraní, v poli Jméno se určuje název virtuálního serveru, TTL (Time to Live) je volitelný parametr udávaný v sekundách, určující jak dlouho se mají data uchovávat v databázi. V tomto případě dochází k přesměrování domény na novou IP 13 adresu: 13 Takovéto nastavení DNS má přímí vliv na funkčnost domény, v případě zadání špatné IP adresy nebude směrování správně fungovat. Strana 16

17 Kapitola 1: Protokol HTTP Obrázek 6: Nastavení A záznamu v konfiguraci DNS CNAME (Canonical Name) slouží k vytvoření aliasů k doménovému jménu, nebo pro vytvoření domén III. řádu. Nepracuje se tedy přímo s IP adresami ale s doménovými jmény. Obrázek 7 ukazuje vytvoření domény III. řádu eshop.novanet.cz a její nasměrování na doménu onlineshop.unas.cz. V tomto případě musí být pro správnou funkci v poli Alias k na konci URL tečka. Obrázek 7: Nastavení CNAME záznamu v konfiguraci DNS Vyjednávání o obsahu Toto rozšíření se hodí, když je dokument dostupný ve více verzích (jazykových, kódování) nebo formátech pro různé klienty 14 (prohlížeče rozličných zařízení). Vyjednávání o obsahu má podle RFC 2616 tři typy umožňující vybrat pro uživatelské zařízení nejvhodnější formu požadovaného dokumentu: Vyjednávání řídí server na základě přijatých hlaviček z požadavku klienta vybere vhodnou formu dokumentu, jež následně odešle v odpovědi. Zmiňované hlavičky požadavku určené k tomuto typu vyjednávání o obsahu mívají zpravidla názvy začínající na Accept. K nabídnutí dostupných variant klientovi slouží serveru hlavička Vary. Pro příklad následuje ukázka použití metody OPTIONS ke zjištění, jaké dotazy (metody) může klient pro vybraný kontext serveru zaslat a výňatek z odpovědi serveru: 14 Kromě počítačů se jedná především o různá mobilní zařízení s přístupem na internet, WAPové prohlížeče mobilních telefonů či kapesních počítačů. Ty většinou nejsou na rozdíl od stolních PC schopny zobrazit stránky v HTML, proto jsou dnes pro takováto zařízení k dispozici dokumenty v jazyce WML. Strana 17

18 Kapitola 1: Protokol HTTP OPTIONS * HTTP/1.1 Host: HTTP/ OK Date: Sun, 6 Aug :15:47 GMT Server: Apache Vary: Accept-Charset,Accept-Language,Accept-Encoding Allow: GET, HEAD, OPTIONS, TRACE Transfer-Encoding: chunked Content-Type: text/plain Vyjednávání řídí klient po obdržení informací od serveru o dostupných verzích dokumentu klient sám, nebo po interakci uživatele, vybere vhodnou variantu a následným požadavkem dokument získá. Ukážeme si zde několik hlaviček a hlavně parametr q určující klientovy preference jednotlivých variant požadovaného dokumentu: Accept: text/html,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: cs,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.7 Klient takto dá serveru jasně najevo, jaké typy informací přijme a příslušné preference mezi nimi. Implicitní hodnota q=1 se neuvádí, značí objekt s nejvyšší preferencí. Pokud se dle příkladu na serveru nevyskytuje cs varianta a en-us i en ano, bude vybrána en-us díky vyšší hodnotě q. Transparentní vyjednávání tento typ komunikace je kombinací obou předchozích a lze ho využít za předpokladu použití proxy cache serveru. Nastavení Apache S předchozím textem také souvisí nastavení na straně serveru, v případě Apache se v konfiguračním souboru conf\httpd.conf pomocí direktivy Options MultiViews povolí výše zmíněné vyjednávání o obsahu (Content Negotiation). Tento kód se nachází uvnitř tagu <Directory> určujícího adresář, jehož se nastavení týká: <Directory "C:/Apache/htdocs"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory> Určení délky S rozvojem dynamicky generovaných dokumentů prezentovaných na internetu nastal problém s určením velikosti zasílaného souboru. Dříve používaná hlavička Content-Length se stala nevyhovující, neboť při odesílání před samotným dokumentem je v případě generovaného obsahu problém zjistit jeho budoucí velikost. Server by tak musel čekat, než se celý dokument vygeneruje a to by způsobilo časové prodlevy. Proto byl vynalezen způsob zakódování přenášených dat tak, aby mohla být odesílána po částech, přičemž každá část je uvozena svou délkou. Tento způsob se značí hlavičkou Transfer-Encoding:chunked. Strana 18

19 1.3.5 Spolupráce s proxy a cache Kapitola 1: Protokol HTTP Ve specifikaci HTTP 1.1 je velmi podrobně řešena spolupráce klientů a serverů s cache a proxy servery. S dokumenty uloženými v cache se pracuje na základě jejich expirace (vypršení platnosti), data pořízení kopie a validace (ověření). Jsou uvedena standardní pravidla chování cache a proxy serverů, včetně hlaviček umožňujících měnit tato pravidla pro konkrétní požadavky, resp. dokumenty. Funkci cache v sobě mají zabudovanou také prohlížeče klienta, princip je stejný. Prohlížeč si dočasně ukládá do paměti navštívené stránky, aby je následně mohl rychle načíst při opětovném požadavku. Podrobněji se tomuto tématu bude věnovat třetí kapitola Další změny Výčtem změn by se dalo pokračovat ještě dlouho, ovšem pro potřeby této práce to není nutné a postačí zmínit podstatné novinky. Zavedena byla podpora vyžádání a přenosu neúplných dokumentů v určitém rozmezí bytů, což v praxi umožňuje přerušení a následné navázání stahování dokumentů. Přidány byly nové metody (OPTIONS a TRACE). Celkový počet stavových kódů je 37 a specifikace HTTP 1.1 byla obohacena o 30 nových hlaviček. 1.4 Cookies Cookies jsou rozšířením protokolu HTTP umožňujícím uchovávání stavových informací na straně klienta, překonávají tak omezení bezestavovosti, o kterém je psáno výše. Cookies je věnována pátá kapitola, nicméně považuji za vhodné je zde zmínit. Nejrozsáhlejší specifikace cookies se nachází v dokumentu RFC 2965 [30] pocházející z roku 2000, blíže k tomuto dokumentu a ostatním historickým verzím je psáno v subkapitole 4.1. Jedná se o soubory s časově omezenou platností uložené v počítači klienta. Obsahují názvy a hodnoty proměnných, jež mohou být opakovaně užívány při přístupu k serveru, z něhož pocházejí. Cookie je u klienta uložena (na pevný disk či do operační paměti) po zaslání odpovědi serverem obsahující hlavičku Set-Cookie. Podle místa uložení rozlišujeme tzv. session cookies uložené v operační paměti (vymazané po ukončení prohlížeče) a trvalé cookies uložené na disku do okamžiku vypršení jejich platnosti. Pokud klient obsahuje cookie platnou pro daný server 15, odesílá jí tomuto serveru s každým svým požadavkem. 15 Cookie platí pouze pro server, ze kterého byla klientovi odeslána, a to po dobu platnosti určenou při jejím vytvoření. Strana 19

20 2 Stavové informace Kapitola 2: Stavové informace S rozvojem interaktivity webových aplikací 16 vzrostla také potřeba přenášet a uchovávat stavové informace. Na to ovšem protokol HTTP není uzpůsobený, neboť s každým přijatým požadavkem klienta je na straně serveru zacházeno jako s prvním. Proto je nutné mít takové informace obsaženy přímo v požadavku, aby je server mohl postoupit na něm implementovanému CGI skriptu nebo jiné aplikaci, která je dále zpracovává. Tyto nároky více či méně efektivně splňuje několik různých metod, jejichž popisem a diskuzí jejich výhod a nevýhod se budu zabývat v následujícím textu. 2.1 Metody uchovávání stavových informací Metod pro uchovávání stavových informací je celá řada. Hlavním kritériem jejich rozlišení je hledisko uložení stavových informací. Mohou být uloženy buďto na straně klienta, nebo na straně serveru. Vždy je ovšem nutností alespoň část informací posílat. Pokud jsou uloženy na straně klienta, musí se serveru poslat všechny, se kterými je potřeba dále pracovat. V případě uložení na straně serveru je nezbytné při komunikaci s klientem si vzájemně odesílat jednoznačné identifikátory umožňující přístup k odpovídajícím stavovým informacím. V obou situacích je tedy legitimní hovořit o metodách přenosu stavových informací (viz kap. 2.3) Na straně klienta Jedná se o udržení přijatých stavových informací od serveru po dobu přerušení spojení a jejich následné odeslání zpět s dalším požadavkem. K tomuto účelu slouží již zmíněný mechanismus cookies 17, který je pro server jedinou cestou, jak do počítače klienta uložit soubor s daty a následně ho získat zpět 18. Používání cookies může uživatel zamezit, proto je nutné umět uchovat stavové informace i jinak. Takto uchovávané informace jsou dynamicky vygenerovány a skryty v pozadí dokumentu načteného v prohlížeči 19. Nejčastěji jsou zakódovány v URL všech vnitřních odkazů stránky, nebo jako hodnoty skrytých formulářových polí Na straně serveru Pokud má webová aplikace práva pro práci se systémem souborů na serveru (většinou pouze v adresáři, kde je aplikace umístěna), může stavové informace dané relace uchovávat tak, že pro ně vytvoří zvláštní soubory. Druhou možností je využití databáze (většinou relační), ve které mohou být data relace uloženy. V každém případě je ale nutné mezi klientem a serverem přenášet identifikátor relace. 16 Online nakupování, práce s y, vyhledávání v databázích, ověřování uživatelů při vstupu do systému, různá uživatelská nastavení atd. 17 Ten je samozřejmě schopen stavové informace udržet i déle, než jen po dobu zobrazení stránky v prohlížeči. 18 Server samozřejmě nemá právo manipulovat se systémem souborů u klienta. Do dočasné paměti se sice ukládají soubory z internetu, využívají se ale pouze k rychlejšímu znovunačítání dokumentů a nejsou odesílány zpět serveru. 19 Skryty oku běžného uživatele, jsou totiž obsaženy ve zdrojovém kódu, nemají však grafickou reprezentaci. Strana 20

21 2.2 Členění z hlediska významu Kapitola 2: Stavové informace Z významového hlediska dělíme stavové informace na identifikační a transakční. Pro práci uživatele s webovou aplikací se vžil termín relace neboli sezení (z anglického session). Takto bývá označován časový úsek od přihlášení uživatele (či první návštěvy stránky 20 ) po odhlášení z aplikace, přechod na jiný server nebo ukončení prohlížeče Identifikační informace Slouží k udržování spojitosti mezi aktuální relací a jejím vlastníkem. Pro identifikátor relace se vžil anglický termín session-id. Je důležité, aby v rámci jedné webové aplikace existovaly pouze unikátní identifikátory, jinak by takovýto systém nemohl správně fungovat. V případě přenosu identifikátoru je též relevantní mluvit o bezpečnostních aspektech, neboť by mohl útočník při úspěšném zcizení takovéto informace získat přístup do zabezpečené zóny s chráněnými informacemi a vydávat se tak za legitimního uživatele. Není vhodné identifikátory ukládat ani přenášet v tzv. otevřené formě. Pro ochranu se používají různé šifrovací algoritmy Transakční informace Většinou představují data zadaná uživatelem během určité transakce (konečné posloupnosti kroků vedoucí k reakci systému). Jako příklad uvedu vyplnění formuláře a jeho odeslání s následnou zprávou serveru o provedené akci. Nebo práci v administrátorském rozhraní mazání položek stiskem tlačítka (systému je odeslán identifikátor položky a následně po smazání je poslán identifikátor výsledku akce, na jehož základě je pak uživateli generována zpráva o úspěšnosti úkonu). V tomto případě jsou identifikátory transakčními informacemi a po provedení akce ztrácejí svůj význam a jsou vyřazeny. 2.3 Metody přenosu stavových informací Z předchozího textu je zřejmé, že k přenosu stavových informací 22 musí docházet vždy, a to bez ohledu na to, kde jsou uloženy, jestli na straně klienta nebo serveru. Metody přenosu pomocí HTTP lze rozdělit do dvou kategorií. Největší skupinou jsou metody využívající přímo vlastnosti protokolu HTTP. Druhou kategorii tvoří Cookies jedná se o rozšíření protokolu HTTP (viz pátá kapitola). 20 Ne všechny webové aplikace pracující se stavovými informacemi vyžadují přihlášení uživatele. Relace tak vzniká v pozadí, leckdy aniž by to uživatel věděl. Na druhou stranu je zřejmé, že uživatele nezajímá systém stavových informací zajišťující funkčnost jím navštíveného systému to je věc programátora. 21 Pokud ani jedna z těchto událostí nenastane, je vhodné mít relace omezené dobou platnosti pro větší zabezpečení dat. Toto omezení spočívá v tom, že pokud po určitý časový interval není zaznamenána žádná interakce od uživatele (zpravidla to bývá půl hodiny, podle úrovně zabezpečení např. elektronické bankovnictví má kratší dobu expirace), relace vyprší a uživatel se musí přihlásit znovu. Zamezuje se tak zneužívání relací třetími osobami. 22 Alespoň jejich části identifikátoru relace. Strana 21

22 2.3.1 URL požadavku Kapitola 2: Stavové informace Přenášet stavové informace v URL lze třemi různými způsoby. Výhodou této metody je, že ji uživatel nemůže blokovat, na rozdíl například od Cookies. První dva způsoby mají sice poměrně jednoduchou implementaci, ale jejich velkou nevýhodou je nutnost dynamicky generovat veškeré odkazy zpět na daný server tak, aby v sobě předávané informace udržovaly: Za otazníkem po názvu dokumentu takto se předávají skriptu parametry. Většinou bývají od sebe odděleny znakem & a název od hodnoty parametru znakem =. Je to zřejmě nejčastěji používaný způsob, neboť nevyžaduje žádné náročné nastavení webového serveru a je podporován mnoha implementačními prostředími pro webové aplikace, zejména extrakcí dat z této části URL do proměnných. Tento způsob je vhodný pro přenášení transakčních i identifikačních informací. Při použití automatického přepisování odkazů v PHP se tato metoda také využívá, slouží k zajištění funkčnosti aplikace uchovávající identifikátory pomocí cookies (viz kap. 4.4), pokud jsou klientem odmítnuty. Spočívá v přidání konstanty SID do parametru URL, ta je prázdná dokud funguje mechanismus cookies. V opačném případě obsahuje identifikátor relace, jenž se následně objeví v URL (což s sebou přináší bezpečnostní rizika). Takto mohou vypadat absolutní URL včetně dat za otazníkem: Za jménem dokumentu jako virtuální adresář je vlastně obdobou metody první. Přenášená data se za jménem souboru oddělují lomítkem, jako by šlo o adresářovou strukturu. Může se kombinovat s metodou první a za tuto strukturu oddělenou lomítky lze ještě přidat otazník s dalšími parametry. Tato metoda vyžaduje odpovídající nastavení serveru, který předá parametry CGI skriptu v proměnné PATH_INFO. Tento způsob nepatří mezi příliš rozšířené, např. v PHP není přímo podporován a je nutné pro práci s PATH_INFO napsat vlastní skript. Nehodí se díky obtížnějšímu převodu na proměnné k přenosu transakčních informací, bývá používán k přenosu identifikátorů: Před názvem dokumentu jako součást cesty výhodou tohoto způsobu je skutečnost, že se nemusí dynamicky generovat odkazy uvnitř dokumentu, jako tomu bylo v případě metod předchozích. Takto předávané informace jsou totiž automaticky součástí cesty ke každému relativně odkazovanému dokumentu. Obtížnější je ale implementace, na serveru je nutný zásah do konfigurace, aby virtuální adresáře nebyly považovány za součást cesty k dokumentu. Proměnná REQUEST_URI obsahuje celou adresu požadavku a z ní je možné přenášené informace extrahovat. Tato metoda je vhodná pro přenos identifikátorů neměnných v průběhu relace. Následující příklady obsahují stavové informace (jméno uživatele ota a identifikátor relace c95c766e8b0 ), aniž by to bylo navenek zřejmé: Strana 22

23 Nastavení Apache Kapitola 2: Stavové informace Server Apache již od verze 1.2 obsahuje modul s názvem mod_rewrite, umožňující různé změny URL 23, jako např. změnu přípony souboru či vložení virtuálních adresářů do cesty. Jde vlastně o přesměrování virtuálních adres na existující soubory (fyzická cesta se v URL nahrazuje virtuální většinou jednodušší, čitelnější a lépe zapamatovatelnou). Tento modul tedy umožňuje také vložení stavových informací do URL jako součást cesty, před názvem dokumentu. Zajímavý je ale také z hlediska dnes aktuálního tématu optimalizace stránek, tzv. SEO (Search Engine Optimization). Lze tak totiž vkládat klíčová slova do URL. Pro zavedení modulu mod_rewrite je nutný zásah do konfiguračního souboru serveru Apache conf/httpd.conf. V tom může být u některých komerčních webhostingů problém, pokud modul není zaveden. Uživatel totiž většinou nemá přístup ke konfiguračnímu souboru a právo jej měnit. Syntaxe vypadá takto: LoadModule rewrite_module modules/mod_rewrite.so AddModule mod_rewrite.c Jednotlivá pravidla pro přesměrování se pak uvádí v souboru.htaccess přímo v adresáři s obsahem webu. K editaci těchto souborů už většinou uživatel právo má, např. pomocí FTP či administrátorského rozhraní zákaznického centra. K správnému nastavení je potřeba znát syntaxi regulárních výrazů, blíže viz [3]. Na příkladu si ukážeme vložení identifikátoru relace do URL, jejíž výsledná podoba má být: Soubor.htaccess v kořenovém adresáři pc/ bude obsahovat tento kód: RewriteEngine On RewriteBase /pc RewriteCond %{REQUEST_URI} /eshop/ RewriteRule eshop/[^/]+/(.*)$ eshop/$1 [L] Tento kód zajišťuje nalezení souboru cart.php v adresářové struktuře webu i přesto, že URL obsahuje identifikátor (virtuální adresář), který by byl jinak brán jako podadresář fyzické struktury. Dojde vlastně k přepsání správnou adresou, přičemž identifikátor z původní URL bude k dispozici v proměnné REQUEST_URI. Hybnou částí kódu je řádek s příkazem RewriteRule, více napoví jeho formalizovaný zápis: RewriteRule <co přepsat> <čím přepsat> [příznaky] $1 značí první regulární výraz v závorkách (v tomto případě jakýkoliv soubor, protože.* značí libovolný počet libovolných znaků), řetězec mezi eshop/ a jménem souboru se tedy z URL vypouští. Příznak [L] značí poslední pravidlo (může jich být více). Podrobné informace o mod_rewrite jsou v dokumentaci Apache [1], v češtině napsal o tomto tématu řadu článků Vojtěch Schlesinger ve svém seriálu [35]. 23 Server Apache má k dispozici ještě další dva moduly s podobnými funkcemi. Jsou to mod_alias a mod_redirect. Ovšem mod_rewrite skýtá nejvíce možností (funkcí). Strana 23

24 2.3.2 Skrytá formulářová pole Kapitola 2: Stavové informace Tento způsob lze uvádět jako odlišný pouze v případě použití metody POST pro odeslání dat z formuláře. Při použití metody GET se totiž formulářová data posílají zakódovaná v URL, což z hlediska zařazení patří do předešlé kategorie. Při použití metody POST jsou data odesílána v zakódované formě v těle požadavku, což má jisté výhody. Hlavní je fakt, že ve většině případů tělo požadavku nebývá zaznamenáváno do logu serverů a také se data odeslaná touto metodou neobjeví v hlavičce Referer ani v historii prohlížeče. Ovšem tato data jsou po síti standardně přenášena v otevřené formě a lze je zachytit, čili tato metoda není zcela bezpečná pro přenos citlivých dat. Nazývat tato formulářová pole skrytá je poněkud zavádějící. Jak již bylo psáno, nemají sice v prohlížeči žádnou grafickou reprezentaci, ale jsou vcelku snadno přístupná komukoliv, stačí si jen zobrazit zdrojový kód stránky, kde již tato pole nijak maskována nejsou. Formulář může obsahovat jak běžná, tak skrytá pole (hidden), které odesílá v požadavku současně. O tom, že tato metoda není příliš výhodná svědčí také fakt, že implementace je v porovnání s ostatními metodami obtížnější. Pro celou oblast webu, kde se má tato metoda použít, je potřeba vytvořit přechody mezi jednotlivými dokumenty pomocí formulářů a jejich odesílacích tlačítek (případně obrázků). Čili je opět nutné dynamicky generovat veškeré odkazy, resp. hodnoty skrytých formulářových polí. Navíc pokud uživatel v prohlížeči zvolí krok Zpět, vždy se zobrazí informační dialog o opětovném odesílání formulářových dat 24. Teoreticky lze tuto metodu použít pro libovolný typ informací, lze pomocí ní posílat větší objem dat, než se vejde do URL (včetně souborů). V praxi se však díky náročné implementaci a nepříliš uspokojivé bezpečnosti používá jen zřídka, a to v případech jednorázového přenosu transakčních informací získaných od uživatele 25. Následuje příklad (úryvek HTML): <form method="post" action="zpracuj.php"> <input type="hidden" name="user" value="ota"> HTTP autentizace Jde o jednoduchý mechanismus zabudovaný přímo v HTTP, umožňující s požadavkem odeslat také informace sloužící pro ověření přístupových práv uživatele k dokumentu. Pokud je autorizace k zpřístupnění dokumentu serverem vyžadována, zašle v odpovědi stavový kód 401 Authorization Required a hlavičku WWW-Authenticate (obsahující mimo jiné typ použité autentizace). HTTP autentizace má dva typy: Basic a Digest, oba jsou popsány ve specifikaci RFC 2617 [28]. Rozdíl mezi nimi spočívá v tom, jestli je jméno (user) a heslo (passw) přenášeno 24 Této nepříjemnosti by se dalo předejít případným přesměrováním po každém požadavku na další stránku, což by bylo jistě velmi komplikované a řekl bych až krkolomné řešení. 25 Po vyplnění formuláře, například při odesílání příspěvku do diskuze. Strana 24

25 Kapitola 2: Stavové informace v nezašifrovaném 26 (Basic), či zašifrovaném tvaru (Digest). Paradoxně se více používá typ Basic, díky jednoduché implementaci a podpoře, přestože je z hlediska bezpečnosti slabší 27. Tato metoda má hned několik nevýhod. Neexistuje jednoduchý způsob, kterým by bylo možno ukončit relaci (odhlásit se). Nelze totiž donutit prohlížeč, aby přestal v požadavcích odesílat autentizační informace 28. Vzniká tak například problém s přihlášením jiného uživatele na stejném prohlížeči. Další komplikací je nutnost mít přidělen identifikátor předem. Tato metoda tedy neumožňuje rozlišení jednotlivých uživatelů ještě před přihlášením 29. Jiným faktem odrazujícím tvůrce webové aplikace od použití této metody může být samotné dialogové okno, jež zobrazuje prohlížeč a není možné ho upravit (graficky sladit s aplikací, jazykově přiblížit uživateli). Z předchozího textu je zřejmé, že tuto metodu je vhodné použít jen pro identifikátory, tj. uživatelské jméno a heslo, a to pouze v případech, kdy jsou tyto údaje uživateli vydány předem. Jedná se o účinný a jednoduchý způsob zamezení přístupu neautorizovaných uživatelů k chráněným dokumentům. Jiné použití této metody naráží na mnoho problémů a je proto nevhodné. HTTP autentizace typu Basic používá například systém pro přístup k síťovým diskům počítačové sítě Vysoké školy ekonomické v Praze, nazvaný NetStorage a přístupný na URL adrese Pro příklad uvádím části požadavků a odpovědí z tohoto serveru při procesu autorizace. Nejprve požadavek s následným vyžádáním autorizace: GET /onenet/netstorage HTTP/1.1 Host: silo.vse.cz... HTTP/1.x 401 Authorization Required Date: Wed, 09 Aug :42:07 GMT Server: Apache/ WWW-Authenticate: Basic realm="cz-vse"... Dále pak úspěšný požadavek po vyplnění jména a hesla: GET /onenet/netstorage HTTP/1.1 Host: silo.vse.cz 26 Data nejsou šifrována, pouze je použito kódování Base Zvláště když otevřené heslo posílá danému serveru s každým požadavkem a tyto údaje se z prohlížeče mažou až po jeho ukončení. 28 Pokud samozřejmě nedojde k ukončení prohlížeče. 29 Tato funkce je potřeba například v systému elektronického obchodu, kde zákazník vybírá zboží a teprve před uskutečněním objednávky použije své identifikační údaje, respektive vyplní jednorázově údaje potřebné pro účel dané transakce. Strana 25