Přejít k navigační liště

Zdroják » Různé » O obcházení bezpečnostní politiky

O obcházení bezpečnostní politiky

Články Různé

K čemu vlastně máme všechny ty bezpečnostní politiky v prohlížečích? Vždyť jen brzdí kreativitu a nutí vývojáře vymýšlet obezličky a hacky, kterými je více či méně důmyslně obejít… Mají smysl, nebo byste taky všechny tyhle bezpečnostní opatření, které každého jen obtěžují, zakázali?

Včera jsem přednášel studentům o HTML5 a po přednášce, v diskusní části, jsem dostal od jednoho studenta dotaz, se kterým jsem si, upřímně řečeno, nevěděl moc rady. Ten dotaz zněl bezelstně a upřímně:

„Já při tvorbě občas narážím na bezpečnostní politiky v prohlížečích, které mi neumožňují dělat to či ono, například nemohu ze skriptu v iframe měnit obsah rodičovské stránky. Nevíte, jak si může vývojář tyhlety pravidla vypnout, povolit, obejít…?“

Studentovi jsem odpověděl, ale později cestou domů jsem nad tou otázkou přemýšlel a díval jsem se na ni z více stran. Ona totiž není tak jednoznačná, jak by se na první pohled zdálo.

Odpověděl jsem upřímně, že nejsem znalec prohlížečů a že je hypoteticky možné, že v nějakém existuje nějaké nastavení, které potlačí třeba kontrolu same origin, ale po pravdě řečeno jsem se po téhle možnosti nikdy nepídil. Pokud jsem na podobný problém narazil v praxi, snažil jsem se ho vždy vyřešit nějakým legitimním způsobem.

Ale ta otázka mě zaujala, takže jsem tazateli položil protiotázku: Proč byste to chtěl dělat, a proč zrovna takhle? To by si každý, kdo na takovou stránku přijde, musel vypnout bezpečnostní zásady v prohlížeči, aby mu fungovala tak jako vám?


kodakgold

Považuji totiž takový přístup za nebezpečný. Nutit uživatele, aby si vypnul bezpečnostní mechanismy, je nejrychlejší cesta do pekel. Vybavil jsem si případ firmy, kde jsem kdysi pracoval. Její ředitel byl proslulý tím, že rád chodil na stránky, řekněme, hambatého charakteru, a pravidelně jednou do měsíce přišel a říkal: „Kluci, ten notebook mi nějak nejede, je to pomalý, asi to bude potřeba přeinstalovat nebo přidat paměť…“ Když notebook přinesl, stačilo na něj pustit antivir, vyházet zhruba 30–40 kousků, kterými si zasvinil systém, a stroj běhal jako znovuzrozený.

Po několika měsíčních cyklech nás to přestalo bavit, a nainstalovali jsme firewall. Ředitel dostal velmi přísné instrukce („Když se to bude ptát zničeho nic, jestli nějaký program, co jste nespouštěl, smí přistoupit na web, dejte NE“) a pro jistotu jsme nastavení zaheslovali. Po pár týdnech přišel kolega v pondělí do práce skleslý a vyprávěl, jak mu ředitel v noci v sobotu telefonoval, že to heslo chce a že to chce vypnout, protože se nemůže dostat na stránky obchodního partnera, kterému chce zpracovat nabídku…

Za pár dní byl notebook zase pomalý… Ptali jsme se ředitele, jak se to, u všech všudy, mohlo stát. No a on odpověděl, že vlezl na ty stránky obchodního partnera, ale tam mu to nic nedělalo, nechtělo ho to pustit dál a furt se to ptalo, jestli smí program XYZ přistupovat k webu. On poctivě mačkal NE, ale furt ho to tam nechtělo pustit. Tak nakonec dal ANO, a pak se teprve dostal dál a mohl pokračovat, dodělat tu nabídku a zachránit firmu.

Od té doby jsem přesvědčen, že by uživatelé nejen neměli mít možnost měnit bezpečnostní nastavení, ale někteří by ani neměli vědět, že tam nějaká jsou. Ideální bezpečnostní politika je taková, o níž běžný uživatel ani neví, kterou musí znát jen vývojář a musí vědět, jak se jí vyhnout.

Teď to vypadá, že si protiřečím, ale není tomu tak. Obejít bezpečnostní politiku je výzva, která nutí vývojáře k zamyšlení: Opravdu to, co řeším, lze řešit tak, že poruším politiku a obejdu ji? V čem mi ta politika brání a proč?

Studentovi jsem nakonec řekl, že mi to nepřipadá jako dobrý nápad, ani pro nějaké uzavřené prostředí „opravdu zodpovědných lidí“, a už vůbec nemyslím, že je dobré řešit problémy s bezpečností vypínáním bezpečnostních kontrol. A to platí nejen v IT.

Kdysi na střední škole jsme chodili na brigády do blízkého polygrafického závodu, kde dělníci pracovali na řezačkách. Do řezačky dělník zasune štos listů, ten si stroj přimáčkne a na pokyn obsluhy je seřízne silným a ostrým nožem. Kvůli bezpečnosti se spouštěl nůž současným stisknutím dvou tlačítek na přední straně stroje, které byly umístěné tak, že je obsluha musela zmáčknout oběma rukama – což zabraňovalo tomu, že by se stroj spustil a dělník měl jednu ruku někde v prostoru stroje. Dělníci ovšem sami sebe považovali za fachmany, odborníky, staré zkušené ostřílené borce, a na tyhle „inžinýrský vymyšlenosti“ nadávali kudy chodili. Že je to zdržuje, že by druhou rukou mohli hned za nožem přidržovat ten štos odřezků a dávat je pryč. Vyřešili to nakonec tím, že jedno z tlačítek zablokovali pomocí kusu složeného papíru v pozici „zapnuto“, a ovládali vše jen jedním. Důsledky si dovedete představit. (Nakonec vše vyřešila světelná závora – ale na jak dlouho, to netuším.)

I mezi uživateli prohlížečů je velká spousta fachmanů, odborníků a starých zkušených ostřílených borců, které bezpečnost jen otravuje, takových, kteří by i na otázku „Smí tato stránka přistoupit k vašemu disku a stáhnout si z něj, co chce?“ odpověděli ANO. Někteří kvůli těm slečnám, jiní kvůli principiálnímu odporu k zákazu.

Ale nic není černobílé a ve vlaku začal hlodat červík pochyb.

Jsme obklopeni zákazy, které mnohdy nedávají na první pohled smysl. A nutno přiznat, že jej leckdy opravdu nemají. Spousta lidí, a v ČR to je téměř národní sport, zkrátka zákazy, které nedávají smysl, ignorují. Problém je, že jejich smysl posuzují oni sami a většinou na základě své situace. Málokdo se nad zákazem zamyslí v obecné rovině (a to platí i pro zakazující); málokdo vnímá zákaz jako výraz svobody („mohu dělat všechno to ostatní!“), častěji se s ním setkáváme ve chvíli, kdy nám v něčem brání.

advocatus diaboli pokračoval: Vždyť přeci spousta novinek a revolučních věcí vznikla právě v místech, kde někdo odvážný překročil pravidla. Odvážil se jít proti pravidlům a rozbořit je zvenčí. Posunout vývoj dopředu… Francouzští kubisté vzali tehdejší pravidla malby a popřeli téměř každé, na které přišli. Kulturní vzedmutí 60. let bylo na revoltě a popření pravidel založené… Co když díky možnosti obejít bezpečnostní politiku právě tenhle student objeví něco, nějakou zajímavou techniku, postup, něco, co se bude za dva roky nazývat šílenstvím a za pět let průmyslovým standardem? Není to spíš ukázka svobodomyslného přístupu k tvorbě, přístupu nesvázaného bezpečnostními politikami a omezeními, které se leckdy v zápalu tvůrčího rozmachu zdají naprosto hloupé („Vždyť by přece stačilo, aby tohle šlo vypnout…“)

Jenže je tu jedno jenže. K tomu, aby výrazný a svobodomyslný jedinec mohl ignorovat bezpečnostní pravidlo, smysluplně pak využít možností, které dosud nebyly možné, a přesvědčit zbytek světa, že výhody převažují nad riziky, je potřeba, aby nejprve pochopil důvody, principy a důsledky onoho zákazu. Aby věděl nejen jak jej obejít, ale i kdy jej obejít a hlavně proč. A aby dokázal, že odvolání zákazu má smysl. Experimentátoři s formou neexperimentovali proto, že ji nezvládali – zvládali ji tak dobře, že se jejich ničení proměnilo v tvorbu.

Upřímně řečeno nevím, jestli tazatel patřil do této kategorie, a v malém koutku duše doufám, že ano, a opravdu mu přeju, aby pomocí obejití zákazu objevil nějakou skvělou netušenou možnost. Ovšem obávám se, že u většinu webdesignérů je podobná snaha výrazem nedostatečných znalostí: „Nejde to tak, jak chci já, takže musíme změnit pravidla, protože mě nenapadá jiný způsob.


mzacha

Bezpečnostní politiky mají i pro vývojáře ten pozitivní vliv, že si při jejich obcházení často uvědomí, že by šlo vše řešit jinak, transparentněji, elegantněji, ne balancováním na hraně možného. Mnoho článků, které přinesly poměrně zásadní webkodérské novinky, začíná variantou na „řešil jsem problém, jak překonat to a to omezení, a nakonec jsem přišel na úplně jiné řešení…

Ale na druhou stranu, opět našeptával čertík, vždyť i ta slavná same origin policy je vlastně taky prolomená. Hacky na její obcházení jsou známé a dnes už existují legální způsoby, jak ji obcházet (CORS). Jenže ji neobcházejí vypnutím bezpečnostní politiky, ale jejím, řekněme, zpřesněním, kdy za určitých specifikovaných podmínek nemusí platit.

Nevím, možná i na počátku CORS stál student, který se ptal „… jak v prohlížeči vývojář vypne same origin policy?

Nakonec jsem studentovi doporučil, že pravděpodobně nejjistější způsob, jak takový prohlížeč pro vědecké účely sestrojit, je vytvořit si svůj vlastni Chrome nebo Firefox, přeložit si jejich zdrojové kódy a zablokovat v nich kontrolu těchto bezpečnostních opatření. Ale pokud bude chtít někdy vytvářet webové stránky pro lidi, měl by mít takový prohlížeč, který budou mít jeho klienti.

A tahle zásada je pravděpodobně nejdůležitější: Vyvíjejte pro standardní nástroje a dbejte toho, aby i vaše řešení používalo standardní metody. Snažte se pochopit důvod bezpečnostních omezení a záměr jejich autorů. Snažte se je nikoli obcházet, ale stavět svoje dílo tak, aby na ně nenaráželo. A pokud je nakonec přeci jen obejdete či odstraníte, dvakrát přemýšlejte, jestli jste náhodou nepustili šídlo z pytle…

Co myslíte, jsou bezpečnostní politiky užitečné, potřebné a měly by zůstat i pro vývojáře, nebo by měli mít vývojáři nástroj bez těchto omezení, aby si mohli rychleji otestovat to co potřebují a nakonec omezení nějak obejít? Nebo je to špatná cesta a vznikly by tak paskvily, plné záplat a hacků? 

Ilustrační foto: sxc.hu

Komentáře

Subscribe
Upozornit na
guest
49 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
limit_false

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)
limit_false

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)

limit_false

Oprava: keytool -importcert

já

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.

anonym

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

NobodyWasHere

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

BobTheBuilder

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í :-)

v6ak

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í?

limit_false

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.

František Kučera

→ nepoužívat nesvobodný software
(a komu není rady, tomu není pomoci)

pas

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.

v6ak

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ží.

Mintaka

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.

Radek Hulán

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 ;)

Oldis

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

imploder

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.

Jiří Kosek

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

Předtím, aby stránka S získala přístup a data ze všech webových aplikací na jiných doménách než je S, ke kterým se uživatel během používání prohlížeče přihlásil.

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.

Zbytečnost to není. Bez Same Origin Policy by se web používal jen pro publikování veřejně přístupných statických stránek. Na interaktivní aplikace, kam se uživatel přihlašuje, byste mohl rovnou zapomenout.

imploder

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

v6ak

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.

imploder

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.

Jiří Kosek

Myslím, že pořád nechápete, proti čemu SOP (Same Origin Policy) chrání. Jde o ochranu uživatele — programátora to před ničím nemá a ani nemůže chránit.

Kdyby nebyl SOP, je možné toto:

1. Uživatel se přihlásí k nějaké službě S (webový mail, facebook, …)

2. Uživatel pak jde na stránku X, která má nekalé účely

3. Stránka X čte libovolné údaje z S, protože bez SOP ji nic nebrání v přístupu k údajům na S, které jsou normálně dostupné jen po autorizaci uživatele

Před takovými X stránkami je potřeba uživatele chránit, protože uživatel nemuže dopředu vědět, zda stránka X je hodná nebo zlá.

imploder

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.

v6ak

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.

imploder

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

v6ak

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.

imploder

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

v6ak

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

imploder

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“?

v6ak

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.

imploder

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.

v6ak

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.

imploder

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.

imploder

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

v6ak

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.

imploder

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ě).

Jakub Vrána

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.

imploder

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.

imploder

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.

bauglir

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.

bauglir

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.

imploder

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.

Jenda

<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?

imploder

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

Rado2

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.

mmad

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(1×1) 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.

hloupý Nemouš

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

budulinek

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.

Jakub Vrána

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.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.