hogyan állítsuk be a ASP.NET webalkalmazások és API-k ahhoz, hogy a HTTPS

minden olyan alkalmazáshoz, amely az interneten található, elengedhetetlen, hogy a biztonság a kezdetektől beépüljön.
a webalkalmazás HTTPS-en keresztüli biztonságos forgalom kiszolgálásának engedélyezése és a házirend érvényesítése az egyik első dolog, amelyet végre kell hajtania, és ez ugyanolyan fontos a webalkalmazások esetében, mint az API-k esetében.

az olyan jól bevált szolgáltatásokkal, mint a Let ‘ s Encrypt, amelyek ingyenes TLS-tanúsítványokat biztosítanak, már nincs olyan kényszerítő technikai vagy pénzügyi ok, hogy ne használja a HTTPS-t webes alkalmazásaihoz.
ebben a cikkben bemutatom, hogyan kell helyesen konfigurálni a webes alkalmazásokat úgy, hogy HTTPS-t igényeljenek, és példákat mutatok be mindkettőre ASP.NET és ASP.NET alapvető projektek.

HTTPS átirányítás

annak érdekében, hogy webhelye megfelelően biztonságos legyen, egy fényes új SSL/TLS tanúsítvány megszerzése és telepítése után meg kell győződnie arról, hogy mindig HTTPS-t használ.

webalkalmazásai, például MVC-alkalmazásai esetében beállíthatja, hogy a forgalom átirányításra kerüljön HTTP-ről HTTPS-re.

különböző okok miatt továbbra is tanácsos az alapértelmezett HTTP portot (80-as port) nyitva tartani, és a böngészőn keresztül elérhető webes alkalmazások számára átirányítani a felhasználókat az alapértelmezett HTTPS portra (443-as port).

ez része a Let ‘ s Encrypt dokumentációban található hivatalos legjobb gyakorlati tanácsadásnak. A legfontosabb biztonsági kutatónak, Scott Helmnek is van egy nagyon jó cikke, amely elmagyarázza, hogy a 80-as port bezárása miért káros a biztonságra a webes alkalmazások összefüggésében.

az alábbi szakaszokban bemutatom, hogyan kell beállítani a HTTPS átirányítást ASP.NET és ASP.NET Core webes alkalmazások.

ASP.NET webes alkalmazások

a ASP.NET MVC framework kényelmesen van egy beépített RequireHttpsAttribute osztály, amely tudjuk igénybe venni.

alkalmazásakor az attribútum átirányítási választ küld vissza az ügyfélnek, ha a kérést HTTPS helyett HTTP-n keresztül küldték.

az attribútum vezérlőnként vagy műveletenként alkalmazható. Nagyon ajánlom azonban az attribútum globális alkalmazását a HTTPS átirányítás érvényesítésére az egész webhelyen, az alábbiak szerint.

 szűrők.Add (új RequireHttpsAttribute());

a fenti kódsor általában egy statikus RegisterGlobalFilters metóduson belül jelenik meg egy FilterConfig osztályban, az alábbi kódrészlet szerint.

/// <összegzés> / / / regisztrálja a globális szűrőket.///</ összegzés>///<param name="szűrők">a nyilvántartandó szűrők gyűjteménye< / param>nyilvános statikus void RegisterGlobalFilters(GlobalFilterCollection szűrők){ szűrők.Hozzáad (új HandleErrorAttribute ()); szűrők.Hozzáadás (új RequireHttpsAttribute ()); szűrők.Add (új AuthorizeAttribute());}

egy ASP.NET alkalmazás, a RegisterGlobalFilters módszer általában hívják indításkor a Application_Start módszer a globális.asax fájl.

mielőtt továbblépnénk, fontos megjegyezni, hogy a globális szűrők csak a vezérlőknek átadott HTTP-kérésekre vonatkoznak. Ezért az ügyfél továbbra is hozzáférhet statikus fájlokhoz, például stíluslapokhoz és szkriptfájlokhoz nem biztonságos HTTP-n keresztül.

ügyeljen arra, hogy a HTML-ből hivatkozott statikus erőforrásokra mutató relatív hivatkozásokat használjon, vagy a HTTPS-sémával rendelkező abszolút URL-eket használjon, hogy megbizonyosodjon arról, hogy az összes tartalom biztonságosan szolgál-e.

újraírási szabályok

a webalkalmazás még biztonságosabbá tétele érdekében beállíthatja az átirányítást fordított proxy szinten, például az IIS konfigurációjának részeként. Ez biztosítja, hogy az összes bejövő kérés megfelelően átirányításra kerüljön.

az IIS esetében ezt újraírási szabályon keresztül valósíthatja meg, ha hozzáadja az alábbiakat a webhez.konfigurációs fájl.

< átírni> < szabályok> < szabály neve="HTTP-HTTPS átirányítás" stopProcessing="true">< match url="(.*)" /> <feltételek> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> </feltételek> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </rule> </rules></rewrite>

az IIS tiszteletben tartja a fenti átírási szabályt a bejövő forgalom kezelésekor, átirányítva a nem biztonságos forgalmat https-re, mielőtt az elérné az alkalmazáskódot.

mint a biztonság számos aspektusában, úgy gondolom, hogy a legjobb, ha több biztonsági réteg van a helyén. Ha valami meghibásodik vagy rosszul van konfigurálva egy szinten, a tartalék mindig jó dolog.

. Net Core

. Net Core is van egy beépített RequireHttpsAttribute osztály, amely lehet alkalmazni akár egy per-vezérlő/akció alapján, vagy lehet regisztrálni globálisan.

a globális regisztráció a ConfigureServices osztály Startup módszerén belül állítható be, az alábbiak szerint.

/// <összegzés> / / / ezt a módszert a futásidő hívja meg./// Használja ezt a módszert szolgáltatások hozzáadásához a tárolóhoz.///</ összegzés>///<param name="szolgáltatások">konténerszolgáltatások gyűjteménye< / param>nyilvános void ConfigureServices(IServiceCollection services){ szolgáltatások.AddControllersWithViews (options => opciók.Szűrők.Add (új RequireHttpsAttribute()));}

a fenti kód alapvetően ugyanazt teszi, mint egy hagyományos ASP.NET projekt.

a. net Core-ban azonban ennél jobbat is tehetünk.

a.net Core beépített HTTPS átirányítási köztes szoftverrel is rendelkezik, amely egy sor kóddal konfigurálható, az alábbiak szerint.

 kb.UseHttpsRedirection ();

a fenti kódsort hozzá kell adni a Configure módszer a Startup osztály. A legtöbb szabvány ASP.NET Core web application sablonok pl MVC, konfigurálja a HTTPS átirányítás köztes szoftver automatikusan.

az alábbiakban bemutatunk egy példát a Configure módszer tipikus tartalmára referenciaként.

/// <összegzés> / / / ezt a módszert a futásidő hívja meg./// Ezzel a módszerrel konfigurálhatja a HTTP kérésfolyamatot./// </összegzés>/// <param name="app">az alkalmazás builder objektum konfigurálásához használt kérelem csővezeték</param>/// <param name="env">a web hosting környezetben az alkalmazás fut</param>public void Configure(IApplicationBuilder app, iwebhostenvironment env){ if (env.IsDevelopment ()) {app.UseDeveloperExceptionPage ();} else { kb.UseExceptionHandler ("/Home / Error"); kb.UseHsts ();} app.UseHttpsRedirection (); kb.UseStaticFiles (); kb.UseRouting (); kb.UseAuthorization (); kb.UseEndpoints (végpontok => { végpontok.MapControllerRoute (név: "alapértelmezett", minta: "{controller=Home}/{action=Index}/{id?}"); });}

tehát miért jobb a HTTPS átirányítási köztes szoftver, mint a RequireHttpsAttribute szűrő?

nos, hála az utat, hogy ASP.NET a központi webalkalmazásokat üzemeltetik, a köztes szoftver HTTPS átirányításait magasabb szinten alkalmazzák, ezért a statikus fájlok, például a stíluslapok és a szkriptek iránti kérelmeket a vezérlőhöz kötött kérések mellett átirányítják.

HSTS

egy másik hasznos darab ASP.A NET Core middleware a HSTS middleware, amelyet a fenti példában a következő kódsoron keresztül konfigurálunk.

 kb.UseHsts ();

vegye figyelembe, hogy a beépített köztes szoftverekhez hasonlóan a ASP.NET a Core middleware a Startup osztály ConfigureServices metódusán belül konfigurálható.

mi az a HSTS és miért használjuk?

a HTTPS átirányítással önmagában az a probléma, hogy az első nem biztonságos kérés érkezik az alkalmazásba egy ügyféltől.

ha az első bejövő HTTP kérést egy ‘középen álló ember’ elfogja, a kérés integritása elvész. Például, az ügyfél lehet átirányítani valahol máshol anélkül, hogy észrevenné például egy hamis bejelentkezési oldal.

a HSTS a HTTP Strict Transport Security rövidítése, és segít megoldani a fent leírt problémát azáltal, hogy tájékoztatja a böngészőt arról, hogy egy webalkalmazás csak HTTPS-en keresztül érhető el.

ezt úgy teszi, hogy a válaszban egy Strict-Transport-Security fejlécet ad vissza, hogy a későbbi kérések további átirányítás nélkül használják a HTTPS-t. A böngésző gyorsítótárazza ezt az utasítást annak biztosítása érdekében, hogy a webhely további látogatása HTTPS-en keresztül történjen, további átirányítások nélkül.

a legelső kérés

Igen, ez mind jól hangzik, de mi a helyzet a legelső kéréssel?

a probléma nagy részét megoldottuk, de még mindig nem foglalkoztunk az első olyan ügyféltől kapott kéréssel, aki még soha nem látogatta meg webhelyünket.

annak érdekében, hogy szuper-biztonságos és zárja be a hurok ezen, tudjuk regisztrálni a helyszínen, hogy ‘előre betöltött’. A böngészők listát vezetnek azokról a webhelyekről, amelyek az ‘előterhelés’ listán szerepelnek, és ha webhelye szerepel ezen a listán, akkor soha nem kap bizonytalan kérést az ügyféltől, mivel a böngésző tiszteletben tartja az előterhelés állapotát.

regisztrálhatja webhelyét előre betöltésre, ha ellátogat a HSTS Preload webhelyére, és kérelmet nyújt be annak előzetes betöltésére.

az alábbiakban bemutatunk egy példát egy HSTS fejlécre, amely tartalmazza a preload irányelvet.

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

vegye figyelembe, hogy rendkívül fontos, hogy alaposan tesztelje webhelyét, mielőtt engedélyezné a HSTS-t egy termelési környezetben, hogy megbizonyosodjon arról, hogy megfelelően működik-e a HTTPS-en keresztül. Ez különösen akkor fontos, ha a webhely előzetes betöltése mellett dönt, mivel ezt nem lehet könnyen visszavonni, és hónapokba telhet, amíg webhelyét eltávolítják az előterhelési listáról.

nagyon ajánlom a HSTS konfigurálását a webes alkalmazásokhoz. Az, hogy a webhely előre telepítve van-e vagy sem, az adott biztonsági követelményektől függ.

Kimenő szabályok

a cikk korábbi újraírási szabályai szakasz szerint a HSTS-t fordított proxy szinten is engedélyezheti.

az alábbiakban bemutatunk egy példát arra, hogyan lehet ezt konfigurálni egy weben.konfigurációs fájl, ha az alkalmazást az IIS-ben tárolja.

< átírni>< outboundRules>< szabály neve="Add szigorú-Transport-Security, amikor HTTPS" enabled="true">< match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".* "/> <feltételek > < add input= "{HTTPS} "pattern=" on "ignoreCase=" true "/ > < / feltételek> < action type = "Rewrite" value= "max-age=31536000" /> </szabály></outboundRules></rewrite>

most a HSTS fejléc lesz beállítva az összes HTTPS forgalom a webhelyen.

vegye figyelembe, hogy a fenti megközelítés mindkét hagyományos ASP.NET és ASP.NET alapvető alkalmazások. Csak hozzá kell adnia egy webet.állítsa be a fájlt a projektbe, és győződjön meg arról, hogy a ‘Copy to Output Directory’ tulajdonság értéke ‘Copy if Newer’.

API-k

az API-k meglehetősen különböznek a normál webes alkalmazásoktól, amelyekhez az emberek hozzáférnek, mind tervezésük, tervezett felhasználási eseteik, mind biztonsági szempontjaik szempontjából.

az alábbi szakaszokban ismertetjük a HTTPS API-khoz való igénylésének legjobb gyakorlatait.

HTTPS szükséges?

hagyományos ASP.NET a Web API-projektek nem férnek hozzá a HTTPS-t igénylő beépített attribútumhoz.

ez azonban nem akadályoz meg minket abban, hogy létrehozzuk a sajátunkat.

az alábbiakban bemutatunk egy példát erre.

/// <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 = új UriBuilder (kérés.RequestUri) { Scheme = Uri.UriSchemeHttps, Port = 443}; actionContext.Válasz.Fejlécek.Hely = uriBuilder.Uri;} más actionContext.Válasz = kérés.CreateResponse (HttpStatusCode.NotFound, "SSL szükséges"); }}

a fenti példában létrehoztam egy RequireHttpsAttribute nevű osztályt, amely a AuthorizationFilterAttribute osztályból származik, és felülbírálom a virtuális OnAuthorization metódust.

GET kérések esetén a fenti módszer a HTTPS séma segítségével tájékoztatja az ügyfeleket a helyes URL-ről, ezt visszaadva a Helyfejlécben. Minden más kérés esetén az’ SSL is required ‘ üzenet egyszerűen visszaküldésre kerül.

bár ennek van értelme, ha API-t hív egy böngészőből, a fenti kód egyik problémája az, hogy átirányítási állapotkódot ad vissza, amelyet a legtöbb API-kliens nem fog megérteni.

nézőponttól függően a fenti kód ehelyett módosítható úgy, hogy a HTTP állapotkódot valami másra állítsa, például rossz kérés, ahelyett, hogy megpróbálná átirányítani az ügyfelet.

valami hasonlót tudunk megvalósítani .NET Core létrehozásával saját osztály, mint a ApiRequireHttpsAttribute amely abból a beépített RequireHttpsAttribute osztály. Ezután felülbírálhatjuk a virtuális HandleNonHttpsRequest metódust, és ennek megfelelően állíthatjuk be a válaszkódot, az alábbi mintakód szerint.

/// <összegzés> / / / hívott, ha a kérés nem érkezett HTTPS-en keresztül.///</ összegzés>///<param name="filterContext">a szűrőkörnyezet< / param>védett felülírás érvénytelen HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Eredmény = új StatusCodeResult (400);}

a fenti kód beállítja a HTTP állapotkódot a rossz kérésre adott válaszhoz (400). Módosítható úgy, hogy üzenetet tartalmazzon a válaszban, vagy bármilyen más egyedi logikára van szükség.

nem figyel?

Ok, ezért megvizsgáltuk, hogyan kényszeríthetjük az API klienseket a HTTPS használatára, amikor megpróbálják használni a HTTP-t.

ez azonban a legjobb megoldás?

a legjobb gyakorlat azt diktálja, hogy több biztonsági réteggel kell rendelkeznünk, de azt is előírja, hogy a biztonságot a lehető leghamarabb végre kell hajtanunk.

valójában a legbiztonságosabb dolog, amit az API-k kapcsán tehetünk, az, hogy megakadályozzuk őket abban, hogy elsősorban nem biztonságos porton hallgassanak. Ezt a tanácsot tükrözi a Microsoft Docs for ASP.NET mag.

természetesen nem akadályozhatjuk meg, hogy egy API kliens bizonytalan módon próbálja elérni az API-t. Ebben az esetben azonban ez az API integrátor hibája, nem pedig olyasmi, amelynek megakadályozására bármi értelmes dolgot tehetünk.

Összefoglalás

ebben a cikkben kitértem arra, hogyan érvényesítheti a HTTPS-t a webes alkalmazásokban és API-kban, és kitértem a legmegfelelőbb és legbiztonságosabb megoldásokra mindkét esetben.

a legfontosabb dolog, hogy vegye el, hogy meg kell végre több réteg biztonsági Az alkalmazás, és ahol lehetséges érvényesíteni a biztonságot a lehető leghamarabb.

használja ki a HSTS-t, és használja ki a fordított proxy konfiguráció erejét a kérések biztonságos kezeléséhez.