Vlákno názorů k článku V datových schránkách je nepříliš bezpečná novinka. DIA ji ale zdůvodňuje „zvýšením bezpečnosti“ od Uncaught ReferenceError: - mě vždy děsí, že tady nám někteří vlastně...

mě vždy děsí, že tady nám někteří vlastně říkají, že IT bezpečnost je založena na tom, že neotevřu špatný odkaz. Útočník má přitom miliony cest, jak mě dostat na špatný web, ať už to jsou všude přítomné reklamy, na které se někdy prostě nedá nekliknout, ať už to jsou skripty třetích stran a běžných "bezpečných" webech nebo to mohou být úspěšné útoky na existující weby a pozměnění obsahu.

Dokud tady všichni budou akceptovat bezpečnost, že nic špatného neotevřu, neposuneme se dál. Systémy musí být dostatečně bezpečné a zvládnout otevření čehokoliv. Přenášet takhle vinu na uživatele, který vlastně není schopný z odkazu nic posoudit je dost šílené, alibistické a špatné.

Nesmysl je učit uživatele rozpoznávat phishing podle aktivních odkazů v e-mailu. Když budou všichni posílat e-maily s textovými odkazy, které budou uživatelé kopírovat, podvodníci se přizpůsobí a budou phishingové odkazy posílat stejným způsobem. Výsledkem je akorát snížení komfortu pro uživatele.

Aktivní odkaz v notifikačním e-mailu je jen pro pohodlí uživatelů – ale těm, kteří se chovají bezpečně, nijak neuškodí. A uživatelům, kteří se nechovají bezpečně, nepomůže ani kdyby byl neaktivní, ani kdyby tam nebyl vůbec. Pro větší komfort by odkaz ještě mohl vést přímo na konkrétní datovou zprávu – ovšem problém je, že ze zákona se považují přihlášením za doručené všechny, protože se předpokládá, že uživatel po přihlášení viděl seznam nedoručených zpráv.

Bez odkazů v e-mailech se obecně neobejdeme, protože e-maily se považují za hlavní identifikátor osob na internetu. Každý web, který používá e-mail, musí umět ověřit, že dotyčný je opravdu vlastník dané e-mailové schránky. Což jde rozumně udělat akorát odkazem. A nemá smysl to uživatelům komplikovat neaktivním odkazem.

Ale hlavně, co se týká obrany před phishingem – je nesmysl učit uživatele, že mají kontrolovat adresu u zdroje. To nefunguje. Uživatel musí kontrolovat adresu v okamžiku, kdy má zobrazenou cílovou stránku v prohlížeči – tu stránku, která je bezpečnostně citlivá, třeba taková, kde se uživatel přihlašuje. Je to nepohodlné, ale funguje to – na rozdíl od kontroly odkazu u zdroje, která nefunguje.

Dále je obranou proti phishingu používání správce hesel, který vyplní heslo jen do správné cílové stránky. Tj. musí být integrován v prohlížeči, žádné kopírování hesla přes schránku.

A pak samozřejmě pomáhají jiné autentizační mechanismy, než je jen jméno a heslo. Je nepochopitelné, že před lety ISDS zrušil možnost používání druhého faktoru TOTP, když zůstala možnost přihlášení jen jménem a heslem. Navíc TOTP dnes podporuje kdejaký web, někde je to dokonce už vyžadováno (nebo nějaký jiný alespoň stejně bezpečný způsob přihlášení). Pro spoustu uživatelů je pořád TOTP ten nejjednodušší způsob, jak výrazně zvýšit zabezpečení.

Říkáte "Král je nahý!" a já já dodávám, že navíc i smrdí.

Už na úrovni základních koncepčních návrhů fungování browserů a www ekosystému je hodně věcí "špatně", protože od dob Mosaicu sira Tima se jejich funkčnost a význam posunuly výrazně jinam. Jsou "operačním systémem" webových aplikací a služeb, ale v mnoha aspektech ustrnuly principy a fungováním někde na konci devadesátek.

Nejde pořád házet bezpečnost na stranu znalostí uživatelů. Je třeba to stavět bezpečně už od základů a měla by se prosazovat promyšlená řešení, která bezpečnost efektivně podpoří na nižších úrovních. (brainstormingový nástřel) Například v rámci browseru udělat významnou hranici mezi běžným prohlížením stránek a přístupem k službám, které potřebují vyšší úroveň ochrany. A nemyslím tím vynucený dvoufaktor, ani malou ikonku někde v rohu, ale spíš panel/rozcestník pro přístup k ověřeným službám, do kterého půjde přidávat jen zabezpečeným způsobem.

Za velký problém považuji, že zde není oficiální, otevřená platforma, na které by se takové koncepční otázky řešily a tak, když vás nějaký "nachytřalý rychlokvašný" bezpečák z vaší oblíbené banky bude přesvědčovat, že je nutné, aby vás po 5 minutách nečinnosti jejich aplikace odhlásila, protože to ultimátně zvyšuje bezpečnost a navíc jim to prý nařizuje zákon, nemáte moc možností tenhle tupý postoj postavit pod světlo odborné diskuze, po které by přišla i náprava.

Maskotem tragického stavu je cookies lišta, která se vám denodenně směje do xichtu a při jejímž zobrazení pokaždé někde na světě zemře nejméně jedno koťátko.

Na tom je jediné správné to https. Nebo už prohlížeče defaultně doplňují https a ne http? Ale jinak je to úplný nesmysl. Pokud nějaký web navštěvuji opakovaně a je tam důležitá bezpečnost, je potřeba ho mít v záložkách (oblíbené) v prohlížeči a chodit na něj přes ně (což může být i přes našeptávání v adresním řádku prohlížeče). To zabrání překlepům.

Většina prohlížečů má adresní a vyhledávací řádek sdružený, takže radit psát něco do adresního a ne vyhledávacího řádku je hraběcí rada.

Ale hlavně – všechny tyhle rady, jako používat oblíbené, psát adresy ručně, psát https apod., zvyšují bezpečnost v rozmezí někde tak 0–10 bodů, zatímco použití správce hesel integrovaného do prohlížeče ji zvýší o 100 bodů. školení o bezpečnosti by se mělo věnovat hlavně tomu.

Jestli někdo dneska bezpečnost řeší stejně, jako v dobách Internet Exploreru, tak doufám, že neřeší požární bezpečnost. Požární hlásiče by neřešil, ale za to by řešil, kam se přivážou koně, kteří přitáhnou hasičskou stříkačku.

Na školení o bezpečnosti nám vysvětlovali, že odkaz je potřeba ručně napsat do adresního (nikoliv vyhledávacího!) řádku v prohlížeči, a to včetně (!) https://.
Pak se školitel zeptal, kdo z nás to poctivě dělá... Byl jsem jediný!

Ony ani ty Oblíbené nejsou kdovíjak bezpečné - v práci jsme řešili problém se zlovolným scriptem, který je vcelku úspěšně generoval/pře­pisoval.
Takže osobně doporučuji mít nějakou statickou stránku s rozcestníkem právě na ony často navštěvované weby. Žel, problém s odkazy na ty nenavštěvované to neřeší.
Sloučení adresního a vyhledávacího řádku považuji za téměř zločinné. Já to v prohlížeči udržuji rozdělené, ale třeba v práci nám tohle blokuje firemní politika. ;-( Takže otevírám odkazy zásadně z příkazového řádku: chrome "https://lupa­.cz/". Výhodou je, že to pak najdu v historii - k opakovanému použití nebo k analýze.

Bezpecaci v cele rade instituci ale presne takhle funguji :-) Aneb resit uvaz pro toho kone je vyrazne jednodussi nez resit EPS.

Zrovna před naší budovou je vyhrazené místo pro případný požární zásah - a ten úvazek pro koně by se tam našel. (Respektive: když se nedaleko konala historická vojenská přehlídka, tak tam kavalérie ty koně uvázané měla.) ;-D

Problém s bezpečností je ten, že musíte řešit i to, co v dobách Internet Exploreru, protože nikdy nemůžete vědět, zda se moderní prohlížeče někdy nezachovají kompatibilně.

Coz typicky zacne narazet v momente, kdy tvurci webove aplikace jebne v lebce a rozhodne se menit hostname. Bohuzel to se deje take vcelku casto - a samozrejme ostrazitost beznych frantu uzivatelu to muze otupit. Treba takovy oracle umi mit hostname stylem idcs-bc771da0a20c4­9gcb6cf695bbc7d0c85­.identity.ora­clecloud.com.­... asi jim to prijde vic sekjur! :D

IMHO je celý sandboxing> (jedno, zda na Windows, Linuxu, či libovolném jiném OS) snahou řešit problém, který by vůbec nemusel existovat, poněkud pozdním řešením. Ono by úplně stačilo, kdyby procesy z principu neviděly jinam, než na své potomky a svého rodiče - a kdyby třebas jednotlivá okna v prohlížeči skutečně byla jako samostatný proces.
Pak by se dala nežádoucí komunikace poměrně snadno zatrhnout.
Žel, desítky let se tu buduje interoperabilita aplikací, často skoro za každou cenu - takže se nelze divit, že všichni smí všechno. Úplná aplikační anarchie.

Zrovna co se týče bezpečnosti jsou na tom mobilní prohlížeče ještě podstatně hůř než desktopové. Integrace se správci hesel problematičtější, adresní řádek věčně schovaný, takže https ani doménu nezkontrolujete. Podívat se na certifikát jsem v mobilním prohlížeči snad ani nikdy nezkoušel, přeci jen mám jakýsi pud sebezáchovy.

A že by místo toho, mobily nabízely jiné zabezpečení, to rozhodně neplatí. Maximálně udělat místo webu nativní aplikaci. Jenže Google prosazuje opačný směr, použít místo aplikací web všude kde to jde. A případně udělat z webu aplikaci pomocí PWA.

Nějaké izolace procesů a podobné věci jsou z hlediska bezpečnosti takové vychytávky pro fajnšmekry. Většina útoků na uživatele necílí na to, probourat se ven z jeho prohlížeče do systému, ale dostat se skrze prohlížeč na jeho bankovní konto, kartu nebo aspoň sociální síť.

Ukazuje to, že IT bezpečnost už je mainstream. Takže jako u jiných oborů se mainstreamem šíří „zaručené“ informace, které částečně platily kdysi dávno, ale dnes už dávno neplatí. A je spousta „odborníků“, kteří tyhle velmi zastaralé informace šíří jako nejnovější pokrok vědy.

Ony ani ty Oblíbené nejsou kdovíjak bezpečné - v práci jsme řešili problém se zlovolným scriptem, který je vcelku úspěšně generoval/pře­pisoval.
To ovšem nebyl skript ve webové stránce, ale buď nějaké napadené rozšíření prohlížeče nebo vir v operačním systému.

Problém s bezpečností je ten, že musíte řešit i to, co v dobách Internet Exploreru, protože nikdy nemůžete vědět, zda se moderní prohlížeče někdy nezachovají kompatibilně.
Ne, to rozhodně není pravda. Takhle prohlížeče nefungují a nikdo to tak nedělá. Nebo snad řešíte, co kdyby nějaký prohlížeč začal podporovat VBScript, ActiveX, Flash?

No, já rozhodně ne, od toho máme bezpečáky - já na to nejsem dostatečně kvalifikovaný (myšleno paranoidní).
Každopádně jistojistě vím, že tam nějaká aktivní pravidla na VBScript a ActiveX (a ještě přihodím Java Applety) máme - a občas si o ně nabijeme hubu, když blokují víc, než by měla (nebo jen udělají falešný poplach).

Tak na ty věci, kam chodím, mám uložené v PM. A to mi nedovolí vyplnit heslo, pokud je URL jiná než uložená....

Myslel jsem, že jsem to v předchozím komentáři napsal jasně. O tom, jak funguje izolace aplikací na mobilních OS samozřejmě vím. Ale také vím, jaké útoky se reálně dějí. Útočníci se snaží zmanipulovat uživatele k tomu, aby jim dal přístup k bankovnímu účtu, nebo aspoň potvrdil jejich transakci. Jak proti tomu pomůže izolace aplikací v OS? Vůbec nijak.

Bavíme se o situaci „neklikat na odkazy, které se tváří, že vedou na web, který známe, ale ve skutečnosti vedou jinam“. A tam jinde bude web, který bude vypadat naprosto stejně, jako ten web, kam uživatel chtěl jít. Akorát ho bude manipulovat k vydání údajů pro přihlášení do banky. Proto jsou datové schránky jedním z cílů – protože tam je přihlášení přes NIA, tedy i přes bankovní identitu, a spoustu lidí falešný web úspěšně povede na přihlášení do jejich banky – ovšem na podvodném webu.

Ty útoky zaměřené na datové schránky fakt nejsou zaměřené na to, že byste se dostal na nějaký web, který se bude pokoušet prolomit zabezpečení prohlížeče. Prostě proto, že prohlížeče jsou už dost odolné, na rozdíl od uživatelů. Pokud už někdo umí prolomit zabezpečení prohlížeče, použije to na sofistikovanější útok, než se snažit obrat babičku o to, co má naspořeno na pohřeb.

Například v rámci browseru udělat významnou hranici mezi běžným prohlížením stránek a přístupem k službám, které potřebují vyšší úroveň ochrany.
To nelze, ta hranice neexistuje – je to spojitá škála.

Je ale pravda, že základy, které jsou v prohlížečích dostupné pro autentizaci uživatelů, jsou tragické – přitom by bylo velmi jednoduché to udělat lépe. Za prvé, přihlášení uživatele heslem se řeší formulářem ve webové stránce, takže k heslu má stránka a všechny skripty na ní přístup. Přitom v protokolu HTTP existoval prostředek, jak to obejít – jen byl v prohlížečích implementován hrozně, a chyběla mu část pro registraci. To se dnes pomaličku nahrazuje passwordless řešeními, takže nějaký pokrok tu je. S třicetiletým zpožděním.

Další problém je autentizace už přihlášeného uživatele. Na výběr je uložení do sessison storage, což bezpečnostní odborníci nedoporučují, nebo cookies, což je taková hrůza, že se o ní bezpečnostní odborníci raději ani nevyjadřují. Přitom by to opět bylo řešitelné podobným způsobem – bezpečnostně citlivé informace by byly uložené v prohlížeči v oddělené části, stránka ani JavaScript by k nim neměl přístup, pouze by mohl dát pokyn, ať se přibalí do hlavičky požadavku. Prohlížeč by kontroloval origin a nedovolil by přibalit informace, na které nemá stráka nebo cíl nárok.

desktop umírá a web jak ho známe také.

Dnes bezpečnost prohlížení řeší a posouvají zejména mobilní OS. Prohlížeč je tam lépe integrovaný s OS, lépe se tam řeší přístupy do dalších procesů, lépe se tam řeší bariéra mezi OS a prohlížečem. Škoda, že Android je pořád v řadě věcí dost pozadu, ale aspoň jde vidět posun u každé verze.

Desktop je mrtví. Windows sandbox nikdy nefungoval a fungoval nebude dokud nezahodí podporu starých "eval" rozhraní. Linux nikdy neměl ambice dělat nějak rozumně aplikační sandbox, všechny GUI aplikace běží pod jedním uživatelem a celý linux je založen na izolaci uživatelů. Xka neřeší bezpečnost mezi aplikacemi, Wayland trochu jo, ale velmi málo, paradoxně situaci pomáhá třeba snap, protože aspoň aplikace běží pod jiným uid, ale pořád to není žádná výhra. MacOS v tom postupuje asi nejlépe, ale pořád to je slabý odvar proti možnostem mobilních OS.

Je to paradoxní, dneska nemáme možnost jak zabezpečit webovou aplikaci v desktop OS, stejně tak nemáme možnost, jak desktop OS ochránit před webovou aplikací. Chrome jak lídr vývoje browserů přidává jednu integraci za druhou, každá otevírá nepřeberné množství nových bezpečnostních problémů.

Izolace procesů je jen jeden dílek skládačky, byť důležitý.

V Linuxu běžně používám spouštění více profilů FF, v případě potřeby lze spouštět i pod různými uživateli.

Ale není to doladěné pro běžné použití.

Já to neriskuji a obvykle otevírám stránky jako parametr podaný prohlížeči: chrome "https://lupa.cz/. ;-D

No - v dobách Internet Exploreru to šlo i scriptem ze stránky. ;-D
Nicméně tohle byla věc v MS Wordu, která měla - keomě jiného - aktualisovat odkazy ve firemním prohlížeči. Akorát to bylo blbě implementované, a trochu se to zvrhlo. Následoval pokus řešit to přes Active Directory, ale to nebylo zcela ideální, takže nakoec se to opustilo s tím, že doporučujeme Oblíbené vůbec nepoužívat (především proto, že ty oblíbené odkazy se interně poměrně často mění).

vybral jsi si jeden typ útoku a točíš se kolem něho. Obecné doporučení v oboru, abys neklikal na cizí odkazy není jen MitM nebo phishing, ale i kvůli jiným vylomeninám, malwerům, cryptověcem atd. atd.

Vybral jsem si ten zdaleka nejrozšířenější typ útoku. Ano, to doporučení se týká i jiných typů útoků, což nemění nic na tom, že je to nesmysl.

No až na to, že teraz adresné a vyhľadávacie pole výrobcovia prehliadačov obvykle zlúčili do jedného políčka, ktoré niekedy otvorí internetovú adresu a niekedy vyhľadávač s danou frázou, niekedy háda, čo to má byť.
Že to https zabráni nejakému nesprávnemu "pochopeniu" prehliadačom by som sa veľmi nespoliehal.

Bezpečnost mobilních browserů posuzuješ podle správce hesel a adresního řádku? :) Jako vážně? To přece neurčuje jak je samotný prohlížeč bezpečný a kolik má potenciálních skulin.

Jak moc víš o tom jak vlastně fungují na mobilních OS procesy, jejich oddělení a jejich komunikace? Předpokládám, že tohle znáš z desktop OS dobře.

Mno, právě na izolaci celá bezpečnost systémů přece visí. Izoluji procesy od syscallů, izoluji procesy od HW zařízení, izoluji OS od některých registrů atd. atd. Nemůžeš přece tvrdit, že nepotřebuješ izolaci služeb a procesů mezi sebou, když útočníci ti napíšou a ty jim pošleš peníze sám. Bavíme se o situaci, kdy se doporučuje neklikat na "neznámé či nebezpečné odkazy".