Sådan konfigureres din ASP.NET for at kræve HTTPS

for enhver applikation, der er hostet på internettet, er det vigtigt, at sikkerheden er indbygget fra starten.
det er en af de første ting, du bør implementere, og det er lige så vigtigt for apps på nettet, som det er for API ‘ er.

med veletablerede tjenester som Let ‘ s Encrypt, der leverer gratis TLS-certifikater, er der ikke længere nogen overbevisende teknisk eller økonomisk grund til ikke at bruge HTTPS til dine internetapplikationer.
i denne artikel demonstrerer jeg, hvordan du korrekt konfigurerer dine internetapplikationer, så de kræver HTTPS, og jeg dækker eksempler for begge ASP.NET og ASP.NET Kerneprojekter.

HTTPS omdirigering

for at sikre, at din hjemmeside er korrekt sikret, efter at opnå og installere en skinnende ny SSL/TLS certifikat, du ønsker at sikre, at HTTPS altid bliver brugt.

for dine internet-apps, f.eks. MVC-programmer, kan du konfigurere trafik til at blive omdirigeret fra HTTP til HTTPS.

af forskellige årsager anbefales det stadig at holde standard HTTP-porten (port 80) åben og omdirigere dine brugere til standard HTTPS-porten (port 443) til internetapplikationer, der er tilgængelige via en bro.ser.

dette er en del af officiel rådgivning om bedste praksis inden for let ‘ s Encrypt-dokumentationen. Top sikkerhedsforsker, Scott Helm, har også en meget god artikel, der forklarer, hvorfor lukning af port 80 er dårlig for sikkerheden i forbindelse med internetapplikationer.

i afsnittene nedenfor demonstrerer jeg, hvordan man konfigurerer HTTPS-omdirigering til ASP.NET og ASP.NET centrale applikationer.

ASP.NET apps

den ASP.NET MVC rammer bekvemt har en indbygget RequireHttpsAttribute klasse, som vi kan benytte sig af.

når den anvendes, vil attributten medføre, at et omdirigeringsrespons sendes tilbage til klienten, hvis en anmodning blev sendt via HTTP i stedet for HTTPS.

attributten kan anvendes enten pr.controller eller PR. handling. Jeg anbefaler dog stærkt at anvende attributten globalt for at håndhæve HTTPS-omdirigering på tværs af hele siden, som vist nedenfor.

filtre.Tilføj (ny Krævttpsattribute());

ovenstående kodelinje vises typisk inden for en statisk RegisterGlobalFilters metode i en FilterConfig klasse, som i kodestykket nedenfor.

/// <resume> / / / registrerer globale filtre.///< / resume> / / / < param name="filters" >indsamling af filtre til registrering</param>offentlig statisk ugyldighedsregisterglobalfilters(GlobalFilterCollection filters){ filters.Tilføje (ny HandleErrorAttribute ()); filtre.Tilføje (ny Krævttpsattribute ()); filtre.Tilføj (ny Autorisationattribute());}

i en ASP.NET ansøgning, RegisterGlobalFilters – metoden kaldes normalt ved opstart fra Application_Start – metoden inden for det globale.asaks fil.

før du går videre, er det vigtigt at bemærke, at globale filtre kun gælder for HTTP-anmodninger, der sendes til dine controllere. Derfor er det stadig muligt for en klient at få adgang til statiske filer såsom stilark og scriptfiler over usikker HTTP.

du bør sørge for at bruge relative links til eventuelle statiske ressourcer, som du refererer fra din HTML, eller bruge absolutte URL ‘ er med HTTPS-ordningen for at sikre, at alt indhold bliver serveret sikkert.

Omskriv regler

for at gøre din internetapplikation endnu mere sikker Kan du konfigurere omdirigering på omvendt fuldmagtsniveau, f.eks. som en del af din IIS-konfiguration. Dette vil sikre, at alle indgående anmodninger bliver omdirigeret korrekt.

i tilfælde af IIS kan du implementere dette via en omskrivningsregel ved at tilføje følgende til dit internet.konfigurationsfil.

<Omskriv> <regler> <Regelnavn="HTTP til HTTPS redirect" stopProcessing="true"> <match url="(.*)" /> <betingelser> <Tilføj input="{HTTPS}" mønster="off" ignoreCase="true" /> </betingelser> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </regel> </regler></omskriv>

IIS respekterer ovenstående omskrivningsregel, når du håndterer indgående trafik, omdirigerer usikker trafik til https, før den når din applikationskode.

som med mange aspekter af sikkerhed tror jeg, at det er bedst at have flere lag af sikkerhed på plads. Hvis noget mislykkes eller fejlkonfigureres på et niveau, er det altid en god ting at have en tilbagegang.

. net Core

. net Core har også en indbygget RequireHttpsAttribute klasse, som kan anvendes enten på en per-controller/handling basis, eller det kan registreres globalt.

Global registrering kan indstilles inden for ConfigureServices – metoden i din Startup klasse, som vist nedenfor.

/// <resume> / / / denne metode bliver kaldt af runtime./// Brug denne metode til at tilføje tjenester til containeren.///< / sammendrag> / / / < param name="services" >indsamling af containertjenester</param>offentlige ugyldige Konfigurationstjenester(IServiceCollection services){ services.Addcontrollersmedvisninger (options => options.Opslagsfiltre.Tilføj (ny Krævttpsattribute()));}

ovenstående kode gør det samme grundlæggende som i en traditionel ASP.NET projekt.

men i.net Core kan vi gøre det bedre end dette.

. net Core har også indbygget HTTPS omdirigering mellemvare, som kan konfigureres med en linje kode, som vist nedenfor.

 app.UseHttpsRedirection ();

ovenstående kodelinje skal tilføjes til Configure – metoden i Startup – klassen. Det meste af standarden ASP.NET til MVC, konfigurere HTTPS omdirigering mellemvare automatisk.

nedenfor er et eksempel på det typiske indhold af Configure – metoden til reference.

/// <resume> / / / denne metode bliver kaldt af runtime./// Brug denne metode til at konfigurere HTTP-anmodningsrørledningen.///< / resume>/// <param name="app">applikationsbyggerobjektet, der bruges til at konfigurere anmodningsrørledningen</param>/// <param name="env">hostingmiljøet, som applikationen kører i</param>Public void Configure(iapplicationbuilder app, env){ if (env.IsDevelopment ()) {app.Usedeveloperekskceptionpage ();} else { app.Useekskceptionhandler ("/hjem / fejl"); app.UseHsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); app.Brug godkendelse (); app.UseEndpoints (endpoints => { endpoints.MapControllerRoute (navn: "standard", mønster: "{controller=Home}/{action=indeks}/{id?}"); });}

så hvorfor er HTTPS omdirigering mellemvare bedre end RequireHttpsAttribute filter?

nå, takket være den måde, at ASP.NET HTTPS-omdirigeringer anvendes på et højere niveau, og derfor vil anmodninger om statiske filer som stylesheets og scripts også blive omdirigeret ud over controller-bundne anmodninger.

HSTS

et andet nyttigt stykke ASP.NET Core mellemvare er HSTS mellemvare, og det er konfigureret i eksemplet ovenfor via følgende kodelinje.

 app.UseHsts ();

Bemærk, at som med mange af de indbyggede mellemvarekomponenter, mange mere avancerede aspekter af ASP.NET Core mellemvare kan konfigureres inden for ConfigureServices – metoden i din startklasse.

Hvad er HSTS, og hvorfor skal vi bruge det?

problemet med HTTPS-omdirigering alene er med den første usikre anmodning, der kommer ind i applikationen fra en klient.

hvis den første indgående HTTP-anmodning bliver opfanget af en ‘mand i midten’, vil anmodningens integritet gå tabt. For eksempel kan klienten omdirigeres et andet sted uden at de bemærker f.eks.

HSTS står for HTTP Strict Transport Security, og det hjælper med at løse problemet beskrevet ovenfor ved at informere bro.ser om, at en internetapplikation kun skal tilgås via HTTPS.

det gør det ved at returnere en streng-Transport-sikkerhed header i svaret, så efterfølgende anmodninger bruger HTTPS uden yderligere omdirigeringer. Brugeren cacher denne instruktion for at sikre, at yderligere besøg på siden vil være over HTTPS uden flere omdirigeringer.

den allerførste anmodning

ja, det lyder godt, men hvad med den allerførste anmodning?

vi har løst det meste af problemet, men vi har stadig ikke behandlet den allerførste anmodning modtaget fra en klient, der aldrig har besøgt vores side før.

for at være super-sikker og lukke sløjfen på dette, kan vi registrere vores hjemmeside for at blive ‘forudindlæst’. Hvis din hjemmeside er på denne liste, vil du aldrig modtage en usikker anmodning fra en klient, da brugeren vil respektere preload status.

du kan registrere din hjemmeside for at blive forudindlæst ved at gå til HSTS Preload hjemmeside og indsende en anmodning om at få den forudindlæst.

nedenfor er et eksempel på en HSTS-overskrift med det angivne preload-direktiv.

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

Bemærk, at det er yderst vigtigt, at du tester din hjemmeside grundigt, før du aktiverer HSTS i et produktionsmiljø for at sikre, at det fungerer korrekt via HTTPS. Dette er især vigtigt, hvis du vælger at forudindlæse din hjemmeside, da det ikke nemt kan fortrydes, og det kan tage måneder at få din hjemmeside fjernet fra forindlæsningslisten.

jeg kan varmt anbefale at konfigurere HSTS til dine applikationer. Hvorvidt du også vælger at få din hjemmeside forudindlæst, afhænger af dine specifikke sikkerhedskrav.

udgående regler

i henhold til afsnittet Omskrivningsregler fra tidligere i denne artikel kan du også aktivere HSTS på omvendt fuldmagtsniveau.

nedenfor er et eksempel på, hvordan du konfigurerer dette på et Internet.config fil, hvis du er vært for din ansøgning i IIS.

< Omskriv>< outboundRules>< Regelnavn="Tilføj streng-Transport-sikkerhed, når HTTPS" enabled="true">< match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" /> <betingelser> < Tilføj input= "{HTTPS} "pattern=" on " ignoreCase=" true "/> < / betingelser > <handlingstype= "Omskriv" værdi= "maks-alder=31536000" /> </regel></outboundRules></Omskriv>

nu vil HSTS-overskriften blive indstillet til al HTTPS-trafik på din side.

Bemærk, at ovenstående tilgang vil arbejde for både traditionelle ASP.NET og ASP.NET centrale applikationer. Du skal blot tilføje et Internet.konfigurationsfil til dit projekt, og sørg for, at egenskaben ‘Kopier til Output-mappe’ er indstillet til ‘Kopier Hvis nyere’.

API ‘er

API’ er adskiller sig ganske lidt fra normale internetapplikationer, som mennesker har adgang til, både i deres design, tilsigtede brugssager og sikkerhedshensyn.

vi dækker de bedste fremgangsmåder til at kræve HTTPS til API ‘ er i afsnittene nedenfor.

kræver HTTPS?

traditionel ASP.NET API-projekter har ikke adgang til en indbygget attribut til at kræve HTTPS.

dette forhindrer os dog ikke i at skabe vores egne.

nedenfor er et eksempel på, hvordan du gør dette.

/// <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 (anmodning.Anmodning) { Skema = Uri.UriSchemeHttps, Port = 443 }; handlingkontekst.Svar.Header.Placering = uriBuilder.Uri;} ellers handlingkontekst.Svar = anmodning.CreateResponse (HttpStatusCode.NotFound, "SSL er påkrævet"); }}

i ovenstående eksempel har jeg oprettet en klasse kaldet RequireHttpsAttribute, som stammer fra AuthorizationFilterAttribute klassen, og jeg tilsidesætter den virtuelle OnAuthorization metode.

for GET-anmodninger informerer ovenstående metode klienter om den korrekte URL ved hjælp af HTTPS-skemaet ved at returnere dette i Placeringsoverskriften. For alle andre anmodninger returneres meddelelsen ‘SSL’ simpelthen.

selvom dette giver mening, når du ringer til en API fra en bro.ser, er et af problemerne med ovenstående kode, at den returnerer en omdirigeringsstatuskode, som de fleste API-klienter ikke forstår.

afhængigt af dit synspunkt kan ovenstående kode i stedet ændres for at indstille HTTP-statuskoden til noget andet, såsom dårlig anmodning, snarere end at forsøge at omdirigere klienten.

vi kan implementere noget lignende i .NET Core ved at oprette vores egen klasse som ApiRequireHttpsAttribute, der stammer fra den indbyggede RequireHttpsAttribute klasse. Vi kan derefter tilsidesætte den virtuelle HandleNonHttpsRequest – metode og indstille svarkoden i overensstemmelse hermed i henhold til prøvekoden nedenfor.

/// <resume> / / / kaldes, hvis anmodningen ikke modtages via HTTPS.///</ resume>///<param name="filterkontekst">filterkonteksten< / param>beskyttet tilsidesættelse ugyldig Handlenonhttpsanmodning(Autorisationfilterkontekstfilterkontekst){ filterkontekst.Resultat = ny Statuscoderesultat (400);}

ovenstående kode indstiller HTTP-statuskoden for svaret på dårlig anmodning (400). Det kan ændres for at inkludere en besked i svaret eller hvilken som helst anden brugerdefineret logik der kræves.

lytter ikke?

Ok, så vi har set på, hvordan man tvinger API-klienter til at bruge HTTPS, når de forsøger at bruge HTTP.

er dette dog den bedste mulighed?

bedste praksis dikterer, at vi skal have flere lag af sikkerhed, men det dikterer også, at vi skal implementere sikkerhed så tidligt som muligt.

faktisk er det mest sikre, vi kan gøre i forbindelse med API ‘ er, at forhindre dem i at lytte på en ikke-sikker port i første omgang. Dette råd afspejles i Microsoft Docs for ASP.NET kerne.

selvfølgelig kan vi ikke forhindre en API-klient i at forsøge at nå vores API på en usikker måde. I dette tilfælde er det imidlertid API-integratorens skyld og ikke noget, som vi kan gøre noget meningsfuldt for at forhindre.

Resume

i denne artikel har jeg dækket, hvordan du håndhæver HTTPS på tværs af dine Internetapps og API ‘ er, og jeg har diskuteret de mest passende og sikre løsninger til begge scenarier.

den vigtigste ting at tage væk er, at du skal implementere flere lag af sikkerhed til din applikation og hvor det er muligt håndhæve sikkerhed så tidligt som muligt.

Gør brug af HST ‘ er og Udnyt kraften i din konfiguration af omvendt fuldmagt til at håndtere anmodninger på en sikker måde.