Bezpečnostní novinky v prohlížečích: ochrana CSRF a důvěryhodná metadata

Flash je mrtev, ať žije WebAssembly

V letošním roce zmizí z prohlížečů Flash. To je ten jediný hrdina, kterého zabil Steve Jobs, řekl na začátku přednášky Michal Špaček. Narážel tím na to, že se Apple už před deseti lety rozhodl nedat Flash na iPhone. To byl vlastně začátek konce Flashe. Ke konci roku přestane Adobe tento modul distribuovat, stejně jako to už nebudou dělat výrobci prohlížečů. To bude znamenat jeho definitivní konec.

Už teď Flash funguje v omezeném režimu, je potřeba jej na konkrétních webech výslovně povolit. Tvůrci prohlížečů už jej před uživateli různě schovali a zneškodnili. Flash byla zajímavá technologie, která umožňovala běh věcí, které nedokázal přímo prohlížeč a JavaScript.

Tvůrci prohlížečů přemýšleli, že by nebylo špatné mít i nadále možnost spouštět binární kód. Vymysleli tedy technologii WebAssembly. Assembler a web jsou dva opačné konce spektra. Už teď je WebAssembly v prohlížečích dostupný, používají ho některá rozšíření, například 1Password. Je to binární kód, který se dá kompilovat z nějakého jiného jazyka. Je možné použít C, C#, F# a další klasické jazyky, stejně jako je možné použít například Pascal. To si musím zkusit, protože Pascal je druhý jazyk, který jsem se po češtině naučil.

Všechny moderní prohlížeče ho používají, je možné jej využít v případě, že potřebujete něco víc, než vám nabízí JavaScript. WebAssembly je sandboxovaná, dodržuje hranice prohlížeče a měla by být od základu bezpečnější než Flash. Uvidíme, jestli v budoucnu nepřijdou nové problémy, které nás donutí přijít zase s něčím dalším. Prohlížeč je dnes v podstatě operačním systémem.

Edge Legacy končí, IE zůstává

Do propadliště dějin míří také původní prohlížeč Edge, který ještě nepoužívá jádro Chromium. Ten skončí v březnu příštího roku, takže na něj vlastně už můžeme zapomenout. Edge postavený na Chromiu bude fungovat dál. Internet Explorer tu s námi ale bude i nadále. Je vázaný na vydávání Windows, takže dokud tu budou Windows 10, bude tu s námi IE 11. Microsoft sám už ho ale nechce používat, odrazuje od toho, takže na konci letošního roku například Microsoft Teams přestane podporovat IE 11. Příští léto ho přestane podporovat také Office365. Snad se blížíme k jeho konci, už by bylo na čase.

HTTP/2 a dál

Prohlížeč v sobě zahrnuje celou řadu různých vrstev, které musí fungovat, abychom načetli webovou stránku. Na nejnižších vrstvách najdeme protokoly TCP, TLS 1.2 a vyšší a HTTP/2. I v této oblasti probíhá neustálý vývoj a Google už před lety přišel s dalším protokolem s názvem QUIC, ze kterého se později vyvinul HTTP/3. Protokol používá pro přenos UDP, u kterého není zaručeno, kdy data přijdou a jestli vůbec přijdou. Proto QUIC nad UDP vlastně vytvořil vlastní řízení provozu podobné TCP.

U protokolu HTTP/2 existuje nešifrovaná varianta H2C. Ta se do standardu dostala poměrně pozdě a nikdo vlastně netuší, proč. Prohlížeče ji nepodporují, ale ve specifikaci je. U HTTP/3 se vůbec s nešifrovanou variantou nepočítá. Uvidíme, jestli ji tam na poslední chvíli někdo nepřidá, ale zatím tam není. HTTP/3 už pravděpodobně váš prohlížeč používá, například Chrome pomocí něj komunikuje se službou YouTube.

Zkracování platnosti certifikátů

S protokolem HTTPS přímo souvisejí certifikáty. Ty mohly mít donedávna platnost dva roky, předtím dokonce deset let. Mít certifikáty s takto dlouhou platností není dobrý nápad. Původně se na zkrácení zástupci CA/B fóra neshodli, protože se změnou nesouhlasili zástupci certifikačních autorit. Tvrdili, že jejich zákazníci to nechtějí, protože by pak museli častěji certifikáty měnit a je to pro ně problém. Tvůrci prohlížečů si ale řekli, že změnu přesto provedou. Oni ovládají prohlížeče a bez nich si můžou autority svoje certifikáty leda tak tisknout na papír.

Od září se tedy platnost veřejných certifikačních autorit zkrátila na 398 dní. Certifikáty s delší platností jednoduše prohlížeč nepřijme. Je to velká změna, která se dotýká celého ekosystému. Jako první toto pravidlo aplikoval Apple v Safari, později se přidaly i další prohlížeče. Nakonec se tato změna dostala také do pravidel pro certifikační autority.

Kratší platnost certifikátů je dobrá kvůli bezpečnostním problémům, kvůli kterým je třeba certifikát zneplatnit dříve. Prohlížeč se ale nemusí o revokaci dozvědět. Nejjistější je tedy počkat na konec platnosti. Další důvod hovořící pro kratší platnost je Certificate Transparency, kde se zveřejňují všechny nově vystavené certifikáty. Prohlížeče mají pravidlo, že certifikát musí být zveřejněn alespoň ve dvou důvěryhodných registrech. Pokud by se některý z nich stal z nějakého důvodu nedůvěryhodným, přestal by být platný i váš certifikát. Stejně byste tak byli nuceni jej vyměnit, přestože by měl dlouhou platnost.

Míchání HTTPS s HTTP

S HTTPS také souvisí problém zvaný mixed-content. To je obsah, který je do šifrované stránky načten po HTTP. Obvykle to nastává, když web přejde na HTTPS, ale má v sobě odkazy na nějaký starý obsah, který je ještě načítán po HTTP. Prohlížeč pak zobrazuje částečnou chybu zabezpečení, která je indikovaná malým vykřičníkem vedle zámečku nebo jinou drobnou úpravou. Je to jakýsi třetí stav, kterému podle výzkumů uživatelé nerozumějí. Je ta stránka špatná nebo není? Nebo jak moc je špatná?

Byla proto vymyšlena funkce zvaná „auto upgrade“. Prohlížeč automaticky nahrazuje reference na HTTP za HTTPS. Nedochází k žádnému přesměrování, prostě se požadavek pošle rovnou na HTTPS. Pokud se obrázek načte správně po HTTPS, je všechno v pořádku. Pokud by došlo k chybě, protože server neumí HTTPS, pak se teprve ukáže chyba. Sníží se to na dva stavy: buď je stránka zabezpečená nebo není.

Chrome od verze 80 takto automaticky upravuje odkazy na audio a video, od verze 86 takto bude upravovat i odkazy na obrázky. Už to mělo být dříve, ale přišel COVID a termíny se odsouvaly. Ještě se to může změnit. Také se to bude zapínat postupně, takže se může stát, že některé vaše zařízení už bude odkazy upravovat a jiné ještě ne.

CSRF: Cross-Site Request Forgery

Útok typu CSRF slouží k falšování požadavků z jednoho webu na druhý. Přihlášený uživatel má například možnost změnit ve svém e-shopu cenu u některého produktu. Já se ale jako útočník rozhodnu, že bych tam chtěl nastavit nižší cenu. Pošlu vám tedy e-mail, kterým vás nalákám na svůj web. Na této stránce by byl vložený obrázek, jehož adresa ale vede ve skutečnosti do administrace vašeho e-shopu. Prohlížeč dostane příkaz ‚načti obrázek‘ a pošle požadavek na váš server. Zeptá se přitom sám sebe, jestli nemá uloženou cookie? Protože je uživatel přihlášený, odchází požadavek také se session ID a požadavek se provede.

Je tak možné zfalšovat požadavek z jednoho webu na druhý. Je to celkem podceňovaný útok, kterým se ale dají dělat zajímavé věci. Klasická ochrana je taková, že se do formuláře na původním webu přidá náhodný token. Ten já jako útočník neznám, takže nedokážu odkaz udělat tak, abych do něj daný token přidal. Tohle ovšem ve skutečnosti řada vývojářů nedělá a jejich weby jsou k podobnému útoku náchylné.

Tvůrci prohlížečů si uvědomili, že jde o velký problém a přišli s řešením nazvaným Same-site cookies. Ty mají speciální parametr SameSite, který je nepovinný a může nabývat tří hodnot: None, Strict nebo Lax. Ty říkají, jestli se cookie pošle a případně za jakých okolností. Pokud je označená jako None, nedojde k žádnému omezení a cookie se mezi weby pošle. Při Strict se naopak nepošle vůbec. Lax znamená, že se cookie pošle jen při požadavku GET. Tahle změna je důležitá, protože vám může znefunkčnit aplikaci.

Pokud by nás tedy útočník vmanipuloval do návštěvy svého webu, který by pak poslal upravený požadavek do naší administrace, správně nastavená cookie by se s tímto požadavkem z našeho prohlížeče neodeslala. Požadavek by tedy přišel od nepřihlášeného uživatele a nenapáchal by žádné škody. Tím pádem by ten útok vůbec nefungoval. Vývojáři prohlížečů se takto rozhodli usnadnit život vývojářům.

Je vhodné stále ještě obě ochrany (SameSite cookie a náhodný token) kombinovat, zejména kvůli prohlížečům, které by ještě nemusely nový parametr pro cookie podporovat. Zásadní informace je, že dochází ke změně výchozího stavu. V současné době cookie bez nastaveného parametru SameSite způsobí stejné chování, jako by měla nastaveno None. Není tam tedy žádné omezení a cookie se normálně posílá. Prohlížeče ale před časem začaly postupně nasazovat změnu, kdy výchozím stavem je Lax. Všechny nové prohlížeče už by se takto měly chovat.

Důvěryhodná metadata

Bylo by dobré, kdyby vývojář mohl od prohlížeče zjistit, jestli požadavek proběhl z jiného webu (Cross site). Doposud jsme to spolehlivě vědět nemohli, bylo to možné zjišťovat pomocí referreru, což ale může například upravit JavaScript. Proto se v prohlížeči objevila funkce Fetch metadata, která umožňuje zjišťovat informace o požadavcích z internetu. Jsou to přídavné hlavičky, které říkají serveru, jaký požadavek vyvolal danou akci.

Všechny tyto hlavičky mají předponu Sec- a není je možné měnit v JavaScriptu. Vždy pocházejí z prohlížeče a můžete se na ně spolehnout, pokud přicházejí po HTTPS. Zatím existují čtyři hlavičky, pravděpodobně budou časem přibývat další:

• Sec-Fetch-Dest  – kam má prohlížeč odpověď umístit
• Sec-Fetch-Mode  – jak bude odpověď v prohlížeči použita (např. jako obrázek)
• Sec-Fetch-Site  – zda jde o cross-site požadavek nebo ne
• Sec-Fetch-User  – zda byl požadavek vyvolán uživatelskou interakcí

Ochranu pomocí SameSite bychom tedy ještě mohli v aplikaci doplnit o kontrolu hlavičky. Vývojář má možnost například zkontrolovat Sec-Fetch-Site a pokud požadavek pochází z jiného webu, může provést nějakou akci. Může například zamítnout provést operaci.

Nové HTTP hlavičky

Postupně přibývají také hlavičky HTTP, nejnovějším příspěvkem jsou hlavičky nastavující izolaci procesů v prohlížeči. To byl princip útoků jako Meltdown či Spectre, které umožňovaly interagovat s jinými procesy. Řeší to i výrobci prohlížečů, kteří nasazují přísnější izolaci jednotlivých procesů, aby útočníkům zkomplikovali život. Zatím to není zapnuto ve výchozím stavu, ale je možné se k ním právě pomocí hlaviček přihlásit dobrovolně.

Hlavička Cross-Origin-Opener-Policy při hodnotě same-origin zajistí, že při otevření stránky v novém panelu dojde k oddělení obou objektů v paměti. Nebudou mít spolu nic společného. Pokud byste to neudělali, zůstane tam nějaká reference, která se dá později zneužít k útokům.

Hlavička Cross-Origin-Embedder-Policy nastavená na hodnotu require-corp zase říká, že abych do svého webu mohl vložit nějakou jinou stránku, musí mi daná stránka vložení povolit. To je možné provést pomocí další hlavičky Cross-Origin-Resource-Policy s hodnotou cross-origin. Tyto dvě hlavičky tedy spolupracují.

Lepší testování WebAuthn

Světem se šíří dvoufaktorová autentizace pomocí různých hardwarových tokenů. Doposud bylo pro vývojáře komplikované takovou funkci testovat, ale do Chrome přichází možnost zapnout si ve vývojářských nástrojích virtuální autentikátor, který emuluje funkci nejrůznějších tokenů připojených různými způsoby.

Android má dnes softwarový token přímo zabudovaný a je možné se autentizovat pomocí Bluetooth. Je to standardní funkce, není to žádný hack. Můžete použít svůj telefon jako druhý faktor. Zatím to funguje jen v Chrome a proti službám firmy Google.