Vlákno názorů k článku
Co je Cross-Site Request Forgery a jak se mu bránit

Tajná hodnota ve formuláři nebude fungovat proti dalšímu útoku --- útočník si na své stránce zobrazí jako iframe stránku ze serveru, na kterém chce uživateli ukrást účet, přičemž většinu toho iframe něčím překryje. Napíše tam třeba text "click here to see free porn =>", uživatel do toho klikne, a přitom kliknul do iframe na serveru, na který je přihlášený, do tlačítka, které udělá v jeho účtu nějakou akci. Tajná hodnota ve formuláři bude v tomto případě submitnuta správně.

Tento útok je trochu slabší než CSRF, protože takhle nejdou vkládat automatem položky do formuláře, jde pouze simulovat kliknutí. Ale dá se takhle např. i změnit heslo, stačí, když útočník na své stránce dá do iframe stránku na změnu hesla, přičemž texty překryje něčím, co se tváří jako captcha a přiměje uživatele, aby opsal obsah obrázku do políčka a kliknul na submit.

Správné řešení na obranu je nepoužívat cookies vůbec a autentizační hash vkládat do URL. Aby URL bylo pokaždé jiné a nikdo ho nemohl uhodnout.

Takovému útoku se říká clickjacking a asi nejsnazším způsobem (a podle mne lepším než vzdát se cookies), jak mu předejít, je zakázat vkládání své aplikace do iframe (lze vyřešit JavaScriptem).

Chránit se před málo rozšířeným a slabým útokem (clickjacking) tím, že povolím rozšířené a silné útoky (javascript - skoro všechny útoky na browsery potřebují zapnutý javascript) mi přijde poněkud protismyslné.

Pozor na míchání jablek a hrušek, ochrana webové aplikace a ochrana uživatelova prohlížeče jsou nezávislé kroky a každý z nich řeší někdo jiný. Webovou aplikaci si chrání vývojář (obrana před clickjackignem hlídáním paren frame pomocí JavaScriptu je jednoduchá a celkem rozumná cesta), prohlížeč si chrání až uživatel.

Jenže to nejsou hrušky a jablka, ale vzájemně to spolu souvisí.

Dáváte vývojáři na výběr vlastně jedinou možnou obranu: javascript, který zabrání zobrazení jeho stránky v IFRAME jiného webu. Čili v nejlepším případě přenášíte hrozbu ze sebe na svého uživatele (pokud bude ochrana před CJ účinná, bude vyžadovat zapnutý JS u uživatele a tím ho vystavovat riziku; spíš ta ochrana účinná nebude a přesto vystaví uživatele riziku, takže teď budete ohroženi oba). Mě to úplně v pořádku nepřipadá.

Problém je, že neplatí "spíš ta ochrana účinná nebude". Ona skutečně zafunguje (způsob, jak obejít kontrolu vložení stránky do iframu pokud vím nikdy nikdo nevymyslel). Ale je pravda, že to cca procento uživatelů, které si JavaScript vypne, v tomto případě chráněné nebude. Tady hodně záleží na naší aplikaci - pokud JavaScript vyžaduje sama o sobě (což u webových aplikací není neobvyklé), pak bude tato nepokrytá skupina nulová.

S tou neúčinností jste mě nepochopil; moje chyba, měl jsem to napsat výslovně.

Problém je v tom, že aby ta kontrola před vložením stránky do IFRAME fungovala, tak:

1) Musí být v browseru povolen javascript obecně, což není v zájmu uživatele. Fakticky to znamená, že ta stránka musí být napsaná tak, aby bez javascriptu vůbec nefungovala.

2) Musí browser dovolit změnu Location (což myslím zatím žádný browser nezakazuje, ale dost dobře se na to nemůžete spolehnout už proto, že to může zablokovat třeba nějaká nadstavba).

Osobně si hlavně myslím, že clickjacking je hrubá chyba tvůrců browseru. Co já vím, tak jsou principielně dva způsoby, jak to funguje, a obě by měly být vyloučeny "by design":

1) Útočník překryje ovládací prvek cizího webu svým prvkem a nějak dosáhne toho, že browser kliknutí na útočníkův element přepošle jako kliknutí i na element oběti. To se podle mě nedá označit jinak než za hrubou chybu browseru.

2) Útočník upraví element oběti tak, aby pro uživatele vypadal neškodně a současně lákavě, aby na něj klikl (třeba z input type=submit udělá input type=image s obrázkem imitujícím zajímavý link). Pak jde ovšem o klasický cross site scripting, který by prohlížeč také neměl povolit - nebo se aspoň zeptat, jestli to je OK.

clickjacking je hrubá chyba tvůrců browseru

Není. Když by byla chyba na straně prohlížečů, bylo by to dobré a šlo by to vyřešit na úrovni prohlížečů (čili relativně rychle). Clickjacking se ale bude muset řešit (a začal řešit) na úrovni standardů. Je to podobné jako s css exploitem - prohlížeče se chovají správně, byť výsledek je pro uživatele nešťastný - a ťeď babo raď, jak z toho ven.

Není?

Takže podle vás je v pořádku, když browser při kliknutí na element X pošle kliknutí elementu Y? Je v pořádku, když skript ze stránky X může ovlivnit obsah stránky Y?

Jak z toho ven je celkem triviální:

1) Výrobce browseru upraví svůj produkt tak, aby se kliknutí na prvek X skutečně poslalo jen prvku X.

2) Výrobce browseru upraví svůj produkt tak, aby skript ze stránky X mohl upravovat jedině stránky ze stejné domény.

3) Aby nedošlo k rozbití webů, které jsou (nesmyslně a hloupě) rozhozeny do několika domén s tím, že je vyžadováno mezidoménové skriptování, zavede se buď nějaký standardizovaný META (kterým stránka X řekne prohlížeči, "souhlasím, aby můj obsah měnily skripty s URL odpovídající regularnímu výrazu R") nebo si browser povede uživatelsky definovatelný seznam "povolených cross-scriptů" (tak, jako si dnes browsery vedou seznam povolených cookies nebo seznam povolených popupů). To první je lepší a univerzální, ale nejspíš reálně neprosaditelné, to druhé se může zavést okamžitě.

Myslím, že tyhle předpoklady jsou nesprávné (proto nelze hodnotit ani jejich závěry).

Takže podle vás je v pořádku, když browser při kliknutí na element X pošle kliknutí elementu Y?

Můžu vidět nějaký příklad, které tohle skutečně dělá? Clickjacking útoky, které znám, jsou totiž založeny na tom, že uživatel skutečně klikne přímo na element Y.

Je v pořádku, když skript ze stránky X může ovlivnit obsah stránky Y?

Opět bych požádal o příklad, abych se omylem nebavili o něčem, co možná vůbec neexistuje 8-)

Událost kliknutí je v současnosti definovaná tak, že informaci o kliknutí pošle všem elementům, které se na dané pozici nacházejí (dokud někdo z nich nezapne event.cancelBubble). Takže pokud mám div a uvnitř něj span, dostanou informaci oba. To nelze změnit, jinak by přestala fungovat spousta současných aplikací.

Clickjacking navíc může být důmyslnější - zakryje se vše kromě malého místečka cílové stránky a uživatel je motivován k tomu, aby kliknul právě na toto místo (např. formou hry). Uživatel pak skutečně kliká do cílové stránky, takže by navrhovaná opatření nepomohla.

Jediným řešením by bylo zcela zakázat klikání do rámů, to by ale zase ovlivnilo současné aplikace (i když by jich asi zase tak moc nebylo).

Jediným řešením by bylo zcela zakázat klikání do rámů

Jediné systematické řešení, které zatím bylo navrženo, je Jakube zakázání vkládání aplikací ho iframe. Ať již na úrovní HTML hlavičky nebo HTTP protokolu. Jiné řešení zřejmě neexistuje. Pokud by tě navržené řešení a diskuse okolo něj zajímala detailně, podívej se na http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/thread.html#16284.

Pokud to projde, tak si prostě většina aplikací (kromě těch, které chtějí fungovat i jako gadgety) přidá tuhle hlavičku, počká se na nové verze prohlížečů a bude vystaráno. Do té doby nezbývá, než se vložení do iframe bránit JavaScriptem.

Přesněji řečeno, systematické by bylo _povolovat_ vkládání aplikace do IFRAME (ať už na úrovni HTML nebo HTTP, nebo možná vůbec nejlépe na úrovni nastavení prohlížeče): V bezpečnostních otázkách je zcela nezbytné používat whitelisty, nikoliv blacklisty.

Jenže tu máme něco přes 10 let historie. Takové rozhodnutí je z důvodů zpětné kompatibility nereálné.

Holt si musíme vybrat, jestli chceme řešení reálné a nefunkční nebo řešení nereálné ale funkční. Případně nemusíme mít řešení žádné, to je taky možnost.

A teď vážně: Ne, zpětné kompatibility bych se nebál. Whitelist tohoto typu by negativně postihl pouze stránky, které legitimně používají IFRAME z cizí domény. Nejsem přesvědčen o tom, že je jich tolik, aby stálo za to je zohledňovat. Snad některé reklamní systémy, možná nějaké špatně napsané Youtube klony. To je myslím tak zhruba všechno.

To správné řešení ale nic neřeší. Pokud se k té správné URL dokáže proklikat člověk, není moc důvod, proč by se tam nemohl proklikat i robot zobrazující ten IFRAME.

Problém je úplně jednoduchý: Tohle řeší případ, kdy uživatel není na cílovém webu přihlášen. Jenže v takovém případě není clickjacking nebezpečný, protože nepřihlášený uživatel by na tom cílovém webu neměl mít právo udělat nic nebezpečného. Clickjacking je hrozbou pro případy, kdy je uživatel na cílovém webu přihlášen a kdy má práva větší. Jenže když je uživatel přihlášen, tak proběhlo to vaše vygenerování náhodného kódu, jeho zápis do DB a jeho vložení do všech potenciálně nebezpečných URL. Takže stačí zobrazit do IFRAME hlavní stránku cílového webu a provést clickjack, kterým se uživatel přesune na cílové URL (teď už unikátní). Druhý clickjack pak provede žádanou akci. Clickjackující útočník vůbec nepotřebuje to unikátní ID znát, stačí mu, že ho zná ten uživatel, respektive že server si ho použije sám na základě vědomí, že s ním pracuje ten uživatel!

Jo, tohle by šlo v případě, že má uživatel zapnuto automatické vyplňování hesel. Takže ještě by server musel vypnout toto, čímž by zase uživateli znepříjemnil přihlášení.

Automatické (ani jakékoliv jiné) vyplňování hesel s tím nemá vůbec nic společného. Kromě toho to server nemůže nijak ovlivnit, i kdyby chtěl.

Prostě si představte, že jste přihlášený do Googlu na svůj Gmail účet. No a teď vás nějaká stránka přesvědčí, že ve své poštovní schránce máte kliknout na "delete all", a v zápětí vás přesvědčí, že máte kliknout na "yes, really". Google může mít zabezpečení jaké chce, pokud jste do něj přihlášen a útočící stránce se podaří vás přesvědčit, ať na ty linky kliknete, tak prostě nemůže nijak zabránit tomu, abyste si svou poštu nesmazal.

A o tom právě je celý clickjacking: že existuje způsob, jak uživatele přesvědčit, aby udělal akci, kterou by normálně vůbec neudělal. Nemá to celkem nic společného se zabezpečením napadávaného webu, který tomu dost dobře nemůže zabránit.

Nemá to celkem nic společného se zabezpečením napadávaného webu, který tomu dost dobře nemůže zabránit.

Až na tu javascriptovou kontrolu na vložení do iframe, která je celkem spolehlivá 8-)

Ano, za cenu toho, že riziko přesune na uživatele.

Plus si nejsem až tak 100% jistý, že jediným způsobem, jak použít clickjacking, je IFRAME. Předpokládám, že přinejmenším přes OBJECT by to mělo jít taky, a nebyl bych až tak moc překvapen, kdyby se clickjackovací funkce objevily i pro samostatná okna (přes window.open si otevřít nové okno, šikovně ho namaskovat a nechat uživatele, ať si do toho klikne).

V okamžiku, kdy je to URL, které zobrazí tlačítko "delete email", tajné --- t.j. v tom URL je obsažen tajný hash, tak tě žádný útočník nemůže přesvědčit, abys na to kliknul --- když útočník nezná URL, na které se v tom iframe má odkázat, tak ten iframe nevyrobí.

Šlo by to tak, že ti útočník zobrazí titulní stránku a donutí tě kliknout na "login" (a předpokládá, že máš zaplé samovyplňování hesla) a pak na "delete email".