Hlavní navigace

Názor ke zprávičce Chrome postupně odstraní zámeček pro HTTPS v adrese od Vít Šesták - Připojují se ty stroje ke stejným URL jako...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 19. 5. 2018 8:10

    Vít Šesták

    Připojují se ty stroje ke stejným URL jako lidi? Nebo jen k nějakému API, které možná stránka na pozadí používá, ale nejde o URL, o které by věděl uživatel (pokud si neotevře zdroják nebo developre console nebo podobně)? Pak by bylo asi nejelegantnější z přejměrování pár URL vyjmout. (Pokud vyjmete i obrázky, zavádíte duplicitní obsah, ale u obrázků by to mohlo být ještě snesitelné.)

    Detekce UA se taky nabízí, jak tu někdo zmiňoval. Je to sice trochu hack, ale snad celkem akceptovatelný. Redirect u wgetu bych za moc důležitý nepovažoval.

    Dal by se udělat i oportunistický upgrade pomocí JS spolu s HSTS, ale to bych bral jako poslední variantu. Přináší to některé problémy, například:

    * Pomalejší první redirect.
    * Duplicitní obsah pro vyhledávače.
    * Když budete generovat URL třeba do e-mailu, kterou variantu zvolíte? Pokud máte aplikaci zcela ve své režii, je to ještě v pohodě (no, framework může trochu působit potíže), u hotové aplikace to může vyžadovat ošklivé hacky.

    (Bez HSTR budou nevýhody výraznější – jak výkonově, tak bezpečnostně.

    Dvě varianty webu (HTTP a HTTPS) bez oportunistického upgrade přinášejí ještě více problémů, například:

    * Duplicitní obsah i pro uživatele. Například: Dělám společnou objednávku, dám zboží do košíku (HTTPS), dostanu od někoho link (HTTP), kliknu na něj a vidím prázdný košík. (Podobný problém můžete také mít u variant s „www.“ a bez „www.“.)
    * Varianta s HTTP může nastavit cookie variantě s HTTPS. Uživatel tak může být například nechtěně přihlášen útočníkem na síti. Dopad je stejný jako u https://support.detectify.com/customer/portal/articles/1969819-login-csrf , liší se jen způsob provedení. Nabízí se i vyšší náchylnost k session fixation, ale to lze ošetřit.