Sdílet prostřednictvím

Práce se soubory cookie SameSite v ASP.NET

Autor: Rick Anderson

SameSite je koncept standardU IETF navržený tak, aby poskytoval určitou ochranu před útoky csrf (cross-site request forgery). Návrh standardu byl původně vypracován v roce 2016 a v roce 2019 byl aktualizován. Aktualizovaný standard není zpětně kompatibilní s předchozím standardem, přičemž nejvýraznějšími rozdíly jsou následující:

  • Soubory cookie bez hlavičky SameSite se ve výchozím nastavení považují za SameSite=Lax soubory cookie.
  • SameSite=None musí být použita k povolení použití souborů cookie mezi weby.
  • Soubory cookie, které tvrdí SameSite=None , musí být také označeny jako Secure.
  • U aplikací, které používají <iframe> soubory cookie, sameSite=Strict může docházet k problémům se sameSite=Lax soubory cookie, protože <iframe> se považují za scénáře mezi weby.
  • Hodnota SameSite=None není povolena standardem 2016 a způsobuje, že některé implementace zacházejí s těmito soubory cookie jako SameSite=Strict. Viz Podpora starších prohlížečů v tomto dokumentu.

Nastavení SameSite=Lax funguje pro většinu souborů cookie aplikací. Některé formy ověřování, jako je OpenID Connect (OIDC) a WS-Federation , mají výchozí hodnotu přesměrování na základě POST. Přesměrování na základě POST aktivují ochranu prohlížeče SameSite, takže sameSite je pro tyto komponenty zakázaný. Většina přihlášení OAuth není ovlivněna rozdíly ve způsobu toku požadavků.

Každá komponenta ASP.NET, která generuje soubory cookie, musí rozhodnout, jestli je sameSite vhodná.

Informace o problémech s aplikacemi po instalaci aktualizací .NET SameSite 2019 najdete v tématu Známé problémy .

Použití SameSite v ASP.NET 4.7.2 a 4.8

.Net 4.7.2 a 4.8 podporuje koncept standardu 2019 pro SameSite od vydání aktualizací v prosinci 2019. Vývojáři můžou programově řídit hodnotu hlavičky SameSite pomocí vlastnosti HttpCookie.SameSite. SameSite Nastavení vlastnosti na Strict, Laxnebo None způsobí, že se tyto hodnoty zapíšou do sítě pomocí souboru cookie. Nastavení na hodnotu rovno (SameSiteMode)(-1) značí, že do sítě se souborem cookie nesmí být zahrnuta žádná hlavička SameSite. Vlastnost HttpCookie.Secure nebo requireSSL v konfiguračních souborech lze použít k označení souboru cookie jako Secure nebo ne.

Nové HttpCookie instance budou ve výchozím nastavení a Secure=falseSameSite=(SameSiteMode)(-1) . Tyto výchozí hodnoty je možné přepsat v system.web/httpCookies části konfigurace, kde je řetězec "Unspecified" popisnou syntaxí pouze konfigurace pro (SameSiteMode)(-1):

<configuration>
 <system.web>
  <httpCookies sameSite="[Strict|Lax|None|Unspecified]" requireSSL="[true|false]" />
 <system.web>
<configuration>

ASP.Net také vydává čtyři vlastní specifické soubory cookie pro tyto funkce: anonymní ověřování, ověřování pomocí formulářů, stav relace a správa rolí. S instancemi těchto souborů cookie získanými za běhu lze manipulovat pomocí SameSite vlastností a Secure stejně jako s jakoukoli jinou instancí HttpCookie. Vzhledem k patchworku standardu SameSite jsou však možnosti konfigurace pro tyto čtyři funkce soubory cookie nekonzistentní. Níže jsou uvedené příslušné konfigurační oddíly a atributy s výchozími nastaveními. Pokud pro funkci neexistuje žádný SameSite atribut nebo Secure související atribut, funkce se vrátí k výchozím nastavením nakonfigurovaným v system.web/httpCookies části probírané výše.

<configuration>
 <system.web>
  <anonymousIdentification cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
  <authentication>
   <forms cookieSameSite="Lax" requireSSL="false" />
  </authentication>
  <sessionState cookieSameSite="Lax" /> <!-- No config attribute for Secure -->
  <roleManager cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
 <system.web>
<configuration>

Poznámka: Neurčené je v tuto chvíli k dispozici pouze pro system.web/httpCookies@sameSite uživatele. Doufáme, že v budoucích aktualizacích přidáme podobnou syntaxi k dříve zobrazeným atributům cookieSameSite. Nastavení (SameSiteMode)(-1) v kódu stále funguje na instancích těchto souborů cookie.*

Pokud toto téma čtete v jiném jazyce než v angličtině, dejte nám vědět v tomto problému s diskuzí na GitHubu , pokud chcete zobrazit komentáře ke kódu ve vašem rodném jazyce.

Změna cílení na aplikace .NET

Cílení na .NET 4.7.2 nebo novější:

  • Ujistěte se,web.config obsahuje následující: 

    <system.web>
  <compilation targetFramework="4.7.2"/>
  <httpRuntime targetFramework="4.7.2"/>
</system.web>

  • Ověřte, že soubor projektu obsahuje správnou verzi TargetFrameworkVersion:

    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

    Další podrobnosti najdete v průvodci migrací .NET .

  • Ověřte, že balíčky NuGet v projektu cílí na správnou verzi architektury. Správnou verzi architektury můžete ověřit prozkoumáním souborupackages.config , například:

    <?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.AspNet.Mvc" version="5.2.7" targetFramework="net472" />
  <package id="Microsoft.ApplicationInsights" version="2.4.0" targetFramework="net451" />
</packages>

    V předchozím souboru Microsoft.ApplicationInsightspackages.configbalíček:

    • Cílí na .NET 4.5.1.
    • Pokud existuje aktualizovaný balíček, který cílí na vaši architekturu, měl by mít targetFramework jeho atribut aktualizovaný na net472 .

Verze .NET starší než 4.7.2

Microsoft nepodporuje verzi .NET nižší než 4.7.2 pro zápis atributu cookie stejného webu. Nenašli jsme spolehlivý způsob:

  • Ujistěte se, že je atribut správně napsaný na základě verze prohlížeče.
  • Zachytávání a úprava souborů cookie ověřování a relací ve starších verzích rozhraní

Změny chování prosincových oprav

Konkrétní změna chování pro rozhraní .NET Framework spočívá v tom, SameSite jak vlastnost interpretuje None hodnotu:

  • Před opravou hodnota None znamená:
    • Negenerujte atribut vůbec.
  • Po opravě:
    • Hodnota None znamená "Generovat atribut s hodnotou None".
    • Hodnota SameSite způsobí (SameSiteMode)(-1) , že atribut nebude generován.

Výchozí hodnota SameSite pro ověřování formulářů a soubory cookie stavu relace se změnila z None na Lax.

Souhrn dopadu změn na prohlížeče

Pokud nainstalujete opravu a vydáte soubor cookie s SameSite.Nonenástrojem , stane se jedna ze dvou věcí:

  • Chrome v80 bude s tímto souborem cookie zacházet podle nové implementace a nebude pro soubor cookie vynucovat stejná omezení webu.
  • Každý prohlížeč, který nebyl aktualizován tak, aby podporoval novou implementaci, bude následovat podle staré implementace. Stará implementace říká:
    • Pokud se zobrazí hodnota, které nerozumíte, ignorujte ji a přepněte na stejná omezení webu.

Takže buď se aplikace v Chromu přeruší, nebo se rozbijete na mnoha dalších místech.

Historie a změny

Podpora SameSite byla poprvé implementována v .NET 4.7.2 pomocí konceptu standardu 2016.

Aktualizace pro Windows z 19. listopadu 2019 aktualizovaly .NET 4.7.2+ ze standardu 2016 na standard 2019. Další aktualizace jsou připravované pro jiné verze Windows. Další informace najdete v článcích znalostní báze, které podporují SameSite v rozhraní .NET Framework.

Návrh specifikace SameSite z roku 2019:

  • Není zpětně kompatibilní s konceptem 2016. Další informace najdete v části Podpora starších prohlížečů v tomto dokumentu.
  • Určuje, že SameSite=Lax se soubory cookie budou ve výchozím nastavení považovat za soubory cookie.
  • Určuje soubory cookie, které se explicitně uplatňují SameSite=None za účelem povolení doručování mezi weby, by měly být také označené jako Secure.
  • Je podporována opravami vydanými podle popisu v seznamu výše uvedených znalostní báze.
  • Je naplánované, aby chrome povolil ve výchozím nastavení v únoru 2020. Prohlížeče začaly na tento standard přecházet v roce 2019.

Známé problémy

Vzhledem k tomu, že specifikace konceptu 2016 a 2019 nejsou kompatibilní, přináší aktualizace rozhraní .NET Framework z listopadu 2019 některé změny, které můžou být zásadní.

  • Soubory cookie stavu relace a ověřování formulářů se teď do sítě zapisují jako Lax nespecifikované.
    • I když většina aplikací pracuje se SameSite=Lax soubory cookie, aplikace post na webech nebo v aplikacích, které je využívají iframe , můžou zjistit, že se soubory cookie autorizace formulářů nebo stavu relace nepoužívají podle očekávání. Pokud chcete tento problém vyřešit, změňte cookieSameSite hodnotu v příslušné části konfigurace, jak je popsáno výše.
  • Objekty HttpCook, které jsou explicitně nastavené SameSite=None v kódu nebo konfiguraci, teď mají tuto hodnotu zapsanou pomocí souboru cookie, zatímco dříve byla vynechána. To může způsobit problémy se staršími prohlížeči, které podporují pouze koncept standardu 2016.
    • Při cílení na prohlížeče podporující koncept standardu 2019 pomocí SameSite=None souborů cookie nezapomeňte je také označit Secure , jinak nemusí být rozpoznány.
    • Pokud se chcete vrátit k chování nepsat SameSite=Nonev roce 2016 , použijte nastavení aspnet:SupressSameSiteNone=trueaplikace . Všimněte si, že se to bude vztahovat na všechny objekty HttpCookies v aplikaci.

Informace o tom, jak Azure App Service konfiguruje chování SameSite v aplikacích .NET 4.7.2, najdete v tématu Azure App Service – Zpracování souborů cookie SameSite a oprava rozhraní .NET Framework 4.7.2.

Podpora starších prohlížečů

Standard SameSite 2016 nařídil, aby neznámé hodnoty byly považovány za SameSite=Strict hodnoty. Aplikace, ke kterým se přistupuje ze starších prohlížečů, které podporují standard SameSite 2016, se můžou porušit, když získají vlastnost SameSite s hodnotou None. Webové aplikace musí implementovat rozpoznávání prohlížeče, pokud mají v úmyslu podporovat starší prohlížeče. ASP.NET neimplementuje detekci prohlížeče, protože User-Agents hodnoty jsou vysoce nestálé a často se mění.

Přístup Microsoftu k řešení problému spočívá v tom, že vám pomůže implementovat komponenty detekce prohlížeče, které odeberou sameSite=None atribut ze souborů cookie, pokud je známo, že prohlížeč ho nepodporuje. Google radí vydávat dvojité soubory cookie, jeden s novým atributem a jeden bez atributu vůbec. Nicméně považujeme rady Společnosti Google za omezené. Některé prohlížeče, zejména mobilní prohlížeče, mají velmi malé omezení počtu souborů cookie, které může web nebo název domény odeslat. Odesílání více souborů cookie, zejména velkých souborů cookie, jako jsou ověřovací soubory cookie, může dosáhnout limitu mobilního prohlížeče velmi rychle, což způsobí selhání aplikací, která se obtížně diagnostikují a opravují. Kromě toho jako architektura existuje rozsáhlý ekosystém kódu a komponent třetích stran, které nemusí být aktualizovány tak, aby používaly přístup s dvojím souborem cookie.

Kód detekce prohlížeče použitý v ukázkových projektech v tomto úložišti GitHub se nachází ve dvou souborech.

Jedná se o nejběžnější agenty prohlížeče, u kterých jsme viděli, že podporují standard 2016 a u kterých je potřeba atribut úplně odebrat. Nejedná se o úplnou implementaci:

  • Vaše aplikace může vidět prohlížeče, které naše testovací weby nepoužívají.
  • Měli byste být připraveni přidat detekce podle potřeby pro vaše prostředí.

Způsob připojení detekce se liší podle verze rozhraní .NET a webového rozhraní, které používáte. Na webu volání HttpCookie je možné volat následující kód:

private void CheckSameSite(HttpContext httpContext, HttpCookie cookie)
{
    if (cookie.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.UserAgent;
        if (BrowserDetection.DisallowsSameSiteNone(userAgent))
        {
            cookie.SameSite = (SameSiteMode)(-1);
        }
    }
}

Projděte si následující témata týkající se souborů cookie ASP.NET 4.7.2 SameSite:

Zajištění přesměrování webu na HTTPS

Pro ASP.NET 4.x, WebForms a MVC je možné pomocí funkce přepsání adresy URL služby IIS přesměrovat všechny požadavky na HTTPS. Následující kód XML ukazuje ukázkové pravidlo:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect to https" stopProcessing="true">
          <match url="(.*)"/>
          <conditions>
            <add input="{HTTPS}" pattern="Off"/>
            <add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

V místních instalacích je přepsání adresy URL služby IIS volitelnou funkcí, kterou může být potřeba nainstalovat.

Testování problémů s SameSite v aplikacích

Aplikaci musíte otestovat v prohlížečích, které podporujete, a projít si scénáře, které zahrnují soubory cookie. Scénáře souborů cookie obvykle zahrnují

  • Přihlašovací formuláře
  • Mechanismy externího přihlášení, jako jsou Facebook, Azure AD, OAuth a OIDC
  • Stránky, které přijímají žádosti z jiných webů
  • Stránky v aplikaci navržené pro vkládání do elementů iframe

Měli byste zkontrolovat, jestli se soubory cookie ve vaší aplikaci správně vytvářejí, uchovávají a odstraňují.

Aplikace, které komunikují se vzdálenými weby, například prostřednictvím přihlášení třetí strany, musí:

Otestujte webové aplikace pomocí verze klienta, který se může přihlásit k novému chování SameSite. Chrome, Firefox a Chromium Edge mají nové příznaky funkce výslovného souhlasu, které se dají použít k testování. Jakmile vaše aplikace použije opravy SameSite, otestujte ji se staršími verzemi klienta, zejména Se safari. Další informace najdete v části Podpora starších prohlížečů v tomto dokumentu.

Testování pomocí Chromu

Chrome 78+ poskytuje zavádějící výsledky, protože má dočasné zmírnění rizik. Chrome 78+ dočasné zmírnění rizik umožňuje soubory cookie starší než dvě minuty. Chrome 76 nebo 77 s povolenými příslušnými testovacími příznaky poskytuje přesnější výsledky. Pokud chcete otestovat nové chování SameSite, přepněte chrome://flags/#same-site-by-default-cookies na Povoleno. U starších verzí Chromu (75 a nižších) se hlásí selhání s novým None nastavením. Viz Podpora starších prohlížečů v tomto dokumentu.

Google nezpřístupní starší verze chromu. Pokud chcete otestovat starší verze Chromu, postupujte podle pokynů v tématu Stažení Chromium. Nestahujte Chrome z odkazů poskytovaných vyhledáním starších verzí chromu.

Počínaje verzí 80.0.3975.0Canary je možné dočasné zmírnění rizik Lax+POST zakázat pro účely testování pomocí nového příznaku --enable-features=SameSiteDefaultChecksMethodRigorously , který umožní testování webů a služeb v konečném koncovém stavu funkce, u které bylo zmírnění rizik odebráno. Další informace najdete v tématu Aktualizace Chromium Projects SameSite.

Testování s Chromem 80 nebo novějším

Stáhněte si verzi Chromu, která podporuje jejich nový atribut. V době psaní tohoto článku je aktuální verze Chrome 80. Chrome 80 potřebuje k použití nového chování povolený příznak chrome://flags/#same-site-by-default-cookies . Pokud chcete otestovat nadcházející chování souborů cookie, které nemají povolený atribut sameSite, měli byste také povolit (chrome://flags/#cookies-without-same-site-must-be-secure). Chrome 80 je cílem provést přechod na zpracování souborů cookie bez atributu jako SameSite=Lax, i když s časovým obdobím odkladu pro určité požadavky. Chcete-li zakázat časové období odkladu, chrome 80 lze spustit pomocí následujícího argumentu příkazového řádku:

--enable-features=SameSiteDefaultChecksMethodRigorously

Chrome 80 obsahuje v konzole prohlížeče zprávy s upozorněním na chybějící atributy sameSite. Pomocí klávesy F12 otevřete konzolu prohlížeče.

Testování v Safari

Safari 12 striktně implementoval předchozí koncept a selže, když je nová None hodnota v souboru cookie. None se vyhnete prostřednictvím kódu pro detekci prohlížeče, který v tomto dokumentu podporuje starší prohlížeče . Otestujte přihlášení ve stylu operačního systému Safari 12, Safari 13 a WebKit pomocí MSAL, ADAL nebo jakékoli knihovny, kterou používáte. Problém závisí na základní verzi operačního systému. OSX Mojave (10.14) a iOS 12 je známo, že mají problémy s kompatibilitou s novým chováním SameSite. Upgrade operačního systému na OSX Catalina (10.15) nebo iOS 13 tento problém vyřeší. Safari v současné době nemá příznak výslovného souhlasu pro testování chování nové specifikace.

Testování pomocí Firefoxu

Podpora Firefoxu pro nový standard může být testována ve verzi 68+ tak, že se přihlásíte na about:config stránce s příznakem network.cookie.sameSite.laxByDefaultfunkce . Ve starších verzích Firefoxu nebyly hlášeny žádné problémy s kompatibilitou.

Testování v prohlížeči Edge (starší verze)

Edge podporuje starý standard SameSite. Edge verze 44+ nemá žádné známé problémy s kompatibilitou s novým standardem.

Testování pomocí Edge (Chromium)

Na stránce jsou nastavené edge://flags/#same-site-by-default-cookies příznaky SameSite. U edge Chromium nebyly zjištěny žádné problémy s kompatibilitou.

Test s elektronem

Verze Electronu zahrnují starší verze Chromium. Například verze electronu používaná teams je Chromium 66, což vykazuje starší chování. Musíte provést vlastní testování kompatibility s verzí electronu, kterou váš produkt používá. Viz Podpora starších prohlížečů.

Vrácení oprav SameSite

Aktualizované chování sameSite v aplikacích .NET Framework můžete vrátit k předchozímu chování, kdy se pro hodnotu Nonenevygeneruje atribut sameSite, a vrátit ověřovací soubory cookie a soubory cookie relace tak, aby hodnotu nevysílaly. To by mělo být považováno za velmi dočasnou opravu, protože změny Chromu narušují všechny externí požadavky POST nebo ověřování pro uživatele používající prohlížeče, které podporují změny standardu.

Vrácení chování rozhraní .NET 4.7.2

Aktualizujte web.config tak, aby zahrnovala následující nastavení konfigurace:

<configuration> 
  <appSettings>
    <add key="aspnet:SuppressSameSiteNone" value="true" />
  </appSettings>
 
  <system.web> 
    <authentication> 
      <forms cookieSameSite="None" /> 
    </authentication> 
    <sessionState cookieSameSite="None" /> 
  </system.web> 
</configuration>

Další materiály