Myšlenky dne otce Fura

Kamarád mi poslal odkaz na zajímavý článek. Jistě všichni znáte ochranu zneužití veřejně dostupných formulářů pomocí CAPTCHA. Koneckonců je většina z nás má na svých blozích po tom, co nám začaly chodit spamové komentáře k článkům. Pánové z Carnegie Mellon University však našli způsob, jak tento otravný fenomén převést na něco, co je užitečné.

(more…)

Jsou chyby malé, velké, závažné i triviální, úsměvné, spletité i velmi hloupé. Z celého pokolení chyb je tahle velmi, velmi stará a také dost hloupá. A vypadá to, že z úcty k jejímu věku, ji nechá M$ už pokojně dožít spolu s chatrčí zvanou Internet Explorer.

Na chybu narazíte tehdy, když coby Java programátor napíšete servlet, který vrací binární data přes protokol HTTPS (např. vygenerovaný MS Excel jako já, nebo třeba PDF atd.). Aniž byste to explicitně nastavili do HttpResponse, bude vrácená odpověď (pravděpodobně) obsahovat v hlavičce tyto údaje:

O to se vám postará váš web server (v mém případě Tomcat i Apache zároveň). Internet Explorer se však k vrácené binární odpovědi s těmito hlavičkami obrátí zády a lakonicky vás informuje: “Aplikace Internet Explorer nemůže otevřít tento server v síti Internet. Požadovaný server není k dispozici nebo jej nelze najít. Akci zopakujte později.”

Tato chybka je dle některých zdrojů v Exploreru už od verze 4.0 (byť záznam v knowledge base Microsoftu tvrdí, je reportovaná až u IE 6.0 SP1) a přetrvává až do současné verze 7.0, což jsem si měl bohužel možnost vyzkoušet na vlastní kůži.

(more…)

Nedávno na jednom připomínkovacím sezení mě zákazník překvapil přáním, že bych chtěl chránit své emailové adresy uvedené v kontaktech jako <a href=”mailto:blabla@blabla.cz”/> proti zneužití spamboty. Jedná se o poměrně jednoduché přání, se kterým jsem se ale ve své praxi setkal poprvé. Obvykle, většina z nás akceptuje toto riziko výměnou za to, že naši zákazníci jednoduše kliknou na odkaz a otevře se jim rovnou jejich mailový klient s předvyplněnou adresou. Ihned nás napadlo vyměnit mailto linky za emaily vepsané např. do obrázku, ale to bychom přišli o tu výhodu jednoduchého otevření mailového klienta s adresou. Nicméně jednání jsme ukončili s vědomím, že si klient bude muset vybrat jedno nebo druhé. Nakonec mi to ale stejně nedalo a zkusil jsem pana gůgla …

(more…)

Je možné zajistit bezpečné sdílení HTTP session mezi oběma protokoly? Z dostupné dokumentace se dozvídáme, že nikoliv. Tento článek se zabývá možným řešením, které za jistých podmínek umožňuje bezpečně sdílet společnou session. Důvod proč se tímto problémem zabývat je jednoduchý – SSL šifrování je výpočetně nákladná věc (viz. např. Performance analysis of Secure HTTP Protocol). Proto je možná vhodné používat HTTPS pouze tam, kde je k tomu důvod (tedy např. uživatel pracuje s některými důvěrnými daty). Jistě se shodneme na tom, že na řadě webových aplikací je takto důvěrných míst pouze pár a zbytek bychom mohli hnát klidně přes protokol HTTP, čímž odlehčíme svému webovému serveru. Jenže tady narážíme na zásadní problém – nemůžeme nechráněným protokolem vyzradit identifikátor session (a naopak nesmíme akceptovat session, která vznikla přes protokol HTTP). Má tedy tato situace řešení, nebo nemá, jak se dočteme v řadě publikací?

Kolega Martin Veska ze společnosti FG Forrest přišel s návrhem řešení, které by umožňovalo bezpečně “vyzradit” identifikátor session, aniž bychom se vystavili riziku záměny autorizovaného uživatele. Jako každé jiné řešení má i toto své mínus, ale o tom až později v článku.