jak nakonfigurovat ASP.NET webové aplikace a API vyžadují HTTPS

pro každou aplikaci, která je hostována na webu, je nezbytné, aby zabezpečení bylo zabudováno od začátku.
povolení vaší webové aplikace sloužit bezpečnému provozu přes HTTPS a prosazování těchto zásad je jednou z prvních věcí, které byste měli implementovat, a to je stejně důležité pro webové aplikace jako pro API.

s dobře zavedenými službami, jako je Let ‘ s Encrypt, které poskytují bezplatné certifikáty TLS, již neexistuje žádný přesvědčivý technický nebo finanční důvod nepoužívat HTTPS pro vaše webové aplikace.
v tomto článku ukazuji, jak správně nakonfigurovat vaše webové aplikace tak, aby vyžadovaly HTTPS, a uvádím příklady pro obě ASP.NET a ASP.NET klíčové projekty.

HTTPS přesměrování

abyste se ujistili, že je váš web správně zabezpečen, po získání a instalaci nového lesklého certifikátu SSL/TLS se budete chtít ujistit, že HTTPS je vždy používán.

pro vaše webové aplikace, např. aplikace MVC, můžete nakonfigurovat provoz, který má být přesměrován z HTTP na HTTPS.

z různých důvodů je stále vhodné ponechat výchozí port HTTP (port 80) otevřený a přesměrovat uživatele na výchozí port HTTPS (port 443) pro webové aplikace, které jsou přístupné prostřednictvím prohlížeče.

Toto je část oficiálních rad osvědčených postupů v dokumentaci Let ‘ s Encrypt. Špičkový výzkumník v oblasti bezpečnosti, Scott Helm, má také velmi dobrý článek, který vysvětluje, proč je uzavření portu 80 špatné pro bezpečnost v kontextu webových aplikací.

v níže uvedených částech ukazuji, jak nakonfigurovat přesměrování HTTPS pro ASP.NET a ASP.NET základní webové aplikace.

ASP.NET webové aplikace

ASP.NET MVC framework má pohodlně vestavěnou třídu RequireHttpsAttribute, kterou můžeme využít.

při použití atribut způsobí, že odpověď přesměrování bude odeslána zpět klientovi, pokud byl požadavek odeslán přes HTTP místo HTTPS.

atribut lze použít buď na základě regulátoru nebo na základě akce. Důrazně však doporučuji použít atribut globálně k vynucení přesměrování HTTPS na celém webu, jak je uvedeno níže.

 filtry.Přidat (nový RequireHttpsAttribute());

výše uvedený řádek kódu se obvykle objevuje ve statické metodě RegisterGlobalFilters ve třídě FilterConfig podle níže uvedeného úryvku kódu.

/// <souhrn> / / / registruje Globální filtry./// < / souhrn> / / / <param name= "filtry" >kolekce filtrů pro registraci< / param>public static void RegisterGlobalFilters (GlobalFilterCollection filters){ filters.Přidat (nový HandleErrorAttribute ()); filtry.Přidat (nový RequireHttpsAttribute ()); filtry.Přidat (nový Autorizeattribute());}

v ASP.NET aplikace, metoda RegisterGlobalFilters je obvykle volána při spuštění z metody Application_Start v rámci globálního.soubor asax.

před pokračováním je důležité si uvědomit, že globální filtry se budou vztahovat pouze na požadavky HTTP, které jsou předány vašim řadičům. Proto je stále možné, aby klient přistupoval ke statickým souborům, jako jsou styly a soubory skriptů, přes nezabezpečený HTTP.

měli byste dbát na to, abyste použili relativní odkazy na jakékoli statické zdroje, na které odkazujete z vašeho HTML, nebo použijte absolutní adresy URL se schématem HTTPS, abyste se ujistili, že veškerý obsah je bezpečně podáván.

přepsat pravidla

aby byla vaše webová aplikace ještě bezpečnější, můžete nakonfigurovat přesměrování na reverzní úrovni proxy, např. jako součást konfigurace služby IIS. Tím se zajistí, že všechny příchozí požadavky budou přesměrovány odpovídajícím způsobem.

v případě služby IIS to můžete implementovat pomocí pravidla přepisování přidáním následujícího na váš Web.konfigurační soubor.

< rewrite> < rules> <rule name= "HTTP to HTTPS redirect" stopProcessing="true" > < match url=" (.*)" /> <podmínky> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> </podmínky> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </rule> </rules></rewrite>

IIS bude při manipulaci s příchozími respektovat výše uvedené pravidlo přepisování provoz, přesměrování nezabezpečeného provozu na https, než dosáhne kódu aplikace.

stejně jako u mnoha aspektů zabezpečení se domnívám, že je nejlepší mít na svém místě více vrstev zabezpečení. Pokud něco selže nebo je nesprávně nakonfigurováno na jedné úrovni, mít nouzový stav je vždy dobrá věc.

. Net Core

. Net Core má také vestavěnou třídu RequireHttpsAttribute, která může být použita buď na základě jednotlivých řadičů / akcí, nebo může být registrována globálně.

Globální registraci lze nastavit v rámci metody ConfigureServices vaší třídy Startup, jak je ukázáno níže.

/// <shrnutí> / / / tato metoda je volána runtime./// Použijte tuto metodu pro přidání služeb do kontejneru./// < / souhrn> / / / <param name= "services" >kolekce kontejnerových služeb< / param>public void ConfigureServices (IServiceCollection services){ services.AddControllersWithViews (options => options.Filtr.Přidat (nový RequireHttpsAttribute()));}

výše uvedený kód dělá totéž zásadně jako v tradičním ASP.NET projekt.

v. NET Core však můžeme udělat lépe než toto.

. Net Core má také vestavěný middleware pro přesměrování HTTPS, který lze konfigurovat pomocí jednoho řádku kódu, jak je uvedeno níže.

 aplikace.UseHttpsRedirection ();

výše uvedený řádek kódu by měl být přidán do metody Configure třídy Startup. Většina standardu ASP.NET pro MVC nakonfigurujte middleware přesměrování HTTPS automaticky.

níže je uveden příklad typického obsahu metody Configure.

/// <shrnutí> / / / tato metoda je volána runtime./// Pomocí této metody nakonfigurujte potrubí požadavku HTTP./// < / shrnutí> / / / <param name= " app ">objekt tvůrce aplikací používaný ke konfiguraci potrubí požadavku< / param>/ / / <param name= " env " >webhostingové prostředí aplikace běží v< / param> veřejná void Configure(iapplicationbuilder app, IWebHostEnvironment env){ if (env.ISdevelopment ()) {app.UseDeveloperExceptionPage ();} else { app.UseExceptionHandler ("/Home / Error"); aplikace.UseHsts ();} aplikace.UseHttpsRedirection (); aplikace.UseStaticFiles (); aplikace.UseRouting (); aplikace.UseAuthorization (); aplikace. UseEndpoints (endpoints => { endpoints.MapControllerRoute( název: "Výchozí", vzor: "{controller=Home} / {action=Index} / {id?}"); });}

proč je tedy middleware přesměrování HTTPS lepší než filtr RequireHttpsAttribute?

no, díky způsobu, jakým ASP.NET hlavní webové aplikace jsou hostovány, přesměrování HTTPS middleware jsou aplikována na vyšší úrovni, a proto budou kromě požadavků vázaných na řadič přesměrovány také požadavky na statické soubory, jako jsou styly a skripty.

HSTS

další užitečný kus ASP.NET Core middleware je HSTS middleware a je nakonfigurován ve výše uvedeném příkladu pomocí následujícího řádku kódu.

 aplikace.UseHsts();

Všimněte si, že stejně jako u mnoha vestavěných komponent middleware, mnoho pokročilejších aspektů ASP.NET Core middleware lze konfigurovat v rámci metody ConfigureServices vaší spouštěcí třídy.

co je HSTS a proč bychom jej měli používat?

problém s přesměrováním HTTPS sám o sobě je s prvním nezabezpečeným požadavkem, který přichází do aplikace od klienta.

pokud je první příchozí HTTP požadavek zachycen “mužem uprostřed”, integrita požadavku bude ztracena. Klient může být například přesměrován někam jinam, aniž by si toho všiml např. na falešnou přihlašovací stránku.

HSTS je zkratka pro HTTP Strict Transport Security a pomáhá vyřešit výše popsaný problém informováním prohlížeče, že webová aplikace by měla být přístupná pouze přes HTTPS.

dělá to tak, že v odpovědi vrátí hlavičku Strict-Transport-Security, takže následující požadavky používají HTTPS bez dalších přesměrování. Prohlížeč ukládá tuto instrukci do mezipaměti, aby zajistil, že další návštěvy webu budou přes HTTPS bez dalších přesměrování.

úplně první požadavek

Ano, to vše zní skvěle, ale co ten úplně první požadavek?

většinu problému jsme vyřešili, ale stále jsme se nezabývali první žádostí obdrženou od klienta, který nikdy předtím nenavštívil naše stránky.

abychom byli super bezpeční a uzavřeli smyčku, můžeme zaregistrovat naše stránky jako “předinstalované”. Prohlížeče vedou seznam webů, které jsou na seznamu “předběžného načtení”, a pokud je váš web na tomto seznamu, nikdy neobdržíte nezabezpečený požadavek od klienta, protože prohlížeč dodržuje stav předběžného načtení.

můžete zaregistrovat svůj web, který má být předinstalován, a to tak, že přejdete na web HSTS Preload a podáte žádost o jeho předinstalování.

níže je uveden příklad záhlaví HSTS se specifikovanou směrnicí předpětí.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Všimněte si, že je nesmírně důležité, abyste svůj web důkladně otestovali, než povolíte HSTS ve výrobním prostředí, abyste se ujistili, že funguje správně přes HTTPS. To je zvláště důležité, pokud se rozhodnete pro předběžné načtení webu, protože to nelze snadno vrátit zpět a může trvat měsíce, než bude váš web odstraněn ze seznamu předběžného načtení.

vřele doporučuji konfiguraci HSTS pro vaše webové aplikace. To, zda se také rozhodnete mít svůj web předinstalovaný, bude záviset na vašich konkrétních bezpečnostních požadavcích.

odchozí pravidla

podle části přepisovací pravidla z dřívějšího v tomto článku můžete také povolit HSTS na reverzní úrovni proxy.

níže je uveden příklad, jak to nakonfigurovat na webu.konfigurační soubor, pokud hostujete aplikaci ve službě IIS.

< rewrite> < outboundRules> < rule name= "Add Strict-Transport-Security when HTTPS "enabled=" true "> < match serverVariable= "RESPONSE_Strict_Transport_Security" pattern=".* "/> <podmínky> < add input= "{HTTPS} "pattern=" on "ignoreCase=" true " / > < / podmínky> <action type=" Rewrite "value=" max-age=31536000" /> </pravidlo> < / outboundRules>< / přepsat>

nyní bude hlavička HSTS nastavena pro veškerý provoz HTTPS na vašem webu.

Všimněte si, že výše uvedený přístup bude fungovat jak pro tradiční ASP.NET a ASP.NET základní aplikace. Stačí přidat Web.konfigurační soubor do projektu a ujistěte se, že vlastnost “Kopírovat do výstupního adresáře” je nastavena na “Kopírovat, pokud je novější”.

API

API se velmi liší od běžných webových aplikací, ke kterým přistupují lidé, a to jak v jejich designu, zamýšlených případech použití, tak v bezpečnostních hlediscích.

v níže uvedených oddílech se budeme zabývat osvědčenými postupy pro vyžadování HTTPS pro API.

vyžadující HTTPS?

tradiční ASP.NET webové API projekty nemají přístup k vestavěnému atributu pro vyžadování HTTPS.

to nám však nebrání ve vytváření vlastních.

níže je uveden příklad, jak to provést.

/// <summary>/// Called when a process requests authorization./// </summary>/// <param name="actionContext">The action context</param>public override void OnAuthorization(HttpActionContext actionContext){ HttpRequestMessage request = actionContext.Request; if (request.RequestUri.Scheme != Uri.UriSchemeHttps) { if (request.Method.Equals(HttpMethod.Get)) { actionContext.Response = request.CreateResponse(HttpStatusCode.Found, "SSL is required"); // Provide the correct URL to the user via the Location header. var uriBuilder = nový UriBuilder (žádost.RequestUri) {Scheme = Uri.UriSchemeHttps, Port = 443 }; actionContext.Reakce.Záhlaví.Location = uriBuilder.Uri;} else actionContext.Odpověď = požadavek.CreateResponse (HttpStatusCode.Nenalezeno, "vyžaduje se SSL"); }}

ve výše uvedeném příkladu jsem vytvořil třídu nazvanou RequireHttpsAttribute, která pochází z třídy AuthorizationFilterAttribute a přepisuji metodu virtual OnAuthorization.

u požadavků GET výše uvedená metoda informuje klienty o správné adrese URL pomocí schématu HTTPS vrácením v záhlaví umístění. U všech ostatních požadavků je zpráva “SSL je vyžadována” jednoduše vrácena.

ačkoli to dává smysl při volání API z prohlížeče, jedním z problémů s výše uvedeným kódem je, že vrací kód stavu přesměrování, kterému většina klientů API nerozumí.

v závislosti na vašem pohledu by výše uvedený kód mohl být namísto toho změněn tak, aby nastavil stavový kód HTTP na něco jiného, jako je Špatný požadavek, než aby se pokusil přesměrovat klienta.

můžeme implementovat něco podobného .NET Core vytvořením vlastní třídy, jako je ApiRequireHttpsAttribute, která pochází z vestavěné třídy RequireHttpsAttribute. Poté můžeme přepsat metodu virtual HandleNonHttpsRequest a odpovídajícím způsobem nastavit kód odpovědi podle níže uvedeného vzorového kódu.

/// <shrnutí> / / / voláno, pokud požadavek není přijat přes HTTPS./// < / shrnutí> / / / <param name= "filterContext" >kontext filtru< / param> chráněný přepis void HandleNonHttpsRequest (AuthorizationFilterContext filterContext){ filterContext.Výsledek = nový StatusCodeResult (400);}

výše uvedený kód nastavuje stavový kód HTTP pro odpověď na Špatný požadavek (400). Mohlo by to být změněno tak, aby zahrnovalo zprávu do odpovědi nebo jakékoli jiné vlastní logiky.

neposloucháte?

Ok, takže jsme se podívali na to, jak donutit klienty API používat HTTPS, kdykoli se pokusí použít HTTP.

je to však nejlepší volba?

nejlepší praxe diktuje, že bychom měli mít více vrstev zabezpečení, ale také diktuje, že bychom měli implementovat zabezpečení co nejdříve.

ve skutečnosti nejbezpečnější věcí, kterou můžeme v kontextu API udělat, je zabránit jim v poslechu na nezabezpečeném portu. Tato rada se zrcadlí v dokumentech Microsoft pro ASP.NET jádro.

samozřejmě nemůžeme zabránit klientovi API, aby se pokusil dosáhnout našeho API nejistým způsobem. V tomto případě je to však chyba integrátora API a ne něco, pro co můžeme udělat něco smysluplného, abychom tomu zabránili.

shrnutí

v tomto článku jsem se zabýval tím, jak prosadit HTTPS ve vašich webových aplikacích a API, a diskutoval jsem o nejvhodnějších a nejbezpečnějších řešeních pro oba scénáře.

klíčová věc, kterou je třeba odnést, je, že byste měli implementovat více vrstev zabezpečení pro vaši aplikaci a pokud je to možné, vynutit zabezpečení co nejdříve.

využijte HSTS a využijte sílu vaší reverzní konfigurace proxy pro bezpečné zpracování požadavků.