nj. když sandbox není sandbox a dovoluje vzájemnou síťovou komunikaci mezi aplikacemi. To iOS neumožňuje.
Tomuhle sice teoreticky zabraňuje CORS, ale prohlížeče se v posledních letech utrhly ze řetězuje a generují nové funkce a rozhraní rychleji než se na to stačí dělat nějaké bezpečnostní bariéry, v tomhle případě za vše může RTC...
Už jen to jaké opičiny musí člověk na linuxu dělat, aby nějakou aplikaci a všechny její procesy síťově usměril a nemohli se dostat na nic vedle nich naznačuje, že tenhle typ zneužití bude možný všudemožně.
Spíš než to, že by iOS blokoval poslouchat na localhostu a jiným se na něj připojovat, je to o tom, že iOS aplikacím neumožňuje, že by na pozadí něco rezidentně běželo. Proto se pak stává, že do VLC se dá z počítače video nakopírovat přes web rozhraní (takže VLC si provozuje vlastní web server a dokonce se na něj může z venku připojit počítač), ale uživatel pak musí po dobu kopírování videa telefon "hladit", aby se neuspal a u toho čučet na progress bar a nejít si na telefonu prohlížet Facebook, jinak se kopírování přeruší.
Avšak tohle chování u běžných aplikací neimplikuje, že tam není nějaká cesta dostat lepší oprávnění, která nějakou background rezidenci umožní nebo že se requesty na localhostí server někde "cachují" a hezky se všechny odbaví, až se ta aplikace probudí - což se třeba děje, když přijde notifikace. Mimochodem "šmírování přes notifikace" je na iOS stále aktuální věc. Když notifikace obsahuje obrázek, tak ho iOS ihned načte. Odesílatel notifikace, pokud si tam vloží unikátní URL, se tak dozví, z jaké konektivity se uživatel připojuje a může ho tím trackovat. Jediná obrana proti tomu je aplikaci zcela sebrat oprávnění na notifikace (tedy ani žádný badge a zvuky)
Upřímně to nějak intenzivně nesleduji (nejsem web developer), ale nejsou ta rozhodnutí trochu komplikovaná kvůli tomu, že je potřeba vždycky najít nějaký rozumný kompromis mezi ochranou a uživatelskou použitelností dané technologie pro normální uživatele? V tom je to těžké.
Myslím, že tyhle stávající CORS ochrany nezabraly, protože skript na stránce posílal jen jednoduché GET requesty a neřešil čtení žádných odpovědí. Podobně pak když se zneužije nějaká první část handshake s různými dalšími protokoly (WebSocket, WebRTC) a zapečou se do toho data, co chce skript leakovat.
Zas vlastně nikdy nedojde k navázání komunikace (a spuštění nějakého ochranného mechanismu).
Velmi podobně to nedopadne pak když se ochrana postaví na nějakých dalších hlavičkách v odpovědi z aplikace (na jejichž port se skript připojuje). To možná zafunguje proti náhodnému skenování portů na localhostu nebo komunikaci s ostatními programy, co tam poslouchají.
Ale pokud má třeba Meta pod kontrolou jak ty skripty ze stránek, tak i aplikaci bokem, může si tam technicky vracet headery jaké chce.
Nevím, nejspíš přijdou na nějakou další ochran a zkusí tenhle způsob leakování dat odříznout, ale trochu se bojím, aby to s sebou nevzalo legitimní použití webového ovládání z prohlížeče pro lokální aplikace a služby, interakci přes websocket atp.
CORS ti ale zabrání i poslat GET, resp. vytvořit samotné spojení, nejen příjmout data, problém je, že je navázaný na konkrétní api v prohlížeči, takže když se přidalo RTC, CORS se o to nerozšířil. Těch "děr" kudy prohlížeč (resp. aplikace v něm) může s okolím komunikovat je strašně moc a přibývají několikrát ročně, vůbec není snadné prohlížeč dnes izolovat od OS.
Ochrana je jednoduchá, na úrovni Androidu nedovolit komunikaci aplikací navzájem na localhostu bez předem daných oprávnění. Tady výchozí aplikace mohla navázet síťové spojení s lokální aplikací. To by nemělo být možné nikdy.
pokud to je v rámci jedné aplikace, je to naprosto běžné a v pořádku, pokud to je mezi aplikacemi, na iOS na to potřebuješ extra oprávnění (takhle se třeba u nás chovají některé bankovní aplikace a jejich "klíče").
Tady to jde ještě dál, aplikace se vystavila otevřené porty do "světa" a mohla se na ní napojit jakákoliv jiná aplikace vč. JS aplikace běžící v prohlížeči. To spíše vypadá na bezpečnostní problém.
CORS povoluje server. Jestli ten jejich tajnej server poslouchajici na localhostu prilepi k odpovedi hlavicku "Access-Control-Allow-Origin: *", browser odpoved preda JavaScriptu, co odeslal ten request, bez mrknuti oka.
Z hlediska CORS problem nevidim. A CORS ani neni neco, co by v tomto pripade melo zajistit bezpecnost nebo zabranit smirovani.
Jako alarmujici vidim, ze embedded browsery v aplikacich Mety (ve vsech?) a Yandexu vkladaji smirovaci kod do stranek, co zobrazuji. Nepouzivam zadnou. Ale pro spoustu lidi jsou "nepostradatelne", takze sve chovani a data poskytuji Mete and Yandexu jako protisluzbu...
4. 6. 2025, 19:19 editováno autorem komentáře
To ale špatně chápeš. V prohlížeči otevřeš nějakou webovou stránku, ta obsahuje trackovací kód od FB a ten kód si volá localhost a posílá si tam identifikátory. V tomhle případě tomu může CORS zabránit, aby kód ze stránky se mohl připojit na localhost. Právě proto využili RTC protokol, u kterého se CORS nekontroluje.
V prohlížeči se ta stránka localhost vůbec neotevírá. Na tom portu není ani http, je tam webrtc a data se posílají jako atributy stun serveru.
> V tomhle případě tomu může CORS zabránit, aby kód ze stránky se mohl připojit na localhost.
Nemůže:
1. CORS je otázka nastavení serveru. To si ale může Meta udělat, jak se jim hodí.
2. CORS ničemu nebrání, naopak to povoluje.
3. CORS neřeší exfiltraci dat ze stránky na server. Naopak, CORS primárně řeší, jestli stránka může ze serveru přímo číst. OK, sekundárně může řešit některé druhy requestů, ale na exfiltraci dat bohatě stačí třeba GET request v obrázku, případně POST request skrze formulář do iframe. Možností je spousta.
> Právě proto využili RTC protokol, u kterého se CORS nekontroluje.
Čímž jste tak trochu načrtla můj bod 3.
Ale ty navštívené stránky nejsou načteny přes servery Mety, že? Jejich CSP (dobře, zmiňoval jsem pouze CORS, ale to je nepřesné, tady se obchází i CSP, pardon) nemá Meta pod kontrolou. Nezapomeň, bavíme se o navštívené webové stránce v mobilním prohlížeči.
Všechno, co píšeš je v pořádku. FB Pixem samozřejmě používá techniku načtení obrázku (GET), iframe a poslání dat přes něj atd.
Tady ale jde o úplně jinou věci a to je spojení identity. V mobilním prohlížeči zpravidla nejsi na FB přihlášený, protože na mobilu používáš jejich aplikace, takže poslání dat do FB nic moc neřeší. Tenhle mechanismus umožňuje právě té aplikaci poslat data o návštěvách, v aplikaci jsi přihlášený, takže tě mohou spárovat. Rozumíme si?
A proč nepoužívá GET, POST, iframe atd.? No, protože ta mobilní aplikace nemá platný http certifikát na localhost a http komunikace z webové aplikace je tak trochu problematická. RTC protokol umožňuje úvodní pakety poslat nešifrovaně.
Ano, píše. Ale nejsou to zranitelnosti jen iOS ale i aplikací. Hned na první stránce je uvedena i zranitelnost ve FortiProxy, kterou vůbec nainstalovaného na mobilu nemám.
Přijde mi, že jsou uvedeny všechny CVE včetně těch, které jsou už opravené. Zaujalo mě CVE https://www.cve.org/CVERecord?id=CVE-2025-24200, které už je opravené, jestli jsem správně pochopil.