Lax som default: Förstärkt skydd mot CSRF-angrepp i Google Chrome

Den som följer nyheterna inom IT-säkerhet kan lätt känna sig lite uppgiven av det ständiga flödet av kritiska sårbarheter, dataläckor och angrepp. För att lätta upp handlar därför det här blogginlägget om en positiv nyhet. Att surfa med Chrome kommer nämligen, åtminstone i vissa avseenden, bli säkrare från och med version 80 som släpps den 4 februari. Samma förändring är också planerad för Firefox, samt Edge och innebär att kakor kommer hanteras på ett säkrare vis som standard.

Den planerade förändringen innebär att kakor kommer märkas med attributet SameSite:Lax i Google Chrome från och med version 80 istället för SameSite:None. Detta kanske inte säger så mycket för dem vars arbetsdag normalt inte innefattar att granska webbapplikationers säkerhet, men förändringen innebär ett även äldre webbapplikationer nu får ett förstärkt skydd mot angreppstypen Cross Site Request Forgery.

Denna sårbarhetsklass var tidigare ett stort problem och var med i den förra utgåvan av OWASP Top 10. Tack vare att moderna ramverk som exempelvis MEAN-stacken och Django har inbyggt skydd mot angrepp har dock förekomsten av sårbarheten kraftigt minskat. När vi granskar äldre applikationer eller IoT-produkter ser vi dock tyvärr fortfarande ofta sårbarheten.

Cross Site Request Forgery

Ett CSRF-angrepp syftar till att förfalska HTTP-anrop i en webbapplikation som en autentiserad användare genom att lura denna att besöka en av angriparen konstruerad hemsida.

Enklast är sannolikt att förstå hur angreppet går till genom ett konkret exempel. För det syftet har jag skapat en enkel applikation där användare efter inloggning kan skicka pengar genom att fylla i mottagare och belopp. (Det finns inga konton eller koppling mellan användare, men låt oss inte haka upp oss på detaljer.)

• 

• 

• 

Bakom kulisserna håller applikationen reda på användare genom att en sessionskaka. Inspekterar vi denna ser vi att attributet SameSite ej är konfigurerat.

Själva överföringen sker genom en Post-förfrågan till transfer.php med parametrarna amount och account.

• 

• 

När servern får ett sådant anrop skrivs bara värdet av parametrarna ut, vilket förstås skiljer sig från en normal bank (men detta spelar ingen roll för beskrivningen av angreppet). Detta syns koden för överföringsfunktionen på serversidan (som under normala förutsättningar ej är läsbar för användaren).

Detta flöde är sårbart mot ett CSRF-angrepp. För att utnyttja sårbarheten kan en angripare skapa en hemsida med följande källkod.

Som framgår av källkoden är det som händer när någon besöker angriparens sida att ett osynligt formulär fyllt med angriparens parametrar skickas i ett Post-anrop till transfer.php i bankapplikationen. I vår testapplikation är detta visuellt tydligt eftersom sidan också öppnas i offrets webbläsare. (I ett verkligt angrepp skulle detta normalt ske utan att synas för användaren.)

Vi ser att angreppet lyckas, vilket beror på att webbläsaren populerar anropet till transfer.php med den kaka som finns lagrad i offrets webbläsare. Att på detta sätt genomföra statusförändrade handlingar som autentiserade användare av webbapplikationer är vad CSRF-angrepp generellt syftar till att åstadkomma.

När sådana angrepp är möjliga för säkerhetskänsliga funktioner som att byta lösenord, ändrar konfigurationer eller överföra pengar blir konsekvenserna förödande.

Varför är SameSite bra?

SameSite är ett attribut för kakor som syftar till att skydda användare mot angreppet beskrivet ovan. Attributet har idag tre möjliga värden som begränsar under vilka förutsättningar webbläsaren skickar med kakor i anrop generade från externa sidor.

1. None (Implicit default idag som innebär att kakan alltid skickas med i anrop från externa sidor.)
2. Strict (Innebär att kakor aldrig skickas med i anrop från externa sidor.)
3. Lax (Kommer bli default och innebär att kakor skickas vid direkt navigering, men inte via Post-anrop från externa sidor).

För att konkret testa vad förändringen kommer innebära kan man aktivera den genom att gå till chrome://flags och söka efter samesite enligt nedan.

Aktiverar vi funktionen och försöker ladda angriparens sida kommer vi istället till inloggningsidan för Bankapplikationen och genomför inte överföringen.

Angreppet fungerar med andra ord ej längre. Värt att notera är dock att eftersom värdet Lax nu används skickas dock kakor med under vissa förutsättningar. Exempelvis kan vi hämta huvudsidan för bankapplikationen genom en direkt länk <a href=”http://…”.

• 

Avslutande ord

Som framgår av exemplet ovan kommer övergången till SameSite:Lax innebär ett förstärkt skydd mot CSRF-angrepp.

Värdet Lax innebär dock en mellannivå mellan nuläget None och det mest restriktiva värdet Strict. Därför går angreppet beskrivet ovan under visa förutsättningar att modifiera för att fungera även med SameSite:Lax. Funktionen ska därför tänkas på som ett försvarled enligt principen defense-in-depth som samverkar med andra etablerade skyddsåtgärder på serversidan som exempelvis CSRF-tokens.

Därutöver rekommenderas att explicit konfigurera SameSite på serversidan för att få samma hantering mellan webbläsare och inte vara beroende av de olika webbläsarnas standardbeteende. För mer känsliga applikationer är även det mer restriktiva läget SameSite:Strict att föredra.

Referenser

1. RFC SameSite Cookies, https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-4.1.1

2. Updatering https://www.chromium.org/updates/same-site