Vlákno názorů k článku Přechod Wikipedie na HTTPS pomohl v boji s cenzurou od hlupák - Hlupákův hloupý a polopatický dotaz k tématu všeobecně....

Ano, webový prohlížeč umožňuje prohlížeč web – to je vskutku nečekané. Na co by se prohlížeč měl uživatele ptát? Na to, jestli smí webová aplikace pracovat s daty, která jí uživatel zadal? „Napsal jste písmeno 'a'. Opravdu mám zadat písmeno 'a' do formulářového pole?“ „Pohnul jste myší. Opravdu chcete pohnout kurzorem myši?“ „Klikl jste na odkaz. Opravdu chcete navštívit odkazovanou stránku?“ Nebuďte troškař, dotáhněte to dál. Uživatel by měl písemně potvrdit každou instrukci procesoru před tím, než se provede.

Odeslání referreru je ale standardní akce, kterou dělá sám prohlížeč na všech stránkách (pokud není prohlížeč speciálně upraven). Odeslání kotvy přes AJAX je to samé, jako odeslání čísla karty – uživatel musí jít na stránku, která danou věc dělá (odesílá formulář nebo kotvu), a musí provést nějakou akci, kterou zadá ty údaje (napíše číslo karty do formulářového políčka, klikne na odkaz s kotvou).

Původní dotaz byl na to, co dělá obecně webový prohlížeč, třeba na Wikipedii. Máte pravdu v tom, že z hlediska bezpečnosti je často podstatnější to, co prohlížeč umožňuje dělat webovým stránkám, než to, co dělá samotný prohlížeč. Uživatel by měl ale počítat s tím, že cokoli zadá do webové aplikace, s tím si ta aplikace může dělat, co chce – ať to zadá jako text do formulářového pole, nebo to zadá jako kotvu kliknutím na odkaz, nebo to „zadá“ implicitně tím, že nad stránkou rejdí myší.

Asi se shodneme – z hlediska bezpečnosti není až tak podstatný defaultní stav (posílá se referer*, neposílá se location hash), jako spíš to, kdo to může ovlivnit (odesílání refereru může ovlivnit stránka, která stejně zná svoji URL; odeslání location.hash může ovlivnit server, který k tomu sám o sobě nemusí mít přístup). Plus je samozřejmě podstatné riziko opomenutí, ale to jsme někde jinde.

Nepovažuju to za zásadní problém, jen v kontextu vysvětlování toho, kdo má k čemu přístup, mi to přišlo trošku zavádějící.

*) Pro úplnost: ani toto neplatí úplně vždy, typicky při HTTPS –> HTTP

Nerozumím tomu, jaký je podle vás rozdíl mezi „serverem“ a „stránkou“. Referrer posílá prohlížeč automaticky, pokud tomu chce nějaký web zabránit, musí všechny externí odkazy přesměrovat přes server, který je anonymizuje. Hash naopak prohlížeč nikam neposílá, a pokud jej chce webová aplikace využít, musí ho naopak pomocí JavaScriptu aktivně přečíst.

Jako příklad byla v úvodním dotazu uvedena Wikipedie, a tam žádný skript odesílající hash není. Pokud se budeme bavit o tom, co mohou udělat skripty, tak skript má přístup k celé adrese ak celému obsahu stránky. Takže se někam můžu připojit přes HTTPS bez SNI, ISP uvidí jen DNS překlad a pak šifrovanou komunikaci s IP adresou, ale neuvidí ani doménový název v té komunikaci, ani adresu, ani obsah stránky. A pak se na té stránce spustí skript, který celou adresu i obsah stránky někam pošle po HTTP. A ISP uvidí vše, co před ním předtím bylo díky HTTPS skryté. Možné to samozřejmě je, ale myslím, že je to něco jiného, než na co se ptal ten původní dotaz. Takže pořád nevím, v čem vidíte ten rozdíl, zda skript spuštěný na stránce má přístup k hashi v URL, nebo zda má stránka přístup k vyplněnému formuláři, cookies, rozměrům stránky, událostem klávesnice a myši a spoustě dalších věcí…

> Nerozumím tomu, jaký je podle vás rozdíl mezi „serverem“ a „stránkou“.

Server posílá prohlížeči stránku.

> Referrer posílá prohlížeč automaticky, pokud tomu chce nějaký web zabránit, musí všechny externí odkazy přesměrovat přes server, který je anonymizuje.

Ano (a lze to i skrze nějaký meta tag), podstatné je, že tady o tom rozhoduje držitel citlivé informace – server, který URL tak jako tak zná. Cílovému serveru pak referer nemusí být vůbec dostupný a ani nemusí mít možnost se k němu dostat.

> Hash naopak prohlížeč nikam neposílá, a pokud jej chce webová aplikace využít, musí ho naopak pomocí JavaScriptu aktivně přečíst.

Z hlediska bezpečnosti není moc podstatné, že se tak nestane defaultně. Podstatné je, že server má možnost location.hash zjistit a standardně (se zapnutým JS atd.) tomu nezabráníme.

> neuvidí ani doménový název v té komunikaci

Uvidí minimálně certifikát (i kdyby neviděl DNS), a z něj lze doménové jméno obvykle vyčíst nebo odhadnout. Ano, wildcard a multidomain certifikáty to kompolikují.

> A pak se na té stránce spustí skript, který celou adresu i obsah stránky někam pošle po HTTP.

To už je trošku jiný druh hrozby – někdo, komu jsem tu komunikaci vědomě (přímo či nepřímo) svěřil, ji nepohlídal dostatečně. Do toho spadá i leaknutý serverový klíč.

Pokud ale budeme předpokládat, že location.hash se na server neposílá, může nás překvapit, že se k tomu může server dostat. Tzn. někdo, komu jsme informaci svěřit nechtěli, se ji dozví přímo od nás.

O posílání referreru ale nerozhoduje server, posílá ho prohlížeč. Úplně stejně, jako může prohlížeč někam odeslat kotvu, může odeslat i zbytek URL (tedy referrer).Server sám o sobě nemá možnost kotvu zjistit. Server má možnost poslat v rámci webové stránky do prohlížeče skript, který může zjistit spoustu informací, a může je poslat zpět serveru, nebo kamkoli jinam – to už ale není vlastností komunikace nebo prohlížeče, ale toho webu, který uživatel prohlíží. Server takhle dokonce může poslat spustitelný kód, který po spuštění uživatelem zformátuje disk nebo zašifruje jeho soubory. Ale to nijak nesouvisí s tím, co je vidět v rámci HTTPS komunikace prohlížeče se serverem.

Pokud ale budeme předpokládat, že location.hash se na server neposílá, může nás překvapit, že se k tomu může server dostat. Tzn. někdo, komu jsme informaci svěřit nechtěli, se ji dozví přímo od nás.
To je ale chybný předpoklad, že můžu poskytnout webové stránce nějaké informace, aniž by měl možnost získat je server. Ne, webový server má nad stránkou plnou kontrolu, a co té webové stránce svěřím, to může znát i server. Což je třeba důvod, proč správná implementace přihlašování na webu by byla taková, že heslo by se zadávalo do prohlížeče (ne webové stránky) a už prohlížeč by z něj spočítal jednorázový hash, který by teprve předal webové stránce. Jakmile dnes zadám heslo v otevřeném tvaru do webové stránky, musím počítat s tím, že to heslo v otevřeném tvaru zná i server.

Na úrovni protokolu HTTP(S) není snad ani kotva definovaná (snad jen v URI scheme), takže zde to IMHO nemá smysl řešit.

Na úrovni prohlížeče naopak dává smysl řešit, co umějí skripty.

> To je ale chybný předpoklad, že můžu poskytnout webové stránce nějaké informace, aniž by měl možnost získat je server.

Běžně ano, ve speciálních případech je to OK: Mohu vypnout JS nebo vyřešit všechny potenciální odchozí kanály (síť, CPU cache, zvuk, …).

Co se týče hesel, celkem souhlas.

Na úrovni prohlížeče naopak dává smysl řešit, co umějí skripty.
To ano, ale je to už zcela mimo původní dotaz. A získání kotvy je podle mne prkotina proti tomu, co všechno webovým stránkám prozrazujeme.

Původní dotaz byl v kontextu prohlížeče. Je fakt, že zmiňoval, že ho nezajímá, co se dozví koncový server. Ale když už to tu bylo nakousnuto, upřesnil jsem to.