så här konfigurerar du ASP.NET webbappar och API: er för att kräva HTTPS

för alla applikationer som finns på webben är det viktigt att säkerheten är inbyggd från början.
aktivera din webbapplikation för att tjäna säker trafik via HTTPS och genomdriva denna policy är en av de första saker som du bör genomföra och detta är lika viktigt för webbappar som det är för API: er.

med väletablerade tjänster som Let ‘ s Encrypt som tillhandahåller gratis TLS-certifikat finns det inte längre någon övertygande teknisk eller ekonomisk anledning att inte använda HTTPS för dina webbapplikationer.
i den här artikeln visar jag hur du konfigurerar dina webbapplikationer korrekt så att de kräver HTTPS och jag täcker exempel för båda ASP.NET och ASP.NET kärnprojekt.

HTTPS omdirigering

för att se till att din webbplats är ordentligt säkrad, efter att ha erhållit och installerat ett glänsande nytt SSL/TLS-certifikat, vill du se till att HTTPS alltid används.

för dina webbappar, t.ex. MVC-applikationer, kan du konfigurera trafik som ska omdirigeras från HTTP till HTTPS.

av olika skäl är det fortfarande lämpligt att hålla standard HTTP-porten (port 80) öppen och omdirigera dina användare till standard HTTPS-porten (port 443) för webbapplikationer som nås via en webbläsare.

Detta är en del av officiella råd om bästa praxis inom Let ‘ s Encrypt-dokumentationen. Toppsäkerhetsforskare, Scott Helm, har också en mycket bra artikel som förklarar varför stängning av port 80 är dåligt för säkerheten i samband med webbapplikationer.

i avsnitten nedan visar jag hur man konfigurerar HTTPS-omdirigering för ASP.NET och ASP.NET kärn webbapplikationer.

ASP.NET web apps

den ASP.NET MVC framework har bekvämt en inbyggd RequireHttpsAttribute klass som vi kan utnyttja.

när det tillämpas kommer attributet att få ett omdirigeringssvar att skickas tillbaka till klienten om en begäran skickades över HTTP istället för HTTPS.

attributet kan tillämpas antingen på en per-controller eller per-action basis. Jag rekommenderar dock starkt att du använder attributet globalt för att genomdriva HTTPS-omdirigering över hela webbplatsen, som visas nedan.

filter.Lägg till (ny RequireHttpsAttribute());

ovanstående kodlinje visas vanligtvis inom en statisk RegisterGlobalFilters – metod i en FilterConfig – klass, enligt kodavsnittet nedan.

/// <sammanfattning> / / / registrerar globala filter.///< / sammanfattning> / / / <param name="filter" >insamling av filter för att registrera</param>public static void RegisterGlobalFilters(GlobalFilterCollection filter){ filter.Lägg till (ny HandleErrorAttribute ()); filter.Lägg till (ny RequireHttpsAttribute ()); filter.Lägg till (new AuthorizeAttribute());}

i en ASP.NET ansökan, RegisterGlobalFilters – metoden kallas vanligtvis vid start från Application_Start – metoden inom det globala.asax-fil.

innan du går vidare är det viktigt att notera att globala filter endast gäller HTTP-förfrågningar som skickas till dina kontroller. Därför är det fortfarande möjligt för en klient att komma åt statiska filer som formatmallar och skriptfiler över osäkra HTTP.

du bör se till att använda relativa länkar till statiska resurser som du refererar till från din HTML, eller använda absoluta webbadresser med HTTPS-schemat för att se till att allt innehåll serveras säkert.

omskrivningsregler

för att göra din webbapplikation ännu säkrare kan du konfigurera omdirigering på omvänd proxy-nivå, t.ex. som en del av din IIS-konfiguration. Detta kommer att se till att alla inkommande förfrågningar omdirigeras på lämpligt sätt.

när det gäller IIS kan du implementera detta via en omskrivningsregel genom att lägga till följande på din webb.konfigurationsfil.

< skriva om> < regler> <regelnamn= "HTTP till HTTPS omdirigering" stoppprocessing= "true"> <matcha url=" (.*)" /> <villkor> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> </villkor> <action type="omdirigera" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </regel> </regler></rewrite>

IIS kommer att respektera ovanstående omskrivningsregel vid hantering av inkommande trafik, omdirigera osäker trafik till https innan den når din programkod.

som med många aspekter av säkerhet tror jag att det är bäst att ha flera lager av säkerhet på plats. Om något misslyckas eller är felkonfigurerat på en nivå är det alltid bra att ha en reserv.

. Net Core

. Net Core har också en inbyggd RequireHttpsAttribute klass som kan tillämpas antingen på en per-controller/action basis eller det kan registreras globalt.

Global registrering kan ställas in inom ConfigureServices – metoden för din Startup – klass, som visas nedan.

/// <sammanfattning> / / / den här metoden kallas av körtiden./// Använd den här metoden för att lägga till tjänster i behållaren.///< / sammanfattning> / / / <param name="tjänster" >insamling av containertjänster</param>public void ConfigureServices(IServiceCollection services){ tjänster.AddControllersWithViews (alternativ => alternativ.Filter.Lägg till (ny RequireHttpsAttribute()));}

ovanstående kod gör samma sak i grunden som i en traditionell ASP.NET projekt.

men i. NET Core kan vi göra bättre än detta.

. Net Core har också inbyggd HTTPS omdirigering middleware, som kan konfigureras med en rad kod, som visas nedan.

app.UseHttpsRedirection();

ovanstående kodrad ska läggas till i Configure – metoden i Startup – klassen. Det mesta av standarden ASP.NET för MVC, konfigurera HTTPS omdirigering middleware automatiskt.

nedan är ett exempel på det typiska innehållet i Configure – metoden för referens.

/// <sammanfattning> / / / den här metoden kallas av körtiden./// Använd den här metoden för att konfigurera HTTP-begäran pipeline./// </sammanfattning>/// <param name="app">application builder-objektet som används för att konfigurera begäran pipeline</param>/// <param name="env">webbhotellmiljön som programmet körs i</param>Public void Configure(iapplicationbuilder app, iwebhostenvironment env){ om (env.IsDevelopment ()) {app.Useveloperexceptionpage ();} annars { app.UseExceptionHandler("/hem/fel"); app.UseHsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); app.UseAuthorization (); app.UseEndpoints (endpoints => { endpoints.MapControllerRoute (namn: "standard", mönster: "{controller=Home}/{action=Index}/{id?}"); });}

så varför är HTTPS omdirigering middleware bättre än filtret RequireHttpsAttribute?

Tja, tack vare det sätt som ASP.NET Core web apps är värd, middleware HTTPS omdirigeringar tillämpas på en högre nivå och därför förfrågningar om statiska filer som formatmallar och skript kommer också att omdirigeras utöver controller bundna förfrågningar.

HSTS

en annan användbar bit av ASP.NET Core middleware är HSTS middleware och den är konfigurerad i exemplet ovan via följande kodrad.

app.UseHsts();

Observera att som med många av de inbyggda middleware komponenter, Många mer avancerade aspekter av ASP.NET Core middleware kan konfigureras inom ConfigureServices – metoden för din startklass.

Vad är HSTS och varför ska vi använda det?

problemet med HTTPS-omdirigering på egen hand är med den första osäkra begäran som kommer in i applikationen från en klient.

om den första inkommande HTTP-begäran blir avlyssnad av en’ man i mitten ‘ kommer integriteten för begäran att gå förlorad. Till exempel kan klienten omdirigeras någon annanstans utan att de märker t.ex. till en falsk inloggningssida.

HSTS står för HTTP Strict Transport Security och det hjälper till att lösa problemet som beskrivs ovan genom att informera webbläsaren om att en webbapplikation endast ska nås via HTTPS.

det gör detta genom att returnera en sträng Transport-säkerhetshuvud i svaret så att efterföljande förfrågningar använder HTTPS utan ytterligare omdirigeringar. Webbläsaren cachar denna instruktion för att säkerställa att ytterligare besök på webbplatsen kommer att vara över HTTPS utan några fler omdirigeringar.

den allra första begäran

Ja, det låter bra, men hur är det med den allra första begäran?

vi har löst det mesta av problemet, men vi har fortfarande inte behandlat den allra första begäran från en klient som aldrig har besökt vår webbplats tidigare.

för att vara supersäker och stänga slingan på detta kan vi registrera vår webbplats för att vara ‘förinstallerad’. Webbläsare föra en lista över webbplatser som finns på en ‘förspänning’ lista och om din webbplats är på den här listan kommer du aldrig att få en osäker begäran från en klient som webbläsaren kommer att hedra förspänning status.

du kan registrera din webbplats för att bli förinstallerad genom att gå till HSTS Preload-webbplatsen och skicka in en begäran om att få den förinstallerad.

nedan är ett exempel på en HSTS-rubrik med det angivna förspänningsdirektivet.

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

Observera att det är oerhört viktigt att du testar din webbplats noggrant innan du aktiverar HSTS i en produktionsmiljö för att säkerställa att den fungerar korrekt via HTTPS. Detta är särskilt viktigt om du väljer att förinstallera din webbplats eftersom det inte lätt kan ångras och det kan ta månader att ta bort din webbplats från förladdningslistan.

jag rekommenderar starkt att du konfigurerar HSTS för dina webbapplikationer. Huruvida du också väljer att ha din webbplats förinstallerad beror på dina specifika säkerhetskrav.

Utgående regler

enligt avsnittet omskrivningsregler från tidigare i den här artikeln kan du också aktivera HSTS på omvänd proxy-nivå.

nedan är ett exempel på hur du konfigurerar detta på en webb.konfigurationsfil om du är värd för din ansökan i IIS.

<skriv om> <outboundRules> <regelnamn="Lägg till strikt Transport-säkerhet när HTTPS" aktiverat="true"> <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".* "/> <villkor> < Lägg till input= "{HTTPS} "pattern=" på "ignoreCase=" true "/ > < / villkor> < action type= "Rewrite" value= "max-age=31536000" /> </regel> </outboundRules>< / rewrite>

nu kommer HSTS-rubriken att ställas in för all HTTPS-trafik på din webbplats.

Observera att ovanstående tillvägagångssätt kommer att fungera för både traditionella ASP.NET och ASP.NET kärnapplikationer. Du behöver bara lägga till en webb.konfigurera filen till ditt projekt och se till att egenskapen’ Kopiera till Utdatakatalog ‘är inställd på’Kopiera om nyare’.

API: er

API: er skiljer sig ganska mycket från vanliga webbapplikationer som nås av människor, både i deras design, avsedda användningsfall och säkerhetshänsyn.

vi kommer att täcka de bästa metoderna för att kräva HTTPS för API: er i avsnitten nedan.

kräver HTTPS?

traditionell ASP.NET Web API-projekt har inte tillgång till ett inbyggt attribut för att kräva HTTPS.

men detta hindrar oss inte från att skapa våra egna.

nedan är ett exempel på hur man gör detta.

/// <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 = ny UriBuilder (begäran.RequestUri) { Schema = Uri.UriSchemeHttps, Port = 443 }; actionContext.Svar.Rubrik.Plats = uriBuilder.Uri;} annat actionContext.Svar = begäran.CreateResponse (HttpStatusCode.NotFound, "SSL krävs"); }}

i ovanstående exempel har jag skapat en klass som heter RequireHttpsAttribute som härrör från klassen AuthorizationFilterAttribute och jag åsidosätter den virtuella metoden OnAuthorization.

för GET-förfrågningar informerar ovanstående metod klienter om rätt URL med HTTPS-schemat genom att returnera detta i Platshuvudet. För alla andra förfrågningar returneras meddelandet ‘SSL krävs’ helt enkelt.

även om detta är vettigt när du ringer ett API från en webbläsare, är ett av problemen med ovanstående kod att den returnerar en omdirigeringsstatuskod som de flesta API-klienter inte förstår.

beroende på din synvinkel kan ovanstående kod istället ändras för att ställa in HTTP-statuskoden till något annat, till exempel dålig begäran, snarare än att försöka omdirigera klienten.

vi kan implementera något liknande i .NET kärna genom att skapa vår egen klass som ApiRequireHttpsAttribute som härrör från den inbyggda RequireHttpsAttribute klass. Vi kan sedan åsidosätta den virtuella HandleNonHttpsRequest – metoden och ställa in svarskoden i enlighet med provkoden nedan.

/// <sammanfattning> / / / anropas om begäran inte tas emot via HTTPS.///< / sammanfattning> / / / < param name="filterContext" >filtret sammanhang</param>skyddad åsido void HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Resultat = nytt Statuskoderesultat (400);}

ovanstående kod anger HTTP-statuskoden för svaret på dålig begäran (400). Det kan ändras för att inkludera ett meddelande i svaret eller vad som helst annan anpassad logik krävs.

lyssnar du inte?

Ok, så vi har tittat på hur man tvingar API-klienter att använda HTTPS när de försöker använda HTTP.

men är detta det bästa alternativet?

bästa praxis dikterar att vi ska ha flera lager av säkerhet, men det dikterar också att vi ska implementera säkerhet så tidigt som möjligt.

egentligen är det säkraste vi kan göra i samband med API: er att hindra dem från att lyssna på en osäker port i första hand. Detta råd speglas i Microsoft Docs för ASP.NET kärna.

Naturligtvis kan vi inte hindra en API-klient från att försöka nå vårt API på ett osäkert sätt. Men i det här fallet är det API-integratörens fel och inte något som vi kan göra något meningsfullt för att förhindra.

sammanfattning

i den här artikeln har jag täckt hur man använder HTTPS över dina webbappar och API: er och jag har diskuterat de mest lämpliga och säkra lösningarna för båda scenarierna.

det viktigaste att ta bort är att du ska implementera flera lager av säkerhet för din applikation och om möjligt tillämpa säkerhet så tidigt som möjligt.

använd HSTS och utnyttja kraften i din omvända proxykonfiguration för att hantera förfrågningar på ett säkert sätt.