Názory 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".

Páni poslanci už přeci otázku CSRF, XSS a vůbec všeho vyřešili v návrhu nového trestního zakoníku za nás... ;-)

§ 228:
(1) Kdo překoná bezpečnostní opatření, a tím neoprávněně získá přístup k počítačovému systému nebo k jeho části, bude potrestán odnětím svobody až na jeden rok, zákazem činnosti nebo propadnutím věci nebo jiné majetkové hodnoty. ...

§ 229
(1) Kdo v úmyslu spáchat ... trestný čin neoprávněného přístupu k počítačovému systému a nosiči informací podle § 228 ... vyrobí, uvede do oběhu, doveze, vyveze, proveze, nabízí, zprostředkuje, prodá nebo jinak zpřístupní, sobě nebo jinému opatří nebo přechovává
a. ... postup, nástroj nebo jakýkoli jiný prostředek, včetně počítačového programu, vytvořený nebo přizpůsobený k neoprávněnému přístupu do sítě elektronických komunikací, k počítačovému systému nebo k jeho části, nebo
b.počítačové heslo, přístupový kód, data, postup nebo jakýkoli jiný podobný prostředek, pomocí něhož lze získat přístup k počítačového systému nebo jeho části,
bude potrestán odnětím svobody až na jeden rok, propadnutím věci nebo jiné majetkové hodnoty nebo zákazem činnosti.

-> takže autor článku rok natvrdo ("vytvoření trvalého platebního příkazu na útočníkův bankovní účet", "příklad bude destruktivní", odkaz na wireshark => úmysl je zde celkem zřejmý), my ostatní, co to čteme, bysme mohli vyváznout jen s podmínkou... ;-)

Já vím, ironie, nadsázka a tak vůbec, ale nedá mi to a demonstruju na tom častou chybu podobných právních výkladů. Totiž zákon praví: "Kdo v úmyslu spáchat to a to udělá to či ono" - a tady narážíte, protože autorovi neprokážete úmysl spáchat podobné činy. :)

Přesně tak: ironie, nadsázka a tak vůbec (pochopeno správně)
Nicméně je dobré, mít na paměti existenci podobných obludností.
Ano: Úmysl je v naprosté většině případů prakticky neprokazatelný. (autora tedy necháme jít s podmínkou ;-)
Ale: § 228 žádný úmysl nezmiňuje. Takže CSRF (bude) zakázáno zákonem a basta! ;-)

Správně! A jak to zákon zakáže, tak končí sranda! :) Ještě bych tam vložil paragraf "Ohrožení dat uchovávaných v systému elektronického uchování dat", a to nějak takhle:

1. Kdo si zvolí heslo, které je rovno jeho datu narození, jménu manželky, psa, kočky, oblíbeného sportovního klubu či podobné, bude potrestán odnětím svobody na 6 měsíců nebo zákazem práce s výpočetní technikou na pět let.

2. Výjimečný trest dostane ten, kdo zvolí heslo "12345" nebo několik stejných znaků.

A bude! :)

Mám lepší řešení: KAŽDÝ by na základě presumce viny dostal př narození 80 let podmínečně. Každý přeci porošuje nějaké zákony, jen státní úředník není vždy na místě, aby to stačil postihnout...

Prevence musí bejt!

To je, možná, přehnané, stačilo by uzákonit, že vlastnictví počítače jednoznačně prokazuje záměr páchat počítačovou kriminalitu, a všechny tyhle clickjacky a dětská pornografie by byly jednou provždy vymýceny. Beztak to poctivýmu pracujícímu k ničemu není!

Správně! Já bych všechny ty internety, clickjackingy a csrf zakázala ...

Co se týče uložení "tajné hodnoty" do cookies, tak to není dobrý nápad - cookies se v javascriptu dají číst, a proto bych se bál toho, že se k té hodnotě útočník dostane. V tomhle případě doporučuji ukládat tu hodnotu třeba do PHPSession - přeci jenom většina formulářů, které by mělo smysl zneužít, se používají až po přihlášení uživatele - a tam už se nějaká identifikace uživatele používá, takže uložení na straně serveru je většinou snadno možné. (Případně je možné hodnotu cookie nějak šifrovat, aby jen server znal skutečnou tajnou hodnotu a nedala se zjistit pouze z hodnoty cookie.)

Další problém je s technologií AJAX - tam je potřeba toto řešit také, jelikož se jedná v principu o to samé a lze to napadnout úplně stejným způsobem.

Ad ochrana:
U uživatele je myslím rozumné používat "anonymní mód" - viz http://zdrojak.root.cz/zpravicky/google-chrome-vicenasobne-prihlaseni/.
Na straně stránek to je mnohem těžší, tam je nejspíš nejrozumnější celkem náročná implementace nějakého jednorázového tunelu nad autorizací v Javascriptu (v tom případě by web měl být kompletně napsaný nad technologií AJAX, aby všechna data šla přes tento tunel); toto řešení je imunní vůči CSRF (tunel si posílá nějakou jednorázovou hodnotu, která se mění pro každý další dotaz na server) i proti Clickjackingu - při otevření iframu se znovu načte stránka, a tudíž nebude uživatel autorizován, jelikož bude autorizován jen v rámci tunelu na původní stránce.
Bohužel formuláře bez autorizace nelze proti Clickjackingu efektivně bránit, maximálně v Javascriptu zabránit, aby byl web načten v iframu.

Co se týče uložení "tajné hodnoty" do cookies, tak to není dobrý nápad - cookies se v javascriptu dají číst

Záleží na tom, jak moc jste si jistý, že je vaše aplikace odolná vůči XSS. Pokud se XSS nebojíte (myšleno oprávněně, protože vstupy pečlivě kontrolujete), tak lze cookies bez problémů použít. Ale je to skutečně o potenciální riziko navíc (důležité je, že je jen "potenciální").

Ano, riziko to je potenciální - jednak to lze zneužít nějakou další zranitelností přes XSS, a druhak by to mohlo jít ještě takhle (tímto postupem si nejsem jistý, jenom mě napadá) - při načtění iframe na útočníkově stránce by se teoreticky dalo přes DOM dostat ke cookies stránky v iframe - nejsem expert na rozdíl implementace Javascriptu v prohlížečích, ale myslím si, že schopný útočník by to mohl zneužít jestli to je možné.

při načtění iframe na útočníkově stránce by se teoreticky dalo přes DOM dostat ke cookies stránky v iframe

Ne, tohle skutečně nejde, to by byla velká bezpečnostní bota v návrhu samotných cookies.

Jediné štěstí - vím jaká kouzla jsou v JavaScriptu možná, a proto si člověk nejdřív musí vyzkoušet, jestli to či ono funguje nebo ne (i v souvislosti s útoky).

Nic takového možné nebylo, IE6 kontroluje přístup k vnořeným rámům stejně jako všechny ostatní prohlížeče (pokud se liší doména rámu, žádný přístup nepovolí).

Přinejmenším takový výrok nelze napsat bez újmy na obecnosti - pokud máte na mysli nějaké konkrétní neopravené verze IE6 nebo nějaký speciální způsob využívající jiné bezpečnostní chyby tohoto prohlížeče, tak je potřeba to napsat. Jinak je takový výrok obyčejný FUD.

Prehliadac IE6 sa opyta, ci dovolujete cross-domain scripting. Vacsina ludi pri takom niecom zarucene odpovie "Ano". Potom mozete kludne pristupovat AJAXom aj k inej domene.

Aktualizovaný Internet Explorer 6 ve výchozí konfiguraci tuto otázku nepokládá a operaci rovnou zamítne.

Tak ta hodnota v cookie by se dala ukládat jako posolený hash.

Opravdu dobrý nápad, tohle je rozumné řešení a relativně snadné na implementaci (IMHO).

Článek právě pojednává o tom, že ani formuláře po přihlášení nejsou v bezpečí a z jiných stránek je může autor zneužít (pokud zná strukturu formuláře).

Pokud odešle formulář, automaticky se použije i hodnota PHPSession, tedy bude přihlášen a kód se provede.

Já jsem teda jenom obyčejná důchodkyně a těmhletěm internetům vůbec nerozumím ... ale jste si vědom toho že ID té PHP session se většinou ukládá taky do cookie, a z bezpečnostního hlediska v tom tedy není výrazný rozdíl? Pokud vaše stránky budou náchylné na XSS, tak je jedno jestli to uděláte tak nebo tak - přes JS se dostanete k oběma.

Také jsem zcela nepochopila čeho chcete dosáhnout tím šifrováním, ale třeba mi to vysvětlíte. A AJAX na pozadí také používá POST / GET požadavky, takže nepochybuji že to také půjde prolomit - je to sice složitější na implementaci, ale určitě to půjde.

Šifrováním samotné hodnoty cookie se nedocílí vůbec ničeho, protože ono úplně stačí odposlechnout tu šifrovanou hodnotu. Sledujte se mnou:

Standardní request:

1) server vygeneruje tajnou hodnotu cookie "A" a zašifruje ji čímž získá hodnotu "B" kterou pošle klientovi
2) klient vezme hodnotu "B" a odešle ji společně s requestem (například ji vloží do formuláře)
3) server vezme zašifrovanou hodnotu cookie, dešifruje a porovná

S odposlechem:

1) server vygeneruje tajnou hodnotu cookie "A" a zašifruje ji, atd. ...
2) zlý hacker odposlechne zašifrovanou hodnotu cookie a uloží si ji
3) zlý hacker vytvoří potřebný request (formulář) a přiměje klienta aby ho odeslal, přičemž v requestu použije odposlechnutou šifrovanou hodnotu
4) server přijme request, a bez problémů ho zpracuje protože obsahuje "bezpečnou" tajnou hodnotu

A včil jsme v piči - celé to právě popsané šifrování cookie je nedomyšlené a nefunguje. Aby to fungovalo tak by klient nesměl posílat zpět tu samou šifrovanou hodnotu jako dostal, ale musel by ji nějak upravit - například dešifrovat a zašifrovat jiným heslem, které by ale musel znát server aby výsledek mohl dešifrovat a zkontrolovat.

Ne že by takové JS šifrování neexistovalo, ale vyžaduje to další věci - například bezpečnou výměnu klíčů. Ale možná existuje nějaká ďábelsky chytrá finta která to řeší. Daleko jednodušší mi ale přijde prohnat to přes SSL a nešaškovat s nějakým custom developed šifrováním.

A teď mne omluvte, jdu se dívat na mexickou telenovelu.

Kurnik, nepral jsem si. :)

Správná připomínka. Pomocí CSRF útoku nelze číst žádná data - útočící požadavek se odesílá v prohlížeči oběti a prohlížeč z bezpečnostních důvodů nedovolí odeslat zobrazený výsledek někam dál (útočníkovi).

Asi nejčastějšími typy útoků, které mohou číst uživatelská data jsou: XSS a JavaScript Hijacking (http://jeremiahgrossman.blogspot.com/2007/04/javascript-hijacking.html).

Plati to i o obrazkach, ktere ziskam pres image.src = xsrf_adresa ? Nelze s tim obejktem image pak udelat neco, ze se ten obrazek dostane do nepovolanych rukou?

Tím jen obrázek může zobrazit webová stránka uživateli, ale ještě se nedostal k útočníkovi a ten nemá jak k obsahu obrázku přistoupit. Takový canvas, který umožňuje přistupovat k obrázkům (a třeba i jejich obsah někam odeslat) může přistupovat pouze k obrázkům ze stejné domény, z tohodle pohledu bezpečné.

Jestli jsem to správně pochopil, tak třeba i takové odhlášení Googlu trpí tímto problémem, protože stačí cinknout na tuhle adresu http://www.google.cz/accounts/ClearSID a Google vás odhlásí. Samozřejmě to funguje i s pouhým obrázkem: http://jdem.cz/ah4n4 Správné řešení by tedy bylo chtít u odhlášení nějaký náhodně vygenerovaný hash uložený v cookies? Třeba google.cz/accounts/ClearSID?hash=123456 a pak kontrolovat, zda je hash v cookie stejný jak v GET?

Odhlášení je akce, která nepochybně změní stav aplikace, takže by měla být provedena metodou POST. Alespoň já jsem to tak v phpMinAdminu udělal.

Podle článku to přece nepomůže, když jsem schopný automaticky odeslat formulář metodou POST přes Javascript. Nebo je v tom nějaký další fígl? :-)

Finta je v tom, že odhlášení je stejně jako ostatní POST formuláře chráněno proti CSRF pomocí tokenu.

Je to tak, odhlášení by mělo mít implementovanou ochranu proti CSRF.

Já osobně také automatické odhlášení považuji za útok, ale mnohé webové aplikace nejsou chráněné (např. aplikace od googlu: výše uvedené URL a také gmail: pomocí URL https://mail.google.com/mail/?logout).

Email na seznamu je ochráněn proti automatickému odhlášení (pomocí ve článku uvedeným hashId).

Někdo to ale za útok nepovažuje, protože nedojde ke ztrátě dat...

Tem POST jsem opravil, děkujeme.

httonly je dobrá věc, ale funguje, myslím, zatím jen v IE a Firefoxu. Ostatní prohlížeče přístup povolí i k takovému cookies; nicméně to nijak nebrání tomu nastavovat httponly jako prevenci v každém případě.

podpora "hlavních" prohlížečů s httpOnly flagem je na https://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

Rozšíření útoku na metodu POST
<form action="http://webmail/poslat" method="get">


Předpokládám že v bloku textu ukazující post útok by měla být metod="post"

Určitě, viz výše.

V článku se psalo o možnosti kromě uložení "tajné hodnoty" do formuláře ji uložit i do cookies. Pak to samozřejmě funguje. Důvodem bylo, aby se pro porovnání nemusela tajná hodnota uchovávat (pro účely porovnání) na serveru.

Zkusím to napsat trošku jinak:

A) na klientské straně vygenerujeme nějaký hash a uložíme ho do cookies a zároveň hodnotu hashe přidáváme ke každému odesílanému formuláři (server o hodnotě hashe nic neví)

B) server při přijetí požadavku (odeslaný formulář od klienta) má k dispozici veškeré cookies, které nastavil klient (v PHP např. proměnná $_COOKIES) a zároveň přístup k POST/GET datům - v těch je také přiložený hash

- server tedy zkontroluje hodnotu uloženou v cookies proti hodnotě z formuláře

- útočník se hodnotu v cookies nedozví a je schopen pouze vytvořit formulář bez hash hodnoty
(snad je tomu teď lépe porozumět)

IMHO je lepší generovat tu tajnou hodnotu už na serveru a ne až na klientovi - například pokud vaše aplikace JS nevyžaduje tak proč ho tam zbytečně tahat, že? A implementačně je to skoro stejné, nijak výrazně se to neliší - pár řádek PHP kódu.

Nehledě na to že cookie se dá využít i elegantněji - na serveru si vygeneruji hodnotu, uložím si ji a pošlu ji uživateli jako cookie. Díky tomu on mi ji při každém requestu automaticky pošle a já si ji mohu porovnat se svojí uloženou hodnotou. Výhoda je v tom že nemusím do úmoru tu hodnotu vypisovat do "hidden" položek všech formulářů (a funguje to dokonce i pro GET requesty aniž bych musela tu tajnou hodnotu uvádět v URL).

Teda, původně mne všechny ty internety jenom otravovaly, ale já jim snad nakonec ještě přijdu na chuť ...

IMHO je lepší generovat tu tajnou hodnotu už na serveru a ne až na klientovi - například pokud vaše aplikace JS nevyžaduje tak proč ho tam zbytečně tahat, že? A implementačně je to skoro stejné, nijak výrazně se to neliší - pár řádek PHP kódu.

vždy záleží na konkrétní aplikaci - vím že existují takové, které javascript nepoužívají

Nehledě na to že cookie se dá využít i elegantněji - na serveru si vygeneruji hodnotu, uložím si ji a pošlu ji uživateli jako cookie. Díky tomu on mi ji při každém requestu automaticky pošle a já si ji mohu porovnat se svojí uloženou hodnotou. Výhoda je v tom že nemusím do úmoru tu hodnotu vypisovat do "hidden" položek všech formulářů (a funguje to dokonce i pro GET requesty aniž bych musela tu tajnou hodnotu uvádět v URL).

Ano - to je princip CSRF útoku :) Hodnota v cookie se posílá automaticky z prohlížeče s jakýmkoliv požadavkem na daný server. Pokud nepoužiji "hidden" položku pro odesílaný formulář, mám zranitelnou aplikaci na CSRF. Díky této položce se dá velmi rychle zkontrolovat, zda-li nějaká aplikace je chráněna proti CSRF či nikoliv.

ještě původní zdroj: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf kapitola "4.2 Client-Side Protection"

Nezapomínejte mladíku že útočníkův request jde sice prohlížeče uživatele, ale z jiné domény, a tudíž nedostane cookie s tajnou hodnotou kterou si uložila původní stránka. Sleduj se mnou:

1) server www.jezevcik.com vygeneruje tajnou hodnotu "x" a pošle ji klientovi
2) útočník na server www.vzteklina.com umístí skript který na server pošle POST request "delete-all", a přiměje uživatele aby ho spustil (jedno jak)
3) útočníkův skript se ale spouští na www.vzteklina.com a tudíž nedostane cookies nastavené pro www.jezevcik.com
4) server www.jezevcik.com si zkontroluje hodnotu "x" a má vyhráno

Paní Pohlová,

asi jsem taky něco nepochopil. Pokud útočník na www.vzteklina.com použije k útoku IFRAME z domény www.jezevcik.com, kde lstivě skryje to, že se jedná o stránku "chcete smazat všechny své e-maily" a donutí (jedno jak) uživatele kliknout na "ano"...

...pak server jezevcik.com dostane:
1. tajny hash ktery si sam vygeneroval
2. tajnou cookie, kterou si sam nastavil

Podle mého není v případě použití IFRAME žádný rozdíl mezi tím, jak uživatel server jezevcik.com používá normálně a jak ho používá, aniž by o tom věděl. V tom případě je však jakákoliv ochrana tohoto typu neúčinná.

A druhá věc k Vašemu příkladu - POST se pošle na jezevcik.com (jinak by to nebyl útok na jezevcik.com) a ten svou cookie, kterou si v bodě jedna nastavil, samozřejmě obdrží.

"HTTP referer jde ale falšovat"

"protože CSRF útok využívá prohlížeč oběti" (v casti o kontole user-agent)

Jak jdou tyhle dve veci dohromady? Jak je mozne zfalsovat referer na strane klienta, tedy prohlizece obeti? Diky, Leo

V tomhle případě se jedná o nezávislé odstavce. Není třeba nic dávat dohromady.

Fajn, a jak je tedy mozne zfalsovat referer abych uskutecnil CSRF? Leo

Falšování HTTP refereru v souvislosti s CSRF samozřejmě nedává smysl (bavíme-li se o aktualizovaných prohlížečích). Snažil jsem se to vysvětlit už Rastislavu Turkovi na jeho přednášce na WebExpu a jsem rád, že nejsem jediný, kdo si to uvědomuje...

Problém je v tom, že se na přítomnost Refereru nedá spolehnout, protože např. firewally ho odstraňují. Kvůli tomu bychom museli povolit provedení operace i bez Refereru, což by dovolilo útočit na uživatele se zapnutým firewallem.

Neda se nez souhlasit, taky nechapu proc to porad lide opakuji ("referer se da falsovat").

Plus (pro podporu nazoru o nesmyslnosti zalozeni obrany proti CSRF na kontrole refereru) pridam, ze je mozne vytvorit v prohlizeci pozadavek uplne bez refereru a to pro POST i GET metodu

Lidi to opakují protože nepřemýšlejí. Někde jednou slyšeli že http referer se dá zfalšovat, všichni s tím evidentně souhlasili, takže to nutně musí být pravda, ne? To že to bylo v úplně jiném kontextu, a že tady to evidentně neplatí, jim jaksi uniká.

Bohužel ne. Mám pocit, že cílem pana Turka je šířit mezi lidmi strach a nikoliv zvyšovat bezpečnostní povědomí. Takže když si někde přečte, že v jakési prehistorické verzi některého prohlížeče šlo podvrhnout Referer, tak to zobecní a na přednášce řekne, že lze podvrhnout Referer. To se ale prostě bez újmy na obecnosti říct nedá.

Tak původně jsem si myslela že referer přes JS jednoduše spoofovat nepůjde, ale vypadá to že to jde - viz například:

http://www.cgisecurity.com/lib/XmlHTTPRequest.shtml

Je to sice z roku 2005 ale týká se to IE 6, což je stále ještě relativně dost rozšířený browser.

Takže pokud někdo bude chtít, nedá mu asi velkou námahu složit si obdobným způsobem libovolný request s libovolným refererem.

V aktuální verzi IE6 se tato chyba již neprojevuje.

"další argument proti referer-based ochraně proti CSRF (k již zmíněným problémům s firewally)."

A jak konkretne by v tomto pripade slo podle Vas podvrzeni refereru Javascriptem zneuzit k CSFR (predpokladejme, ze uzivatel / obet utoku ma ten nezabezpeceny IE6).

Problem s firewally je opacny - neumozni CSRF, pokud referer vyzaduji a delam jeho kontrolu tak omezim opravneneho uzivatele, ale neumoznim utok.

Leo

Za prvé je ta chyba opravená i v aktuální verzi IE 6. I tento prohlížeč byl aktualizován, především právě o bezpečnostní záplaty.

A navíc Leoš Ondra správně poukázal na to, že odkázaný útok se pro CSRF nedá použít, protože CSRF je založeno na transparentním poslání cookie, ke kterému při tomto útoku nedojde.

Takže i když souhlasím, že Referer se pro obranu proti CSRF použít nedá (protože ho firewally filtrují), tento příspěvek je poněkud mimo.

Jak se dá zjistit, kolik lidí používá neaktualizované IE6, když tvrdíte, že jich je hodně?

Odkázaným útokem se dá podvrhnout Referer, nepošle se ale cookie. CSRF tímto útokem tedy provést nelze.

Ano, to nikdo nerozporuje. Jen je potřeba se vyjadřovat přesně a nesměšovat "Referer lze podvrhnout" s principem CSRF. Protože když už někdo Referer podvrhne, tak zároveň nepodvrhne cookie.

Já myslím, že ty jsou před spoustou těchto útoků chráněné už z principu. V Seaside to funguje zhruba takto... Každá session dostane vygenerovaný hash, který se předává v URL a navíc každá akce má přiřazený opět hash, který se ovšem po každé vygenerované akci mění. Tzn. že například link na akci "delete" má v jeden okamžik hodnotu "iOvfrbZo", ale stačí provést jakoukoliv akci nebo refresh stránky a původní hash už neplatí, ale akce "delete" má nyní hodnotu třeba "TCXdQyWZ". A samozřejmě tahle akce platí jen pro tu konkrétní session.
Myslím, že to je zabezpečení víc než slušné.

a funguje pak taková aplikace ve více záložkách?

příklad: zobrazím si stránku kde je akce "delete", tu samou stránku ještě jednou v druhé záložce (zase je tam akce "delete" s novou hash hodnotou) a z té první se pokusím o akci "delete" (se starým hashem)
...dojde k chybě?

„a funguje pak taková aplikace ve více záložkách?“

Ano, funguje. Onen předávaný hash akce totiž neidentifikuje akci samotnou, ale jejího předka (alespoň takhle to má Apache Cocoon). Na serveru pak nemusíte mít seznam navazujících akcí, ale může to být strom – pokud z jednoho místa otevřete víc záložek, má odpovídající místo ve stromu víc potomků.

Ono jsem to možná špatně vysvětlil. V Seaside jsou i ty jednotlivé stránky adresovány pomocí těch action hashů. Takže pokud máme například aplikaci na adrese "www.apl.cz" tak po zadání té adresy do prohlížeče se vygeneruje například "www.apl.cz/?_s=RfbsExbGPszyseST&_k=CqAJIouj" a pokud otevřeme novou záložku opět s adresou "www.apl.cz", dostaneme "?_s=JmSGvKrMLqzkmpAY&_k=ZhPyTUdi". Vizuálně i funkčně to vypadá stejně, ovšem v praxi 2 rozdílné instance té aplikace, tudíž problém nastat nemůže.
Pokud bychom otevřeli první záložku a měli adresu "www.apl.cz/?_s=RfbsExbGPszyseST&_k=CqAJIouj", otevřeli druhou záložku a přesně tam zkopírovali tu adresu, zobrazilo by se nám to samé a dokonce adresa by zůstala stejná. Pokud bychom na té stránce kliknuli na akci "delete" (která by měla na obou stránkách stejný hash), v obou případech by se akce provedla (díky mechanismu cache, uchovávající posledně použité požadavky), ale poté by byla v každé záložce jiná adresa, protože každa záložka by vygenerovala nový request nezávisle na sobě. V každé takto vyrenderované stránce by samozřejmě odkazy (i když ukazující třeba na stejné akce) měly už naprosto jiné action hashe.

Díky za výborný článek a díky zejména za výborné příklady.

(Přeposílám kolegovi, který se mne dneska párkrát ptal, proč nás pořád tak trápí ten ActionController::InvalidAuthenticityToken :)

karmi

Není zač. Přeposílám poděkování do Plzně.

Pokud používáte Nette Framework, můžete aktivovat ochranu před CSRF metodou addProtection(). V praxi to může vypadat nějak takto:

// jednoduchý formulář na změnu emailové adresy
$form = new Form;
$form->addText('email', 'E-mail:')
        ->addRule(Form::FILLED, 'Please enter new email.')
        ->addRule(Form::EMAIL, 'The entered email is not valid.');

$form->addSubmit('save', 'Save');

$form->addProtection('Please submit this form again 
        (security token has expired).');

Zprava v metodě addProtection je volitelná a zobrazí se uživateli tehdy, pokud odesílání kvůli CSRF ochraně selže. Například když token stačil vyexpirovat.