PHP: CSRF Protection class (diskuse)

[retro]

Vaše řešení je špatné.

Zkuste se přihlásit na kteroukoliv libovolnou vysokou technickou školu. Tam vám řeknou proč.

[gogloid]

Už se stalo a ještě neřekli. Mohl byste to rozvést? Já plánuji tuto třídu používat; a tedy pokud tam je něco, co to činí nebezpečné, tak bych o tom rád věděl.

[Mrkva]

No, kód jsem nějak dlouho nestudoval. <flamebait>Ale to bude tím, že to je v PHP </flamebait>

[retro]

Nehodlám tu psát vyčerpávající návod, který by mne stál plno času. Místo toho, pokud máte zájem, se podívejte, jak tuto problematiku řeší třetí strany.

[pht]

Mě by ten návod docela zajímal. Bejt tajemnej jak hrad v karpatech akorát snižuje vypovídací hodnotu Vašeho příspěvku na nulu.

Vaše třetí strany to řeší v lepším případě úložištěm na serveru, čemuž se chtěl zdejší autor vyhnout.

Což neznamená, že nemám o zdejším kódu své pochybnosti, ale to hlavně proto, že je to implementace vlastního krypto schematu, jehož důsledky nejsem schopnej dohlédnout. Ale to samé platí o Vás a Vašem kódu třetí strany.

[Integral]

a ty nam nereknes, proc je spatne?

[fraxinus]

Suhlasim s retro, je to uplne spatne. Navyse je to prekomplikovane zlozite.

...aby se nedal jinak než z IP adresy uživatele zjistit jiný platný token pro případné podvržení (třeba dotazem z útočníkova serveru)

WTF?

Asi by ste si mali znova prestudovat co je to CSRF.

[gogloid]

Tady mi jde o to, že pokud by byl útočník schopen podvrhnout cookie a dodat vlastní token, tak by musel za A) vytvořit vlastní token a kontrolní cookie na svém serveru (kde útočník neví, jak přesně se to dělá) nebo za B) zjistit jinou funkční dvojici - právě proto ta kontrola IP (aby pokud by útočník provedl dotaz se stejným User Agent na chráněné stránky ze svého serveru (čímž by získal jak cookie, tak token), tak aby takto získané údaje nefungovaly).

[podlesh]

No a co když mu prostě a jednoduše javascript ten token pošle? Tím že se tokeny na serveru neukládají je totiž možné použít jeden token opakovaně - alespoň po dobu platnosti toho tokenu, což ovšem je (a musí!) doba dostatečně dlouhá na napáchání škody.

Obávám se, že ukládání tokenů na serveru je nutnost, kterou nelze obejít.

[gogloid]

Ano, ale jak javascript ten token získá? Z cookie ho nelze získat (vzhledem k tomu, jak se vytváří hash, který se vkládá do cookie). Princip CSRF útoku spočívá v tom, že útočník není schopen získat obsah stránky, jen poslat dotaz.

[podlesh]

Ale ano, proti samotnému CSRF to jako ochrana zafunguje.

Ale ta IP adresa se mi stejně nelíbí.

Mimo jiné - co když jde každý request z jiné IP adresy? Například když tam má několik transparentních proxy, náhodně volených, každá s úplně jinou IP adresou? (Toto je naprosto reálný příklad, takovou konfiguraci mají v jedné nejmenované České bance).

[gogloid]

Přiznávám se, to mě nenapadlo. V ten okamžik, pokud by se ověřování IP v kódu vypnulo, je útočník schopen získat dvojici token -> cookie, ale ještě ho musí podvrhnout - což není také tak snadné, jak je napsáno v posledním odstavci. Na druhou stranu, pokud by se IP nahradila session_id nebo něčím se stejnou rolí, tak by útočník již nebyl schopen novou dvojici získat; nebo, pokud by toto id bylo uloženo u klienta, tak by ho musel nejdřív získat a potom by měl možnost získat funkční dvojici token -> cookie. (nejspíš to tam přidám jako možnost konfigurace, to nahrazení IP za session_id)

[pht]

Pokud tam cpete session, tak už můžete rovnou použít tu session k uchování tokenu.

[gogloid]

V principu ano; na druhou stranu mým záměrem bylo neukládat token na serveru - nechtěl jsem, aby se tam hromadily.

[pht]

IMHO pokud už získáte token z nějakého otevřeného formuláře, tak budete mít možnost ten formulář vyplnit a odeslat ještě dříve než to provede uživatel, takže nebude fungovat ani schema, kdy je neopakovatelný token ověřen proti úložišti na serveru.

[podlesh]

Ano, to je slabina i ostatních (zde odkazovaných) řešení.

[pht]

A co když používají útočník a oběť stejnou IP adresu (NAT, proxy)?

[gogloid]

Potom může teoreticky zjistit novou funkční dvojici tokenu plus cookie, ale k podvržení je potřeba infikovat chráněný server, odkud se musí poslat nové cookie (protože by se přepisovalo); nebo, pokud ochrana není zapnutá trvale, alespoň vložit kód do stránky na serveru, který získá cookie ze serveru útočníka (podvrhne ho).

[pht]

Váš protokol je zhruba toto:

C->S: GetForm

S->C: Form,TimeStamp,Cookie

kde Cookie=hash(TimeStamp,OldIP,OldUserAgent)

a

C->S: PostForm,TimeStamp,Cookie

a pak server porovná

Cookie ?==? hash(TimeStamp,NewIP,NewUserAgent)

a

TimeStamp + ExpireTime ?<? TimeNow

a pokud ano, tak akceptuje PostForm.

Teď si vemte, že útočník může navodit situaci, kde má stejnou IP a UA jako oběť a dokonce to stihne dřív než se posune TimeStamp. Pak javascript běžící na oběti udělá něco takového:

C->S: GetForm

S->C: Form,TimeStamp,Cookie=hash(TimeStamp,IP,UA)

C->U: GetTimeStamp

U->S: GetForm

S->U: Form,TimeStamp',Cookie'=hash(TimeStamp',IP,UA)

U->C: TimeStamp'

C->S: PostMaliciousForm,TimeStamp',Cookie

Nemusím nic podvrhovat.

PS. koukám že jste zlepšil tu ochranu na IP na X-Forwarded-For, to ovšem principielně nic neřeší a navíc jste to "zapoměl" zdokumentovat...

[gogloid]

S dokumentací s IP se omlouvám, že není uvedena v dokumentaci (od začátku jsem kód neměnil a použil jsem generický kód).

V následující úvaze mne prosím opravte, jestli jsem se zmýlil v pochopení vašeho komentáře. Chtěl bych zmínit, že timestamp nelze zjistit (je vložen do tokenu a nelze z něj bez znalosti přesného obsahu třídy). V ten okamžik se obávám, že vámi uvedený postup není funkční, protože neumožňuje zaměnit timestamp za jiný; je tedy nutné podvrhnout cookie, aby šel poslat jiný token.

[podlesh]

Počkat, počkat... takže se ve formuláři neposílá nic navíc a celé je to založeno jen na tom, že máme určitý autorizační cookie který je akceptován?

Pak to nebude fungovat! Podstata CSRF spočívá přeci v tom, že si útočník vlastní formulářová data se správnými cookie (a IP adresou, User-Agent, atd) a server provádí autentizaci (a autorizaci) jen na základě těch cookie.

Ochrana pak musí spočívat v ověření, že data formuláře patří k tomu cookie - tedy, formulář musí obsahovat nějakou informaci závislou na cookie (a vice versa).

Přidání dalšího cookie bez změny formuláře vůbec nic nezmění, takový cookie tam vlastně již je - session ID. Poskytne se tím částečná ochrana proti "session-hijacking", ale to je něco jiného.

[gogloid]

Ne, možná jsem se špatně vyjádřil - ve formuláři se samozřejmě posílá autorizační token.

[pht]

je vložen do tokenu a nelze z něj bez znalosti přesného obsahu třídy

To jste taky nějak zapoměl zmínit. Ono by Vám vůbec neuškodilo kdybyste ten algoritmus trochu formálně popsal. V tom případě nevím na co tam máte to IP a user agent? Celý protokol můžete udělat takto:

C->S: GetForm

S->C: Form,TimeStamp,Nonce,Cookie=hash(TimeStamp,Nonce)

C->S: PostForm,TimeStamp,Nonce,Cookie

a dále postupovat stejně. Pak se to více méně podobá klasické ochraně akorát místo uložení na serveru máte "uloženo" v prohlížeči, přičemž spoléháte na tu hash funkci a na ochranu cookies.

Jak tak na to koukám tak tam ten timestamp ani hash nemusí být. Co třeba:

C->S: GetForm

S->C: Form,Nonce,Cookie=Nonce

C->S: PostForm,Nonce,Cookie

[gogloid]

Timestamp a hash tam být musí. Timestamp je pro zajištění expirace a v cookies je hash, aby se při pouhém přečtení cookies nedal získat token. User Agent je v podstatě jen pro okrasu a IP proto, aby nebylo tak snadné podvržení (již to bylo v diskuzi rozebíráno).

[pht]

Timestamp a hash tam být musí. Timestamp je pro zajištění expirace a v cookies je hash, aby se při pouhém přečtení cookies nedal získat token

Přečtení cookies? To už tady nějak bylo řečeno, že nejde a kdyby šlo tak je to stejně celé k ničemu? A expirace snad ani není v tomto kontextu bezpečnostní prvek. Proti replay nepomáhá, to už bylo taky řečeno.

IP proto, aby nebylo tak snadné podvržení (již to bylo v diskuzi rozebíráno).

To jsme právě rozebrali a ta nonce to spolehlivě zajistí i bez IP.

[gogloid]

Můj protokol funguje zhruba takto:
C->S: GetForm
S->C: Form,Token,Cookie=hash(Token,TimeStamp vytvoření,IP,UA,salt)
a potom:
C->S: PostForm,Token,Cookie
a porovnává se
Cookie ?==? hash(Token,TimeStamp,NewIP,NewUserAgent)
a TimeStamp + ExpireTime ?<? TimeNow
kde timestamp se získává z tokenu (a bez konfigurace třídy, která je unikátní pro každou třídu, nelze zjistit; a možností je velmi mnoho, jak jsem zmínil v zápisku)
Navíc, pokud se nemýlím, tak vámi navržený útok nemůže fungovat - protože projde pouze kombinace (token, cookie) či (token', cookie'), nikoliv (token', cookie).

[pht]

S->C: Form,Token,Cookie=hash(Token,TimeStamp vytvoření,IP,UA,salt)

Tohle asi není úplně ono? Co tam dělá ten salt a jak se ho dozví validátor?

kde timestamp se získává z tokenu (a bez konfigurace třídy, která je unikátní pro každou třídu, nelze zjistit; a možností je velmi mnoho, jak jsem zmínil v zápisku)

V čem to je lepší než přišpendlení nonce?

Navíc, pokud se nemýlím, tak vámi navržený útok nemůže fungovat - protože projde pouze kombinace (token, cookie) či (token', cookie'), nikoliv (token', cookie).

Naopak, můžete poslat jen (cokoliv, cookie), protože cookie tam dodá prohlížeč. To byla Vaše základní premisa a na tom to celé stojí (a padá:)

[fraxinus]

> Tady mi jde o to, že pokud by byl útočník schopen podvrhnout cookie...

Tak sa utocnik normalne prihlasi (cez cookie) a tie maily zmaze priamo.

[gogloid]

Možná si nerozumíme, ale já si pod pojmem "podvržení cookie" představím nastavení nového cookie či jeho přepsání (na což je potřeba posílat to cookie ze stejné domény) uživatelovi útočníkem, nikoliv získání cookie uživatele (což je, pokud se nemýlím, "harvesting cookie").

[podlesh]

Asi by bylo dobré někam dát kompletní aplikačičku s konkrétním použitím, ať je možné konkrétně ukázat problémy.

[vlastikroot]

Však co to je za brutálnost Na CSRF stačí jakejkoli blbej hash hozenej do formu + uloženej do session + ověření toho hashe. Tak primitivní věc.

[Petr Tomášek]

„Tomášovi poznatky“? To je něco jako „mupy mup!“?

[v6ak]

Většinou stejně je nejlepší použít nástroj z frameworku.