Názory k článku
O obcházení bezpečnostní politiky

Vyborny clanek.

Zrovna pred par dny jsem narazil na "nadherny" odstrasujici priklad - http://adisepo.mfcr.cz/adis/jepo/ramce.htm?P=DNEDP3&S=1 .

I kdyz pominu veci jako ze je to jenom pro IE (i kdyz hlavni aplikace je Java applet), jednou to generuje PDF, podruhe XPS a jine nekonzistentnosti, tak:

1. musite zmenit bezpecnostni politiku IE, nekde se na ty strance lze proklikat k dlouhemu seznamu co je vse potreba nastavit
2. ActiveX - FFFUUU, seriously?
3. i kdyz zakazete ActiveX, hned se to pta na pristup k clipboardu (WTF?)
4. zapis souboru primo na C:\ !!! (cesta je pokud si dobre pamatuju zadratovana natvrdo)
5. certifikat je podepsan od I.CA, coz v principu nevadi, ale lidi, co si dokazou root cert I.CA nainstalovat, je v CR asi pet a pul (BTW taky neni jednoduchy nalezt na strankach I.CA kde jsou root certs, ja jsem je musel vygooglit); o overovani fingerprintu nemluve. (Nutnost pouzit I.CA je dano nejakym uzasnym zakonem.)
6. jestli je v podpisu Java appletu kompletni certificate chain jsem uz ani nezjistoval, protoze nainstalovani root certu do Java keystoru je celkem vyzva i pro programatory (kdyz uz tusi, ze existuje nejaky keystore kam se to ma nainstalovat)

Podival jsem se na certifikaty tych javovych appletu, taky celkem zajimave:

Prvni applet:
- screenshot zobrazeni certifikatu: http://imgur.com/qb6e5.png
- issuer je I.CA

Druhy applet:
- screenshot zobrazeni certifikatu: http://imgur.com/FC3eB.png
- a ted je pro zmenu issuer Verisign (predinstalovany root cert/security token); nenechte se zmast tim, ze v tom treeview to maji zobrazeno obracene
- obchazeni java sandboxu: http://imgur.com/fFQVa

BTW: import do keystore se dela pres "keytool -import", v linuxu je keystore napr. v /opt/sun-jdk-1.6.0.22/jre/lib/­security/cacer­ts (bude asi zaviset od distribuce)

Oprava: keytool -importcert

Nic debilnějšího jsem zatím neviděl, blahopřeju. Takovýmu paskvilu se ani nedá řikat programování, a kdo to dělal a schválil je na hranici idiocie.

Chápu dobče že se to platilo ze státního rozpočtu?

chápete to zcela správně a buďte rád, že nevíte za kolik ...

No, nechci vám do toho rozhořčení moc kecat - ano, bylo to tak (EPO1) a byla to hrůza, nicméně i DPFO je už od loňska v EPO2, kde takovéhle zhovadilosti nejsou a jde to vyplnit třeba ve Firefoxu. Naostro to uvidíme v únoru, až dojde čas na daňové přiznání :-)

Už se na Android objevilo pár kousků SW, který odesílá osobní informace. Co myslíte, bude to stačit, aby si lidé začali prohlížet seznam oprávnění, která aplikaci udělují?

Nebude. Jednoduchy priklad: aplikace pro zalohovani kontaktu a sms, ktera je freeware s reklamami.

V permissions bude mit pristup k telefonnimu seznamu, sms a internetu. Nemuzete vedet, co odesila bez pouziti dedexer-u nebo neceho podobneho.

Podle mě úplně stačí systém hodnocení aplikací, recenze, testy, články, certifikáty... Tak jako všude jinde v běžném životě, kde nemám jistotu, jestli mě v čínské restauraci nepřiotráví, přestože nemají "svobodnou kuchyni". ;-)

Pokud by nastal hon na nesvobodný SW (třeba nějakým blikajícím varováním v marketu), tak by to podle mě v konečném důsledku pro uživatele přínos nebyl - nabídka by se omezila (a tím pádem jiná svoboda - svoboda volby, včetně volby rizika). A naopak, kdo má nekalé úmysly, určitě by se mu podařilo je provést i se svobodným SW.

Já třeba si dávám na takový SW pozor (někdy mi přijde, že některá práva jsou požadována celkem uměle).

Jinak je pravda, že je tu spousta způsobů, jak to udělat relativně nenápadně (např. dvě spolu komunikující aplikace, každá s oprávněním na něco). Ale v této chvíli se o to patrně nesnaží.

Mám rád, když se jde k jádru věci.
Mám rád, když zamyšlení má přesah do více oblastí.

Díky za článek.

Pokud by šla bezpečnostní politika obejít, pak to není bezpečnostní politika, ale jen jakési doporučení. Každý virus by si mohl otevřít firewall, nastavit administrátorská práva, atd.

Obávám se, že ten konkrétní člověk prostě nechtěl "tvořit velké a nové věci", ale spíše problematiku nechápal ;)

nastesti ti uniklo ze clanek je o problematice obecne a konkretni pripad pouziva jako priklad.

Máme:

1. uživatele U
2. stránku S na serveru X, kterou U přímo používá
3. jiný server Y

Před čím vlastně chrání uživatele same origin policy na stránce S? Pokud jde o vstup:

1. Zabraňuje S poslat Y data z formuláře, který U vědomě odeslal? Ne, protože
   1. action může vést kamkoliv (to může ale uživatel v HTML ověřit)
   2. i když je action v pořádku (vede na X), může data z něj X tajně přeposlat Y
2. Zabraňuje S komunikovat s Y bez toho, aby uživatel něco dělal (tj. javascriptem)? Ne, protože formulář se dá odeslat automaticky javascriptem i bez vědomí uživatele.

Takže U nezbývá, než věřit S, že předaná data Y nedává. A to záleží na programátorovi stránky S. Pokud S data práská Y, tak je to proto, že:

1. to programátor tak udělal schválně
2. to programátor tak udělal omylem (neuvědomil si, že tam má bezpečnostní díru)

V každém případě za to může programátor. V případě, že jeho úmysly nejsou čisté, tak same origin policy nepomůže. Tak k čemu to vlastně je? Mělo by to smysl jenom jako pojistka, pro případ, že stránka komunikuje s cizím serverem nechtěně (neošetřená bezpečnostní díra). To by to ale muselo být řešené komplexně, s možností zapnout same origin policy pro jakýkoliv externí obsah včetně např. obrázků (načítáním určitých obrázků se taky dají předat cizímu serveru data).

Stejně mi to připadá jako zbytečnost. Takové rádoby bezpečnostní opatření, které každého jen otravuje a kdo to chce obejít, ten udělá menší nebo větší prasárnu a úspěšně to obejde.

Další nesmyslné omezení:

1. v prohlížeči si můžu normálně uložit stránku na disk, ale výstup javascriptu ne
2. na stránce můžu vybrat soubor a odeslat ho tam, kam stránka určí, ale nemůžu ho předat javascriptu přímo na stránce

Odpovědí na tohle je v HTML5 FileAPI, snad bude v budoucnu dobře podporovaný i zápis, jinak by to bylo na 2 věci.

Myslím, že není problém prohlížeč udělat tak, aby posílal cookies jenom stránce, kterou mám načtenou jako hlavní dokument. Všechno, co nepoužívám přímo já (tedy co není S), se může načítat normálně, akorát bez cookies. Pokud by S potřebovala z nějakého důvodu dostat se k mojemu soukromému obsahu na cizí stránce, tak by měla smůlu, leda že bych jí explicitně předal potřebné cookies. Myslím, že to by bylo smysluplnější zabezpečení než same origin policy - bezpečné a přitom neomezuje v případě, že opravdu chci aby S přistupovala k mojim soukromým datům jinde. A bylo by to systémové řešení.

Trošku se v tom motáte - "prohlížeč" neposílá cookies stránce, ale serveru. Cookies ze serveru A neposílá s požadavky na server B, ale o to vůbec nejde.

Problém totiž není v cookies. Situace: Vlezete na web A, kde je nějaký obsah, a krom něho se do stránky načítají i skripty z domén B, C, D,... (počítadla apod.) Skripty z těchto domén by ve světě bez "same-origin" mohly přistupovat přímo k serveru webu A jako uživatel, přihlášený pod vaším účtem. Nasimulovat třeba smazání účtu, změnu hesla či převod peněz na pozadí pomocí XHR by nebyl žádný problém - "vaše" stránka by "svými" skripty přistupovala k "Vašemu" serveru, žádná cookies nejsou nutná.

Změna hesla (obvykle nutnost znát staré) a převod peněz (často nutnost potvrdit pomocí SMS) není možná ten nejšťastnější příklad, vhodnější by bylo psát o čtení informací (např. všech příchozích e-mailů).

Ony by se i ty akce obvykle zakládaly na čtení informací, protože (snad s výjimkou využití refereru) stejně je potřeba přečíst si anti-CSRF token. (Přesněji řečeno, pokud to potřeba není, tak obvykle same-origin-policy nepomůže, CSRF je možné udělat i tak.)

Ale v zásadě s tímto příspěvkem souhlasím.

Vím, že cookies se posílá na server. Cookies jsem myslel jako cookies konkrétně pro stránku S (ve smyslu výroku "stránka má na vašem počítači uložené cookies" z okna "Informace o stránce" ve Firefoxu). Klidně můžeme uvažovat i platnost cookies pro celý server X, na tom tady nezáleží. Doufám, že si rozumíme.

Problém totiž není v cookies. Situace: Vlezete na web A, kde je nějaký obsah, a krom něho se do stránky načítají i skripty z domén B, C, D,... (počítadla apod.) Skripty z těchto domén by ve světě bez "same-origin" mohly přistupovat přímo k serveru webu A jako uživatel, přihlášený pod vaším účtem.

To je chyba toho, kdo tak web A naprogramoval. Stejně tak může být kvůli chybě programátora web A zranitelný XSS. Načítání cizího skriptu ale IMHO narozdíl od díry pro XSS nejde jen tak omylem spáchat. Pokud je URL konstantní, tak se to stát nemůže; pokud načítám skript z proměnné URL (i to by se mohlo někde hodit, ale na běžné stránce to nebude), do které může zapsat někdo cizí, tak musí URL projít naprosto přísnou validací. Klasika, stejný princip jako obrana proti XSS.

Tyhle věci si prostě programátor síťové aplikace musí uvědomovat. Bez toho se bezpečné webové aplikace dělat nedají. Pokud někdo chce spustit na svojí stránce cizí JS, tak to může i teď: stačí si u sebe na serveru udělat proxy skript, který ten cizí JS načte. Pokud si to nějaká lama ignorující bezpečnost chce na stránku dát, tak může. Same origin policy jen brání tomu udělat to normálně, musí se na to zbytečně využívat server - stejná blbost jako u načítání a ukládání souborů.

Jo, hodila by se možnost jednoduše automaticky ověřit, že na stránce se určité věci, jako spouštění cizího skriptu nebo XSS, nemůže stát. To je záležitost programátora (je protřeba ověřit celou aplikaci, ověření jenom na straně klienta např. pro XSS stačit nebude). To asi jen tak nepůjde, protože dynamické jazyky jako javascript a PHP jsou pokud vím pro formální verifikaci mimořádně nevhodné. V tomhle prostředí si takové věci prostě musí programátor ohlídat. Nesmí být prase.

Možná si úplně nerozumíme. "same origin policy" myslím to, že javascript na stránce nemůže posílat requesty na cizí servery. To je dost zásadní a podle mě zbytečné omezení.

Vy nejspíš myslíte něco jiného: že javascript nesmí mít přístup do jiných stránek, co mám v prohlížeči otevřené. S tím naprosto souhlasím.

Tady nejde o samotné poslání požadavku, ale především o čtení jeho odpovědi. Zkusíte si vypnout SOP a já vám pošlu e-mail, který obsahuje link na stránku, která pošle požadavek na získání kontaktů GMailu a pošle mi je? (Nechci, aby to vyznělo útočně, spíše chci, aby to bylo názorné.) Tady poznáte, proč se SOP sice požadavek poslat mohu (přes form), ale už si nemohu přečíst odpověď (přes XHR nebo přes iframe apod.).

Mimochodem, možnost posílání requestů na cizí servery bez explicitního povolení taky asi nebyla úplně šťastným nápadem, hlacně u metody POST - vizte problematiku CSRF.

Tohle všechno je možné jenom v případě, že se do toho požadavku automaticky vloží moje cookies. Když tam nebudou, tak to bude jako kdyby se na stránku podíval nějaký cizí uživatel - k mojim datům se nedostane. Už jsem o tom psal: http://zdrojak.root.cz/clanky/o-obchazeni-bezpecnostni-politiky/nazory/13828/

To samé CSRF. Když se nepošlou moje cookies, nic se nestane, bude to jako požadavek kteréhokoliv jiného uživatele. CSRF touto cestou nehrozí.

Proti CSRF musí být ochrana na straně napadené stránky. POST jenom vypadá bezpečnější, protože na CSRF nestačí podstrčit uživateli obyčejný odkaz, je potřeba mu podstrčit formulář. Vzhledem k tomu, že na odkaz se dá zavěsit submit() formuláře, tak je to vlastně jedno. POST žádná ochrana proti CSRF není.

Je tu spousta možností, jak to navrhnout, nemůžeme vybrat jedinou správnou, ale můžeme vybrat jedinou, která značí, jak to navrženo bylo.

Neposílat automaticky cookies - pak by to asi problém nebyl, jen nevím, na co by to bylo. BTW Totéž by se muselo udělat i s http autentizací.

Neříkám, že POST formulář je co do CSRF nějak výrazně bezpečnější - sice GET některé útoky zjednodušuje například možností vložit obrázek nebo odkaz přímo na fórum a tím vyřešit i referer, není to to, o čem jsem psal. Narážím na logiku těchto metod - zatímco GET by neměl měnit stav (statistiky nepočítám do stavu) a mělo by to být z hlediska CSRF neškodné, o POST to říct už nelze a může to být problém.

Samozřejmě, je to jen povzdechnutí "kdyby tehdy to udělali jinak", ale po bitvě by každý mohl být generál.

Mimochodem, z tohoto pohledu je lepší si na HTML5 nějakou chvíli ještě počkat, než za pár let naříkat, že to mohli udělat jinak, ale teď to už nemohou změnit.

Když javascript vytvoří cross-site request ( http://www.petefreitag.com/item/703.cfm ), tak tam doufám Firefox moje cookies a autentizace pro ten cizí server do něj nedává. Nezkoušel jsem to, ale snad to tak udělali. To řešení s hlavičkou Access-Control-Allow-Origin: <URL> se mi líbí, nenaruší to stávající zabezpečení.

K čemu by bylo neposílat cookies a autentizaci? No, u cross-site requestů je to nutnost, protože jinak by mi na stránce, kde jsem přihlášený mohla jiná stránka sama něco svým javascriptem provést - přesně to, o čem se tady celou dobu bavíme.

HTML5 by se nemělo uspěchat, s tím souhlasím. Ale je taky potřeba ho důkladně otestovat, právě proto aby pak v něm nebylo něco, co se reálně ukáže jako nevyhovující. Zatím musíme počítat s tím, že se HTML5 bude měnit a ty změny nemusí být zpětně kompatibilní.

U XS requestů to nutnost není, pokud je na to povolující web připraven.

Je to nutnost. Bez ohledu na to, co na jakém webu kdo připravil, já jako uživatel chci mít záruku, že mi jedna stránka nebude svévolně přistupovat k jiné. Možná jsem to nepochopil, co myslíte tím "připravením"?

To už teď nemáte, je to možné obejít přes iframe a hash. Tímto způsobem byste z toho pouze udělal nástroj, který by takovéto iframy nedokázal nahradit plně. Takže pochybuji, že to takto navrhli.

Připravena - počítá s tím, že některé požadavky mohou jít z XS XHR.

Můžu se zeptat, jak to jde obejít? Mně tohle ve Firefoxu ani v Chromiu nefunguje: http://jsdo.it/imploder/QBtW

V Chromiu se vypíše do konzole: Unsafe JavaScript attempt to access frame with URL http://diskuse.jakpsatweb.cz/ from frame with URL http://jsrun.it/imploder/QBtW. Domains, protocols and ports must match.

Takže tímhle jednoduchým způsobem iframe nepřečtu, protože se zjevně i tady dodržuje same origin policy.

Diskutuji o situaci, kdy to stránka svolí, což se ostatně musí stát i u XS XHR. V takovém případě lze prý použít pro komunikaci location.hash iframu. Nezkoušel jsem, ale vím, že to existuje a že na to asi jsou i nějaké knihovny.

Aha, spletl jsem se, Access-Control-Allow-Origin posílá odpověď na požadavek, ne moje stránka. Beru to zpět, nelíbí se mi to. Je to další omezení na divném místě, které budí dojem bezpečnosti, ale bezpečnost (v tomto případě to, že stránka moje data nikomu cizímu nepošle a že od nikoho cizího netahá skripty nebo data) ve skutečnosti nezaručuje (dá se jednuduše obejít proxy skriptem).

Kdybych to měl řešit já, tak povolím stránce posílat přes XHR cokoliv kamkoliv, ale se svými cookies a autentizací, ne s mojimi cookies a autentizací. Aby tím nevznikla díra ve starých stránkách, které spoléhají na to, že pro XHR platí SOP a že teda skript na nich nikomu cizímu request poslat nemůže, by se to muselo něčím (třeba hlavičkou stránky) zapnout. Bezpečnost by nijak neutrpěla (nedovolilo by to nic, co by už teď nešlo, akorát že teď to jde jenom prasácky přes proxy skript) a webové aplikace by se mohly normálně bavit s jinýma a načítat z webu cokoliv. Ještě k tomu přihodit slušnou práci se soubory (ta teď taky vyžaduje krkolomné řešení s využitím serveru) a případně podporu "XHR" v jiných protokolech než HTTP a webové aplikace by mohly začít fungovat víceméně jako normální aplikace a ne jako jakýsi podivný kočkopes.

Nic takového se asi nikdy neuskuteční, ale stejně nám budou vtloukat do hlavy, že webové aplikace jsou plnohodnotnou náhradou desktopových a jak je web super.*

*) Neberte si to prosím nikdo osobně. Cíl tohohle (stěžovatelského) příspěvku není ukazovat na lidi, ale na technologii: že webové aplikace nemůžou a v blízké době ani moct nebudou dělat věci, které normální aplikace zvládá běžná desktopová aplikace je potřebuje.

Už asi chápu, jak to myslíte. Pokud má web, kam request míří, ochranu proti CSRF, tak cookies a autentizace nestačí, je potřeba ještě správný token. To pak jo, je to jako normální CSRF. Jenže: u požadavků neměnících stav (GET) se ochrana proti CSRF obvykle nedělá (musela by být pak na každé soukromé stránce) a v takovém případě by mi mohl cross-site request číst soukromá data. Sice by nemohl nic měnit, ale mohl by číst a to taky není dobré.

Souhlasím, že to není dobré (mimochodem, většinou by pak šlo díky získání CSRF tokenu i měnit data), ale jde tu o situaci, kdy je to explicitně povoleno. Neznám XS XHR podrobně, ale omezení zcela určitě nebude nutné dělat pro větší celek než pro jednu doménu. A když cookies budou pro .www.example.com a API s povoleným XS XHR bude na .api.www.exam­ple.com, pak v tom není problém.

Tak jsem zagooglil a asi jsem trochu zaspal dobu. Cross-domain request už jde, resp. půjde, až to budou všechny prohlížeče podporovat :)
http://www.petefreitag.com/item/703.cfm
http://html5demos.com/postmessage2
Je to něco jiného, než bylo zmíněno v článku (změna rodičovského dokumentu z iframe - to je špatně).

Pokud by se cookies posílaly jen hlavní stránce, tak by to mimo jiné znamenalo, že by Google Analytics a další počítadla nedokázala měřit návštěvy a návštěvníky, ale pouze zobrazení stránky. Obdobný problém by měly reklamní systémy a další legitimně vložené kódy.

Měřiče návštěvnosti jak Google Analytics - to jsou obrázky, případně iframy. Někdy se hodí mít možnost zobrazit (i soukromá) data z cizího webu na stránce, ale tak, že na ně nemůže - např. tlačítka "Like" s fotkou a statistikou z Facebooku atd.. Tady SOP dává smysl - je to prostě jenom kus cizího obsahu, jako by byl v jiném okně, ale zobrazí se pomocí iframu přímo do stránky. Podobně obrázky - je to kus cizího obsahu (může být i soukromý), který stránka může svévolně načíst, ale JS na stránce ho nepřečte (aspoň doufám, SOP by mělo platit logicky i pro obrázky když platí pro iframy - nezkoušel jsem; kdyby ne, byla by to bezpečnostní díra).

SOP jsem kritizoval u jiné věci: XHR (ajax) - tam SOP podle mě vůbec nedává smysl a přesto tam je. Proč nedává smysl: XHR načítá data ze serveru za účelem práce s nimi v JS - to znamená, že nedává smysl XHR použít stejným způsobem, jako iframy a obrázky (tj. načtení cizích, i soukromých dat, bez možnosti přístupu k nim z JS na stránce) - prostě proto, že k čemukoliv načtenému přes XHR javascript prostě bude mít přístup. To znamená, že nesmí jít pomocí XHR načíst soukromá data uživatele z cizího serveru. To je velice důležitá věc a naprosto s ní souhlasím. Taky že to teď nejde (kvůli uplatňování SOP na XHR). Ale nejde ani prostě načíst nějaká data z cizího serveru - a to je kámen úrazu. To by mělo jít, není důvod, aby to nešlo. Takže navrhuju:

Ať XHR funguje i pro cizí servery (jakékoliv), jen s tím rozdílem, že cizímu serveru prohlížeč nepošle automaticky cookies a autentizaci. To by znamenalo, že cizí server nedostane žádné informace identifikující uživatele a JS by vystupoval jako nezávislý uživatel. JS by mohl do XHR požaddavku zahrnout libovolné cookies a autentizaci, ale aby poslal ty uživatelovy, na to by mu je musel uživatel explicitně dát*.

*) Ideální by na takové předání bylo, aby ho prohlížeč nějak podporoval (např. "předat skriptu na stránce X má soukromá data uložená na tomto počítači stránkou Y?" - "ano, předat má soukromá data"/"zrušit"; případně něco ještě polopatičtějšího). Na co se předání hodí: např. pokud chci povolit webové aplikaci vrtat se mi v mém účtu v jiné webové aplikaci - např. import obrázků z fotoalba na jednom serveru do jiného fotoalba na jiném serveru, které z toho prvního podporuje import; nebo nějaká nastavení, zálohování - možnosti by byly široké (stejné jako u běžných desktopových aplikací).

Napadá mě jediný potenciální bezpečnostní problém, pokud by se možnosti XHR takhle rozšířily: pokud u nějakého skriptu je URL proměnná náchylná na XSS a jedině SOP brání tomu, aby se provedl požadavek na podvrženou cizí URL. K tomu se dá zaujmout dva postoje: buď říct, že taková "featura" prostě v JS aplikaci být nemá, nebo se držet striktně toho, že změna nesmí na žádné už existující stránce vytvořit bezpečnostní díru.

Jsem radši spíš pro to druhou, striktní variantu. V tom případě musí se možnost použití XHR na cizí server nějak explicitně zapnout. IMHO nejlepší by byl nějaký nový parametr nebo atribut při vytváření XHR. Protože by to ale změnilo rozhraní XHR, vznikne tak vlastně mírně odlišná třída (v JS teda vlastně prototyp?) XHR. Mohl by pod nějakým novým názvem existovat společně s tím starým, který by se stal "deprecated".

Vidíte v tom nějaké problémy? Pokud jsem někde v těch úvahách neudělal chybu, tak je to IMHO pěkné (a potenciálně velice užitečné) rozšíření funkčnosti XHR bez jakéhokoliv ohrožení bezpečnosti nových i stávajících aplikací. Hodně se mi ten nápad líbí, chtěl bych to navrhnout přímo zodpovědným lidem ve W3C. Nevím, jak moc si do toho nechají kecat, ale tohle by se jim mohlo líbit - nahrazení SOP u XHR něčím lepším a podobně jednoduchým, žádné nevýhody. Pokud k tomu máte připomínky nebo nápady, tak napište, klidně i na mail (petrmej@gmail­.com).

Ještě bych se vrátil k těm iframům a obrázkům: to, že může cizí server sledovat uživatele všech stránek, na kterých se z něj načítá nějaký iframe a může ty uživatele mezi jednotlivými nesouvisejícími weby identifikovat, se ne každému líbí. Uživatel nic netuší a je to v podstatě tolerovaná bezpečnostní díra v návrhu HTML. IMHO by bylo dobře, kdyby se tenhle koncept (SOP) zavrhl. Mohlo by se i u obrázků a iframů používat to, co navrhuju u XHR: těmhle prvkům, pokud jsou na cizím serveru, neposílat automaticky identifikaci uživatele (cookies, autentizace).

Měřáky návštěvnosti a reklamní systémy by pak musely sledování uživatelů řešit jinak než že můžou skrytě sledovat uživatele napříč neomezeným množstvím webů. Jako možnost mě napadá přesunout identifikaci na klientský web - ten bude uchovávat cookie a posílat její hodnotu v GET parametru URL obrázku/iframu z měřicího webu. To jde řešit javascriptem ve vloženém kódu - nic složitého. Tím by se sledoval uživatelv rámci jednoho webu. Případně množiny webů, které by se na tom vzájemně dohodly (sdílely by nějak identifikační cookie - např. novým XHR). Obojí (nastavování, sdílení cookies) by šlo udělat u klientského webu i čistě na straně serveru.

Takže výsledkem by bylo, že klientský web má pod kontrolou, s kým (a jestli vůbec) identifikaci uživatele sdílí. Mohlo by to být v podmínkách např. reklamního systému, takže by se vlastně moc nezměnilo. Rozdíl by byl jenom v tom, že autor klientského webu by o tom rozhodoval. Uznávám, pro uživatele asi žádný přínos. Takže tady dává smysl zůstat u starého SOP. Narozdíl od XHR.

Ale možná bude lepší nechat XHR být, jak je, protože komunikaci s cizími serveru bude možná řešit WebSockets, pokud tam SOP nebude. Ale ozývají se hlasy volající po SOP i tam:

Does WebSocket obey the same origin policy?
The "same origin policy" is one of the cornerstones of web security. Essentially, executable page content can only establish a connection to the server that the user has loaded the page from. Many of the recent security exploits on the web (such as the gmail address book exploit and clickjacking) arise because of subtle breakdowns in same-origin enforcement. It is not clear whether WebSocket is intended to follow the same-origin policy or not (a failure condition when the URL does not refer to the originating host is not documented) but for the safety of the web, we should insist that this policy remain in place.
[ http://java.dzone.com/articles/websocket-neither-web-nor-sock ]

Co na to říct? Věty tohohle typu „The "same origin policy" is one of the cornerstones of web security.“ jenom zatemňují, k čemu SOP vlastně je. Doufám, že o tom bude rozhodovat někdo, kdo o tom přemýšlí. Aby to neskončilo taky tak zbytečně omezené kvůli SOP jako XHR.

To vypadá, jako by ten článek psal někdo, kdo WebSocket viděl z vlaku :)
Protokol samozřejme podporuje SOP, nevynucuje jej (jako XHR level 1), ale umožnujě, v rámci požadavku na server je nutné poslat hlavičku *Origin (obyč, nebo secure verze) s doménou, která, požaduje přístup, server se na základě ní může rozhodnout jak uzná za vhodné. Stejně tak i server odpovídá, kde v odpovědi je zase hlavička *Origin (obyč, nebo secure verze) a prohlížeč v případě, že origin požadavku a odpovědi nesouhlasí, tak spojení ukončí. Tzn. server může ukončit spojení na základě požadavku a i klient může ukončit spojení v např. v případě, že je v odpovědi origin natvrdo a někdo se pokusí připojit z jiné domény.

Nechápu Váš návrh na "vylepšení" XHR. Pokud by šlo v XHR zapnout SOP, tak by ho programátoři zapínali a SOP by přestalo existovat. Je na serveru, zda chce umožnit přístup z cizích domén, toto není na klientovi. A od toho máme na straně serveru Access-Control-Allow-Origin hlavičku.

Je na serveru, zda chce umožnit přístup z cizích domén, toto není na klientovi.

Proč by se vlastně cizí server měl zabývat tím, jestli na něj přistupuje nějaká aplikace přes XHR? On je na internetu veřejně, jakýkoliv normální program s ním může komunikovat jak uzná za vhodné a hlavičku Origin vůbec neposílat nebo do ní dát cokoliv ho napadne. Akorát JS v prohlížeči potřebuje kvůli tomu na cizím serveru takovéhle ptákoviny. K čemu to je? Připadá mi to padlé na hlavu.

<já chci povolit tag blockquote>v prohlížeči si můžu normálně uložit stránku na disk, ale výstup javascriptu ne</já chci povolit tag blockquote>

Nestačí (ve Firefoxu) Ctrl+A → rightclick → View Selection Source → File → Save Page As? Případně rozšíření Web Developer má funkci Zobrazit generovaný zdroj.

Ale k čemu je vlastně dobré uložit si výstup JS?

<taky chci povolit blockquote a taky "b" a "i">Nestačí (ve Firefoxu) Ctrl+A → rightclick → View Selection Source → File → Save Page As? Případně rozšíření Web Developer má funkci Zobrazit generovaný zdroj.</taky chci povolit blockquote a taky "b" a "i">

Ne, změny v DOM se v kódu neprojeví a v normálně uložené stránce nebudou. Určitě by to šlo přes nějaké rozšíření prohlížeče (jako říkáš to "Zobrazit generovaný zdroj"). Tohle ale po uživateli nemůže webová aplikace chtít. Mně jde o to, že to nejde nijak normálně, v obyčejném, standardním prohlížeči.

Ale k čemu je vlastně dobré uložit si výstup JS?

Je to potřeba v jakékoliv JS aplikaci, která by chtěla fungovat jako typická desktopová aplikace: načítat uživatelovy soubory, pracovat s nima, ukládat je. Ukázka takové webové aplikace:

http://awkwords.wsr3.net

Načítání a ukládání souborů tam řeším nesmyslným kolečkem přes server, protože to jinak nejde. Novou verzi bych rád udělal čistě v JS, tak, že by se aplikace vlastně jenom zavedla ze serveru a dál ho nepotřebovala. Protože on tam server ve skutečnosti na nic jiného není potřeba. Ale nejde to, v současné době si prostě webové aplikace musí dělat ze serveru poskoka a nesmyslně tahat data sem a tam. Dokud se tohle nespraví, tak prostě webové aplikace nebudou plnohodnotnou náhradou desktopových. Jo, šlo by tam dát java aplet, šlo by tam dát flash, ale s obyčejným HTML + JS + serverovými skripty (= standardní webová aplikace) to prostě nejde. Pokud má být web aplikační platformou budoucnosti, tak programování takové základní funkcionality nesmí být jako drbání se levou nohou za pravým uchem.

To uloženie DOM snáď nesúvisí s bezbečnosťou. V IE to neni problém, aj keď to nie je na prvý pohľad jasné, ako to urobiť (F12,Ctrl+S). Firefox už nemám, takže to neviem skúsiť, ale myslím že sa to dalo aj tam, ale bolo treba použiť firebug.

Jeden příklad využití - rozšířený OpenWysiwyg. Zde je potřeba při aspoň trochu rozumném rozhraní nějak poslat serveru data z formuláře a zároveň stránku neznovunačítat. Jedno řešení je DOM Iframe(1x1) a do něj vložený a odeslaný stejný formulář. Problém nastává ve chvíli, kdy má dojít k předání dat z rámu. Zde se chodí skrz adoptChild, neboť jiné přístupy se zasekávají právě na bezpečnostní politice.
Další příklad z OpenWysiwyg - vyskakovací okna (díky staršímu založení). Opět je tu problém s přístupem k rodičovskému oknu, protože vyskakovací se chová jako samostatný rám. V budoucnu z toho bude podstatný problém.

Víte, není to jen o bezpečnostních politikách implementovaných do serveru. Je to i o jiných politikách, které nás nutí ostatní nedodržovat, protože jim to ulehčuje život. Řeknete si, vždyť jsou zákony, ale stejně je nedodržujeme (jezdíme rychle, nedodržujeme jiná dopravní pravidla), nedodržujeme pravidla bezpečnosti práce nedodržujeme ......
Tisíckrát se nic nestane a všechno projde a po tisící a prvé "zařve člověk". Pak se řeší: kdo to zavinil?
Pravidla jsou od toho aby se dodržovala. A to i ta, která nejsou v zákoně. Lidé, kteří tato pravidla vytváří si nedělají dobře tím, že je vytváří. Dělají to proto, aby něčemu zabránili. Jen se vždycky najde někdo, kdo v důsledku své neznalosti poruší, co se porušit dá. A pak se diví.

Pravidla prave ze nejsou od toho aby se dodrzovala, pokud mi pripadaji hloupa.
Plati to od bezpecnostni politiky pres rychlost na silnicich az po pravidlo chuze v pravo.
Vetsina inteligentnich lidi se pred uplatnenim pravidla na svoje chovani zamysli a vyhodnoti, zda je v tomto okamziku nutne dodrzet jista konkretni pravidla pro tento okamzik/cinnost a potom kona.
Hloupi lide berou pravidla jako certifikat se zarukou bezpeci, coz je samozrejme omyl a potom mame podobnych lidi plne nemocnice a hrbitovy.

Ohledne tech zakonu, staci jmenovat Nemecko, Kambodzu, Rusko a dalsi zeme, kde se rozhodli ze pravidla musi byt a vyzadovali jejich dodrzovani, rekl bych ze tamni obyvatele meli na dodrzovani pravidel jiny nazor, do te doby nez byli odeslani do gulagu, vyleteli kominem nebo je zaorali do pole.

Jedno omezení (ani nevím, jestli je bezpečnostní nebo jestli se to zatím nikomu nechtělo udělat) je nemožnost po explicitní akci uživatele (tedy např. po kliknutí) pracovat se schránkou. Obchází se to Flashem, což má ale ten neblahý důsledek, že stránka ztratí focus, takže ji třeba nejde zavřít pomocí Ctrl+W/Ctrl+F4.