Práce se soubory cookie SameSite v ASP.NET

Autor: Rick Anderson

SameSite je návrh standardu IETF navržený tak, aby poskytoval určitou ochranu před útoky CSRF (padělání žádostí mezi weby). Koncept normy byl původně navržen v roce 2016 a aktualizován v roce 2019. Aktualizovaný standard není zpětně kompatibilní s předchozím standardem, přičemž nejvýraznější 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.
  • Aplikace, které používají <iframe> , můžou mít problémy s sameSite=Lax soubory cookie nebo sameSite=Strict soubory cookie, protože <iframe> jsou považovány za scénáře mezi weby.
  • Hodnota SameSite=None není povolena standardem 2016 a způsobuje, že některé implementace zachází 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 aplikace. Některé formy ověřování, jako je OpenID Connect (OIDC) a WS-Federation, standardně používají přesměrování založené na POST. Přesměrování na základě POST aktivují ochranu prohlížeče SameSite, takže SameSite je pro tyto součásti zakázáno. Většina přihlášení OAuth nemá vliv na rozdíly ve způsobu toku požadavků.

Každá komponenta ASP.NET, která vytváří soubory cookie, se musí rozhodnout, jestli je SameSite vhodný.

Podívejte se na známé problémy s aplikacemi po instalaci aktualizací .Net SameSite 2019.

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 prostřednictvím kódu programu řídit hodnotu hlavičky SameSite pomocí vlastnosti HttpCookie.SameSite. Nastavení vlastnosti na hodnotu Strict, Lax nebo None způsobí, že tyto hodnoty budou zapsány na síť spolu se souborem cookie. Nastavením hodnoty (SameSiteMode)(-1) se rovná se značí, že žádná hlavička SameSite by neměla být zahrnuta na síti se souborem cookie. 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í SameSite=(SameSiteMode)(-1) a Secure=false. Tyto výchozí hodnoty je možné přepsat v system.web/httpCookies části konfigurace, kde je řetězec "Unspecified" popisnou syntaxí určenou pouze 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í soubory cookie pro tyto funkce: anonymní autentizace, autentizace formulářů, stav sezení a řízení rolí. Instance těchto souborů cookie získané v modulu runtime lze manipulovat pomocí SameSite vlastností a Secure vlastností stejně jako jakékoli jiné instance HttpCookie. Vzhledem k nepravidelnému vzniku standardu SameSite jsou však možnosti konfigurace pro tyto čtyři funkce týkající se souborů cookie nekonzistentní. Níže jsou uvedeny příslušné oddíly a atributy konfigurace s výchozími nastaveními. Pokud pro funkci neexistuje žádný SameSite nebo Secure související atribut, funkce se vrátí k výchozím nastavením nakonfigurovaným v system.web/httpCookies části uvedené 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: "Nezadané" je k dispozici system.web/httpCookies@sameSite pouze v tuto chvíli. 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 to č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 vidět komentáře ke kódu ve vašem nativním jazyce.

Změna cílení aplikací .NET

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

  • Ujistěte se, že 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 hodnotu TargetFrameworkVersion:

    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

    Průvodce migrací na .NET obsahuje další podrobnosti.

  • 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 souboru packages.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 packages.config souboru Microsoft.ApplicationInsights balíček:

    • Je určen pro .NET 4.5.1.
    • Pokud existuje aktualizovaný balíček zaměřený na váš cílový rámec, měl by být jeho atribut targetFramework aktualizován na net472.

Verze .NET starší než 4.7.2

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

  • Ujistěte se, že je atribut správně napsaný na základě verze prohlížeče.
  • Zachyťte a upravte ověřovací a relace soubory cookie ve starších verzích rámců.

Změny chování prosincových záplat

Konkrétní změna chování rozhraní .NET Framework je způsob, jakým SameSite vlastnost interpretuje None hodnotu:

  • Před opravou hodnota None znamenala:
    • Nevysílejte atribut vůbec.
  • Po opravě:
    • Hodnota None znamená "Vydat atribut s hodnotou None".
    • SameSite Hodnota (SameSiteMode)(-1) způsobí, že atribut se nevygeneruje.

Výchozí hodnota SameSite pro ověřování formulářů a relační soubory cookie byla změněna z hodnoty None na Lax.

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

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

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

Aplikace se tedy přeruší v Chromu, nebo se přeruší 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 z 19. listopadu 2019 pro Windows aktualizovaly .NET 4.7.2 nebo novější ze standardu 2016 na standard 2019. Další aktualizace jsou připravované pro jiné verze Windows. Další informace naleznete v článcích znalostní báze, které podporují SameSite v rozhraní .NET Framework.

Koncept specifikace SameSite z roku 2019:

  • není zpětně kompatibilní s návrhem z roku 2016. Další informace naleznete v tématu Podpora starších prohlížečů v tomto dokumentu.
  • Určuje, že soubory cookie jsou ve výchozím nastavení zpracovávány jako SameSite=Lax.
  • Určuje soubory cookie, které explicitně uplatňují SameSite=None , aby bylo možné povolit doručování mezi weby, musí být také označeny jako Secure.
  • Podporují se záplaty vydané podle popisu v znalostních bázích uvedených výše.
  • Ve výchozím nastavení má být Chrome povolen v únoru 2020. Prohlížeče začaly v roce 2019 přejít na tento standard.

Známé problémy

Vzhledem k tomu, že návrhy specifikací z roku 2016 a 2019 nejsou kompatibilní, přináší listopadová aktualizace .NET Framework 2019 některé změny, které mohou být přelomové.

  • Soubory cookie stavu relace a ověřování formulářů se nyní zapisují do sítě jako Lax místo nezadané.
    • I když většina aplikací pracuje se SameSite=Lax soubory cookie, aplikace, které používají metodu POST na různých webech nebo v aplikacích, které využívají iframe, mohou zjistit, že jejich soubory cookie pro stav relace nebo autorizaci formulářů nejsou používány podle očekávání. Chcete-li to napravit, změňte cookieSameSite hodnotu v příslušné části konfigurace, jak je popsáno dříve.
  • HttpCookies, které mají explicitně nastavenou hodnotu SameSite=None v kódu nebo konfiguraci, mají nyní tuto hodnotu uloženou do souboru cookie, zatímco dříve byla vynechávána. To může způsobit problémy se staršími prohlížeči, které podporují pouze verzi návrhu standardu z roku 2016.
    • Při cílení na prohlížeče, které podporují návrh standardu 2019 s cookies SameSite=None, nezapomeňte je také označit Secure, jinak nemusí být rozpoznány.
    • Pokud se chcete vrátit k chování z roku 2016, kdy se nepsalo SameSite=None, použijte nastavení aplikace aspnet:SupressSameSiteNone=true. Všimněte si, že to platí pro všechny httpCookies v aplikaci.

Informace o konfiguraci 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 vyžaduje, 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 přerušit, když získají vlastnost SameSite s hodnotou None. Webové aplikace musí implementovat detekci 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é odstraní sameSite=None atribut ze souborů cookie, pokud je prohlížeč známý, že ho nepodporuje. Google radili vydat dvojité soubory cookie, jeden s novým atributem a jeden bez atributu vůbec. Považujeme však rady společnosti Google omezené. Některé prohlížeče, zejména mobilní prohlížeče, mají velmi malá omezení počtu souborů cookie webu nebo název domény může odesílat. Odesílání více souborů cookie, zejména velkých souborů cookie, jako jsou ověřovací soubory cookie, může velmi rychle dosáhnout limitu mobilního prohlížeče, což způsobuje selhání aplikací, které se obtížně diagnostikují a opravují. Kromě toho existuje velký ekosystém kódu a komponent třetích stran, které se nedají aktualizovat tak, aby používaly dvojí přístup k souborům cookie.

Kód pro detekci prohlížeče použitý v ukázkových projektech v tomto úložišti GitHubu je obsažen ve dvou souborech.

Tyto detekce jsou nejběžnějšími agenty prohlížeče, které jsme viděli, že podporují standard 2016 a pro který je potřeba atribut zcela 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é architektury, kterou používáte. Následující kód lze zavolat na místě volání HttpCookie

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 lze funkci přepsání adresy URL služby IIS použít k přesměrování všech požadavků na HTTPS. Následující 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 IIS URL Rewrite volitelnou funkcí, kterou může být nutné nainstalovat.

Testování aplikací kvůli problémům se SameSite

Aplikaci musíte otestovat pomocí prohlížečů, 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řihlašování, jako je Facebook, Azure AD, OAuth a OIDC
  • Stránky, které přijímají požadavky z jiných webů
  • Stránky v aplikaci navržené tak, aby byly vložené do rámců iframe

Měli byste zkontrolovat, jestli jsou soubory cookie vytvořené, trvalé a správně odstraněné ve vaší aplikaci.

Aplikace, které komunikují se vzdálenými weby, jako je přihlášení třetích stran, musí:

Otestujte webové aplikace pomocí klientské verze, která se může přihlásit k novému chování SameSite. Chrome, Firefox a Chromium Edge mají nové příznaky funkce opt-in, které je možné použít k testování. Jakmile aplikace použije opravy SameSite, otestujte ji ve starších verzích klienta, zejména v Safari. Další informace naleznete v tématu Podpora starších prohlížečů v tomto dokumentu.

Testování pomocí Chromu

Chrome 78+ poskytuje zavádějící výsledky, protože má zavedené dočasné opatření. Dočasné zmírnění rizik pro Chrome 78+ 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. Chcete-li otestovat nové chování SameSite, přepněte chrome://flags/#same-site-by-default-cookies na Povoleno. Starší verze Chromu (75 a novější) se hlásí, že selhávají s novým None nastavením. Viz Podpora starších prohlížečů v tomto dokumentu.

Google nezpřístupní starší verze chromu. Postupujte podle pokynů ke stažení Chromium a otestujte starší verze Chromu. Nestahujte Chrome z odkazů poskytovaných vyhledáváním starších verzí Chrome.

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žňuje testování webů a služeb v konečném koncovém stavu funkce, ve které bylo zmírnění rizik odebráno. Další informace naleznete v tématu Aktualizace SameSite na The Chromium Projects

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

Stáhněte si verzi Chromu, která podporuje nový atribut. V době psaní je aktuální verze Chrome 80. Chrome 80 potřebuje, aby byl příznak chrome://flags/#same-site-by-default-cookies povolený pro použití nového chování. Měli byste také povolit (chrome://flags/#cookies-without-same-site-must-be-secure) otestovat nadcházející chování souborů cookie, které nemají povolený žádný atribut SameSite. Chrome 80 je připraven provést přechod na zacházení se soubory cookie bez tohoto atributu SameSite=Lax, ale s časovým obdobím odkladu pro konkrétní požadavky. Pokud chcete časový interval odkladu zakázat, můžete chrome 80 spustit pomocí následujícího argumentu příkazového řádku:

--enable-features=SameSiteDefaultChecksMethodRigorously

Chrome 80 obsahuje v konzole prohlížeče upozornění o chybějících atributech sameSite. Pomocí klávesy F12 otevřete konzolu prohlížeče.

Testování pomocí Safari

Safari 12 striktně implementoval předchozí koncept a selže, když je nová None hodnota v souboru cookie. None je vyhnuto pomocí kódu detekce prohlížeče v části Podpora starších prohlížečů v tomto dokumentu. Otestujte možnosti přihlášení ve stylu operačního systému s použitím Safari 12, Safari 13 a WebKitu prostřednictvím knihovny MSAL, ADAL nebo jakékoli jiné 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 jsou známé, že mají problémy s kompatibilitou s novým chováním SameSite. Problém řeší upgrade operačního systému na OSX Catalina (10.15) nebo iOS 13. Safari momentálně nemá příznak výslovného souhlasu pro testování nového chování specifikace.

Testování ve Firefoxu

Podporu Firefoxu pro nový standard lze testovat na verzi 68+ zapnutím na about:config stránce s příznakem funkce network.cookie.sameSite.laxByDefault. Ve starších verzích Firefoxu nebyly hlášeny problémy s kompatibilitou.

Testování s prohlížečem Edge (Legacy)

Edge podporuje starý standard SameSite. Edge verze 44 nebo novější nemá žádné známé problémy s kompatibilitou s novým standardem.

Testování s Edge (Chromium)

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

Test s elektronem

Verze Elektronu zahrnují starší verze Chromium. Například verze Elektronu, kterou Teams používá, je Chromium 66, které vykazuje starší chování. Musíte provést vlastní testování kompatibility s verzí elektronu, 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 zpět na předchozí chování, kdy se atribut sameSite pro hodnotu None nevysílá, a soubory cookie ověřování a relace můžete vrátit k tomu, aby tyto hodnoty neodesílaly. Mělo by se to zobrazit jako extrémně dočasná oprava, protože změny Chromu přeruší všechny externí požadavky POST nebo ověřování pro uživatele pomocí prohlížečů, které podporují změny standardu.

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

Aktualizujte web.config tak, aby zahrnovaly 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>

Dodatečné zdroje

  • Last updated on