Vlákno názorů k článku
Společnosti Meta a Yandex párují na Androidu chování v prohlížečích s identitami uživatelů od Uncaught ReferenceError: - nj. když sandbox není sandbox a dovoluje vzájemnou...

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

V původním článku se píše:

The researchers say it may be technically feasible to target iOS because browsers on that platform allow developers to programmatically establish localhost connections that apps can monitor on local ports.

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)

ale iOS na to potřebuje právo navíc a ještě k tomu se opakovaně ptá, jestli něco takového povolíš. Aspoň z mých experimentů. Je pak jedno, jaký protokol se na to použije. To je asi i důvod, proč něco takového na iOS facebook aplikace nedělá.

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.

Slovenska podpisova aplikacia tak funguje ze sa spaja s localhost-om kde bezi na pozadi Java program ktory robi sluzby podpisovania.

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.

Toto nemá nič spoločné so systémom... si tu len honíš jabĺčkarské ego, ale v jablku máš kopec iných zraniteľností ako obísť tieto veci. Jablko nie je o nič bezpečnejší než Android.

Byl by, prosím, nějaký konkrétní příklad? Rád si přečtu. Díky moc.

https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=iOS&field_date_added_wrapper=all&field_cve=&sort_by=field_date_added&items_per_page=20&url=

Aktuálně píše Showing 1 - 20 of 139

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.