Provozuji web v poměrně levném prostředí sdíleného hostingu (LAMP): technicky vzato, v této souvislosti jediné, co mohu udělat, je upravit jeden nebo více htaccess soubory.

Možná pro účely vyrovnávání zátěže hostitel slouží dvěma nezabezpečeným souborům cookie.

Existuje nějaký způsob, jak nastavit Secure vlajka na obou cookies z htaccess přepsat jejich původní hodnoty?

  • 1 Stranou: Z jakéhokoli důvodu tyto konkrétní soubory cookie potřeba být v bezpečí?
  • Dobrá otázka: tento web je https. Někdy web odesílám na Mozilla Observatory nebo na jiné podobné weby (securityheaders.io, další související s SSL atd.). Vždy hlásí stejnou vadu: web https podává nezabezpečené soubory cookie. Vidí to jako zranitelnost, i když v tomto případě pravděpodobně žádná zranitelnost vůbec neexistuje. Toto je tedy „problém“, na který obecně zapomínám, ale kdykoli ho znovu najdu, zkusím to vyřešit, možná jen pro zajímavost. :-)
  • 1 „Vidí to jako zranitelnost“ - To je jen (divoká) generalizace. Toto je přinejlepším upozornění / varování. Ne všechny soubory cookie by na webu HTTPS měly být nutně „zabezpečené“ (pokud to možná není jen HTTPS a nereaguje ani na HTTP). TBH, pokud se tento soubor cookie používá pro „vyvažování zátěže“, pak by pravděpodobně neměl být obsluhován příznakem „zabezpečený“, jinak nebude schopen „vyvažovat zátěž“ požadavků HTTP - což by mohlo mít nepříznivý dopad na výkon serveru. Například StackOverflow je pouze HTTPS a odesílá 16 souborů cookie, ale pouze jeden z těchto souborů cookie má nastaven příznak „zabezpečený“.
  • Existuje online skener, který považuje problém za „střední“ úroveň.Svými vlastními slovy: „Vzdálená webová aplikace nastavuje různé soubory cookie během neoverené a ověřené relace uživatele. Existují však případy, kdy aplikace běží přes nezašifrovaný protokol HTTP nebo soubory cookie nejsou označeny jako„ zabezpečené “, což znamená, že je prohlížeč mohl odeslat za určitých okolností zpět přes nezašifrovaný odkaz. V důsledku toho může být možné, aby vzdálený útočník tyto soubory cookie zachytil "," přidejte atribut secure do všech souborů cookie relace nebo souborů cookie obsahujících citlivá data. "
  • 1 „Prohlížeč by je za určitých okolností mohl odeslat zpět přes nezašifrovaný odkaz“ - I když ale implementujete HSTS, určitě tuto možnost minimalizujete.

tl; dr Pravděpodobně nemůžete udělat nic, abyste ovlivnili cookie hostitel nastavuje „pro účely vyrovnávání zátěže“.


Soubor cookie nastavený aplikačním serverem

Pokud se soubor cookie nastavuje na vašem aplikačním serveru, můžete případně zachytit odpověď a přepsat Set-Cookie Záhlaví odpovědi HTTP.

Například na základě odpovědi na StackOverflow by následující bezpodmínečně připojil Secure příznak při nastavování souboru cookie "MYCOOKIE" pomocí mod_headers Apache:

Header always edit Set-Cookie ^(MYCOOKIE=.+) '$1; Secure' 

Nebo na základě jiné odpovědi na ServerFault používá následující a negativní pohled nejprve zkontrolovat, zda Secure již není nastaven na cookie:

Header always edit Set-Cookie '(?i)^(MYCOOKIE=(?:(?!;\s?secure).)+)$' '$1; Secure' 

Cookie nastavený proxy / load balancerem

Pokud však cookie nastavuje nástroj pro vyrovnávání zatížení / proxy, který je mimo vaši kontrolu, pak výše uvedená metoda pravděpodobně nebude fungovat. A jakýkoli pokus o přepsání cookie může sám být znovu přepsán proxy serverem, v závislosti na tom, kdy proxy nastaví cookie.

Pomocí mod_rewrite můžete zkusit něco podobného, ​​ale mějte na paměti, že budete také muset ručně nastavit doména a cesta (a život) části cookie přesně stejné, jaké jsou nastaveny hostitel (např. kontrolou počátečního Set-Cookie Hlavička odpovědi HTTP, kterou vidíte v prohlížeči), jinak nepřepíše stejný soubor cookie. Například:

RewriteEngine On RewriteCond %{HTTP_COOKIE} (MYCOOKIE)=([^;]+) RewriteRule ^ - [CO=%1:%2:.example.com:1440:/:secure] 

%1 je zpětná reference k názvu souboru cookie (např. MYCOOKIE) v předchozím RewriteCond směrnice. A %2 je odpovídající hodnota. .example.com, 1440 a / jsou doména, život (v minutách) a Cesta URL souboru cookie, který se pokoušíte nastavit, a bude nutné jej nastavit ručně.

Jak však bylo uvedeno výše, nemusí to nic dělat, protože proxy to může jednoduše přepsat.

Odkaz:

  • https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_co
  • https://httpd.apache.org/docs/current/mod/mod_headers.html#header
  • Zapomněl jsem zmínit, že jsem první ze dvou nápadů zkusil bez štěstí. Zkusím to druhé, ale jsem pesimistický :-)
  • V zásadě dostanu chybu 500 po vyzkoušení druhého :-)
  • Ah promiň, měl by být = (ne :) bezprostředně po CO vlajka. Aktualizoval jsem svou odpověď.
  • Dobře, zde není žádná chyba, ale žádný účinek :-) Díky, každopádně!

Pracoval pro vás: Charles Robertson | Chcete nás kontaktovat?