PHP: CSRF Protection class

28.1.2010 00:19 | Přečteno: 1824× | PHP a Web | poslední úprava: 28.1.2010 11:39

Rád bych se podělil o třídu, která má bránit proti CSRF útokům.

CSRF obecně

Jako první bych začal, co to CSRF (Cross-site request forgery) útok vlastně je. Jde o typ útoku, který umožňuje útočníkovi (po spuštění jeho kódu na jeho webové stránce) provést operace na jiné důvěryhodné stránce, kde je uživatel aktuálně přihlášen. Pro příklad: Jste přihlášeni ve webmailu, jenom navštívíte útočníkovu stránku a on vám změní nastavení přeposílání emailů tak, že veškeré vaše nové emaily se přesměrují i do jeho schránky. (více informací o útoku třeba zde či zde)

Vzhledem k tomu, že útočník nepotřebuje najít chybu v kódu stávající stránky k úspěšnému provedení útoku a stačí mu pouze návštěva uživatele na cizí stránce, tak si myslím, že by tento typ útoku neměl být brán na lehkou váhu. Navíc obrana proti němu je dle mého názoru relativně snadná (a snad i s touto třídou snadnější ). Nejjednodušší princip ochrany (a také nejpoužívanější) je používání autorizačního tokenu, který se vkládá jako parametr (GET či POST) nového dotazu do stránky, následně se odešle na server a tam se zkontroluje oproti uložené hodnotě. Používat by se měl při každém dotazu, nebo alespoň u těch, které provádějí na serveru nějakou akci.

Bezpečnost ochrany

Alfou a omegou fungování této ochrany je nemožnost získání tokenu útočníkem. Vzhledem k tomu, že útočník nemá (až na jeden způsob, a to vložením externího javascriptu (JS) do stránky) možnost získat v prohlížeči uživatele obsah chráněné stránky (a tím i token), tak je potřeba vyvarovat se vkládání tokenu v čitelné formě v JS formátu (ať už naprostým nevkládáním tohoto tokenu do JS nebo používáním AJAXu pro získání tokenu či zapouzdřením tokenu v JS tak, aby z venku nešel získat (riskantní způsob, ale někdy to jinak nejde)). Stejně tak je dobré, aby token nebyl funkční po moc dlouhou dobu a aby byl pokaždé unikátní.

Moje třída používá přesně tuto ochranu (tedy používání autorizačního tokenu). Jedna z důležitých vlastností této třídy (a také způsob návrhu) je ta, že na serveru se autorizační token neukládá (na rozdíl třeba od řešení Jakuba Vrány). To sice teoreticky dává možnost útočníkovi odhadnout token, případně podvrhnout klíč i kontrolní cookie, ale jak brzy vysvětlím, proti tomu je třída (dostatečně) chráněna.

Fungování třídy

Pojďme se nyní dostat k tomu, jak moje třída funguje. Když necháte vygenerovat token, tak se do cookie uloží kontrolní hash a při kontrole se tyto dva údaje proti sobě zkontrolují. Aby to ale nebylo tak jednoduché, tak v tokenu je zakomponováno, kdy byl vytvořen, a v kontrolním hashi je mimo tokenu zakomponován jak čas vytvoření, tak IP adresa uživatele a jeho User Agent - to vše pro to, aby se omezila možnost použít token vícekrát a 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). Třída má zároveň možnost povolit více kontrol naráz - buď je nastaveno používání jenom jedné hodnoty v cookie (tedy pokud uživatel má otevřených více stránek naráz, tak bude fungovat jen ta poslední načtená) nebo se v cookie bude ukládat více hodnot a fungovat budou všechny otevřené stránky.

Nyní vás možná napadlo - toto je veřejně dostupná třída a útočník má možnost získat jak IP adresu, tak User Agenta uživatele, tak proč by nemohl vytvořit vlastní platnou dvojici a podvrhnout ji? I na toto jsem při návrhu myslel. Předtím, než začnete třídu používat, si vygenerujete pomocí metody csrfp::random_settings vlastní náhodné nastavení generování tokenu. Možností generování je při standardním nastavení (délka klíče 40 znaků, znaky v klíči 0-9a-zA-Z a 50 znaků salt pro hash) přes 2*10^192 a s postupem času se toto číslo zvětšuje (díky úpravě času v hashi).

Jak třídu používat

//Vytvoření nové instance
$csrfp = new csrfp($settings);
/* Možnosti nastavení (settings je pole a je to nepovinný parametr konstruktoru; v následujícím popisu je v závorkách uvedena obecná hodnota):
length => Délka tokenu (standardně 40 znaků)
validity => Délka platnosti v minutách (standardně 20; třída bude funkční až do platnosti 1 dne)
cookie => Jméno cookie (csrfp)
get => Jméno parametru, když je token v $_GET (csrfp)
post => Jméno parametru, když je token v $_POST (csrfp)
cookie_properties => Parametry pro funkci setcookie (od path včetně; standardně prázdné a jedná se o pole)
multiple => Pokud je true, tak se zapne podpora pro více kontrol naráz (standardně zapnuté).
*/
//Pro získání nového tokenu je potřeba inicializace; vzhledem k tomu, že se vytváří cookie, tak nesmí být do té doby poslán jakýkoliv obsah
$token = $csrfp->start(); //nebo
$token = $csrfp->token;
//Token je možné po inicializaci získat buď jako $csrfp->token, nebo $csrfp->key nebo jenom pomocí (string) $csrfp

//Pro vytištěni odkazu s tokenem
echo 'text';
//Kontrola tokenu - vrací true nebo vyhazuje Exception
$csrfp->check();
//Smazání cookie
unset($csrfp->token); //smaže poslední úspěšně zkontrolovaný token (při multiple; jinak funguje vždy)
//nebo
$csrfp->disable($token); //parametr nutný jen při zapnutém multiple

Doplnění: Pro správné fungování je potřeba používat token jednorázově, proto se po zkontrolování token smaže z cookie.

Závěrem

Doufám, že vám tato třída pomůže k jednoduché implementaci ochrany proti CSRF. Třída je dostupná pod licencemi MIT a GPLv3.0 a testována v PHP 5.2.10, takže by neměl být problém ji využít téměř kdekoliv (pokud se mýlím, opravte mě v komentářích). Stejně tak pokud byste měli pocit, že třída není bezpečná nebo byste měli jakýkoliv jiný dotaz, napište komentář . Děkuji za čtení.

Update 28.1.2010 11:40: Upravil jsem třídu tak, aby se vždy používalo právě jedno cookie, čímž je bez přístupu útočníka na chráněný server nemožné podvrhnout cookie (pokud je platnost autorizace uživatele na serveru stejná nebo kratší než platnost cookie a cookie je přítomno, tedy ochrana je zapnuta na všech stránkách). Je to díky tomu, že na přepsání cookie je potřeba, aby cookie přišlo ze stejné domény.

Třída (včetně PHPDoc dokumentace) je ke stažení zde.        

Komentáře

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