slik konfigurerer du ASP.NET Web Apps og Apier for Å kreve HTTPS

for alle programmer som er vert på nettet, er det viktig at sikkerheten er innebygd fra starten.
Å Aktivere webapplikasjonen din for å betjene sikker trafikk over HTTPS og håndheve denne policyen er en av de første tingene du bør implementere, og dette er like viktig for webapper som Det er For Apier.

Med veletablerte tjenester Som Let ‘ S Encrypt som gir gratis tls-sertifikater, er det ikke lenger noen overbevisende teknisk eller økonomisk grunn til ikke å bruke HTTPS for webapplikasjonene dine.
i denne artikkelen demonstrerer jeg hvordan du konfigurerer webapplikasjonene dine riktig slik at DE krever HTTPS, og jeg dekker eksempler for begge ASP.NET og ASP.NET Kjerneprosjekter.

HTTPS-Omdirigering

for å sikre at nettstedet ditt er ordentlig sikret, må DU sørge for AT HTTPS alltid brukes etter at du har fått og installert et skinnende NYTT SSL/TLS-sertifikat.

for webappene dine, FOR EKSEMPEL MVC-applikasjoner, kan du konfigurere trafikk til å bli omdirigert FRA HTTP TIL HTTPS.

av en rekke årsaker er det fortsatt tilrådelig å holde STANDARD HTTP-port (port 80) åpen og omdirigere brukerne til standard HTTPS-port (port 443) for webapplikasjoner som er tilgjengelige via en nettleser.

Dette er en del av offisielle beste praksis råd i la Oss Kryptere dokumentasjon. Topp sikkerhetsforsker, Scott Helm, har også en veldig god artikkel som forklarer hvorfor lukking av port 80 er dårlig for sikkerhet i sammenheng med webapplikasjoner.

i avsnittene nedenfor viser jeg hvordan DU konfigurerer HTTPS-omdirigering for ASP.NET og ASP.NET Kjerne webapplikasjoner.

ASP.NET web apps

Den ASP.NET MVC framework har beleilig en innebygd RequireHttpsAttribute klasse som vi kan benytte oss av.

Når Attributtet brukes, Vil Det føre til at et omdirigeringssvar sendes tilbake til klienten hvis en forespørsel ble sendt VIA HTTP i STEDET FOR HTTPS.

Attributtet kan brukes enten per kontroller eller per handling. Jeg anbefaler imidlertid å bruke Attributtet globalt for å håndheve HTTPS-omdirigering over hele nettstedet, som vist nedenfor.

filtre.Legg til (ny RequireHttpsAttribute());

koden ovenfor vises vanligvis i en statisk RegisterGlobalFilters – metode i en FilterConfig – klasse, i henhold til kodebiten nedenfor.

/// <sammendrag>/// Registrerer Globale Filtre.///</ summary>// <param name= "filters" >samlingen av filtre for å registrere</param> offentlig statisk tomrom RegisterGlobalFilters(GlobalFilterCollection filters){ filters.Legg til (new HandleErrorAttribute ()); filtre.Legg til (nytt RequireHttpsAttribute ()); filtre.Legg til (new AuthorizeAttribute());}

I en ASP.NET søknad, kalles metoden RegisterGlobalFilters vanligvis ved oppstart fra metoden Application_Start I Den Globale.asax-fil.

før du går videre, er det viktig Å merke seg at globale filtre bare gjelder FOR HTTP-forespørsler som sendes til kontrollerne dine. Derfor er det fortsatt mulig for en klient å få tilgang til statiske filer som stilark og skriptfiler over usikker HTTP.

du bør passe på å bruke relative koblinger til statiske ressurser som du refererer til FRA HTML-KODEN din, eller bruk absolutte Nettadresser med HTTPS-ordningen for å sikre at alt innhold blir servert sikkert.

Omskrive regler

for å gjøre webapplikasjonen enda sikrere kan du konfigurere omdirigering på omvendt proxy-nivå, for eksempel som en del av IIS-konfigurasjonen. Dette vil sørge for at alle innkommende forespørsler blir omdirigert på riktig måte.

i TILFELLE AV IIS, kan du implementere dette via en omskrivningsregel ved å legge til Følgende På Nettet.config-fil.

< skriv >< regler > < regelnavn="HTTP til HTTPS-omdirigering" stopProcessing="true" > < match url=" (.*)" /> <betingelser> <legg til input="{HTTPS}" mønster="av" ignoreCase="true" /> </betingelser> </regler> </regler ></regler ></regler>< / omskrive> 

iis vil respektere omskrive regelen ovenfor når du håndterer innkommende trafikk, omdirigere usikker trafikk til https før den når programkoden.

som med mange aspekter av sikkerhet, tror jeg at det er best å ha flere lag med sikkerhet på plass. Hvis noe feiler eller er feilkonfigurert på ett nivå, er det alltid en god ting å ha en tilbakebetaling.

. NET Core

. NET Core har også en innebygd RequireHttpsAttribute klasse som kan brukes enten på en per-kontroller / handling basis eller det kan registreres globalt.

Global registrering kan settes opp i ConfigureServices – metoden i Startup – klassen, som vist nedenfor.

/// <sammendrag> / / / denne metoden blir kalt av runtime./// Bruk denne metoden til å legge til tjenester i beholderen.///</ sammendrag>// <param name= "tjenester" >innsamling av containertjenester</param> Offentlig ugyldig ConfigureServices(IServiceCollection services){ tjenester.AddControllersWithViews(alternativer => alternativer.Filter.Legg til (ny RequireHttpsAttribute()));}

ovennevnte kode gjør det samme fundamentalt som i en tradisjonell ASP.NET prosjekt.

MEN I. NET Core kan vi gjøre det bedre enn dette.

. NET Core har også innebygd HTTPS Omdirigering mellomvare, som kan konfigureres med en linje med kode, som vist nedenfor.

app.UseHttpsRedirection ();

ovennevnte kodelinje skal legges til Configure – metoden i Startup – klassen. Mesteparten av standarden ASP.NET Core web application maler f. eks FOR MVC, konfigurere HTTPS Omdirigering mellomvare automatisk.

Nedenfor er et eksempel på det typiske innholdet i Configure – metoden for referanse.

/// <sammendrag> / / / denne metoden blir kalt av runtime./// Bruk denne metoden til å konfigurere http-forespørselsrørledningen./// </summary>// <param name="app">application builder-objektet som brukes til å konfigurere forespørselsrørledningen</ param>/// <param name="env">webhotellmiljøet programmet kjører i</ param>Offentlig ugyldig Konfigurering(iapplicationbuilder app, iwebhostenvironment env){ if (env.IsDevelopment ()) {app.UseDeveloperExceptionPage ();} annet { app.UseExceptionHandler ("/Hjem / Feil"); app.Brukerhsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); app.UseAuthorization (); app.Brukendepunkter (endepunkter => { endepunkter.MapControllerRoute (navn: "standard", mønster: "{controller = Home} / {action = Index} / {id?}"); });}

Så hvorfor ER HTTPS-Omdirigering mellomvare bedre enn filteret RequireHttpsAttribute?

Vel, takk til måten det ASP.NET Kjerne web apps er vert, MIDDLEWARE HTTPS omdirigeringer brukes på et høyere nivå, og derfor forespørsler om statiske filer som stilark og skript vil også bli omdirigert i tillegg til controller-bundet forespørsler.

HSTS

Et annet nyttig STYKKE ASP.NET Core middleware er HSTS middleware og den er konfigurert i eksemplet ovenfor via følgende kodelinje.

app.UseHsts ();

Merk at som med mange av de innebygde mellomvarekomponentene, er mange mer avanserte aspekter av ASP.NET Kjerne mellomvare kan konfigureres i ConfigureServices – metoden i Oppstartsklassen.

HVA ER HSTS og hvorfor skal vi bruke DET?

problemet MED HTTPS omdirigering på egen hånd er med den første usikre forespørselen som kommer inn i programmet fra en klient.

hvis DEN første innkommende HTTP-forespørselen blir oppfanget av en mann i midten, vil integriteten til forespørselen gå tapt. For eksempel kan klienten bli omdirigert et annet sted uten at de merker f. eks. til en falsk påloggingsside.

HSTS står FOR HTTP Strict Transport Security, og hjelper til med å løse problemet beskrevet ovenfor ved å informere nettleseren om at en webapplikasjon bare skal nås VIA HTTPS.

det gjør Dette ved å returnere en Streng-Transport-Sikkerhetshode i svaret, slik at etterfølgende forespørsler bruker HTTPS uten ytterligere omdirigeringer. Nettleseren bufrer denne instruksjonen for å sikre at ytterligere besøk til nettstedet vil være OVER HTTPS uten flere omdirigeringer.

den aller første forespørselen

ja, det høres bra ut, men hva med den aller første forespørselen?

vi har løst det meste av problemet, men vi har fortsatt ikke behandlet den aller første forespørselen mottatt fra en klient som aldri har besøkt nettstedet vårt før.

for å være super-sikker og lukke sløyfen på dette, kan vi registrere vår side for å være ‘forhåndslastet’. Nettlesere har en liste over nettsteder som er på en ‘preload’ – liste, og hvis nettstedet ditt er på denne listen, vil du aldri motta en usikker forespørsel fra en klient, da nettleseren vil respektere preload-statusen.

du kan registrere at nettstedet ditt skal forhåndsinstalleres ved å gå til hsts Preload-nettstedet og sende inn en forespørsel om å få det forhåndsinstallert.

Nedenfor er et eksempel PÅ EN hsts-header med det angitte preload-direktivet.

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

Merk at det er ekstremt viktig at du tester nettstedet grundig før du aktiverer HSTS i et produksjonsmiljø for å sikre at DET fungerer riktig OVER HTTPS. Dette er spesielt viktig hvis du velger å forhåndslaste nettstedet ditt, da dette ikke lett kan angres, og det kan ta måneder å få nettstedet fjernet fra preload-listen.

jeg anbefaler på det sterkeste å konfigurere HSTS for webapplikasjonene dine. Hvorvidt du også velger å ha nettstedet forhåndsinstallert vil avhenge av dine spesifikke sikkerhetskrav.

Utgående regler

i Henhold til Delen Omskrivningsregler fra tidligere i denne artikkelen kan DU også aktivere HSTS på omvendt proxy-nivå.

Nedenfor er et eksempel på hvordan du konfigurerer dette i En Web.config-fil hvis du er vert for søknaden din i IIS.

< skriv om>< outboundRules > < regelnavn="Legg Til Streng-Transport-Sikkerhet når HTTPS" enabled="true" >< match serverVariable= "RESPONSE_Strict_Transport_Security"pattern=".* "/>< betingelser> < legg til input=" {HTTPS}"pattern=" på"ignoreCase=" true " / > < / betingelser>< handlingstype="Omskrive" value="max-age=31536000" /> </rule > < / outboundRules> < / rewrite> 

NÅ blir hsts-overskriften satt for ALL HTTPS-trafikk på nettstedet ditt.

Merk at ovennevnte tilnærming vil fungere for både tradisjonelle ASP.NET og ASP.NET Kjerne applikasjoner. Du trenger bare å legge Til En Web.konfig-fil til prosjektet ditt og sørg for at Egenskapen ‘Kopier Til Utdatakatalog’ er satt til ‘Kopier Hvis Nyere’.

Apier

Apier skiller seg ganske mye fra vanlige webapplikasjoner som nås av mennesker, både i design, tiltenkt bruk-saker og sikkerhetshensyn.

vi vil dekke de beste fremgangsmåtene for Å kreve HTTPS For Api-Er i avsnittene nedenfor.

Krever HTTPS?

Tradisjonell ASP.NET Web API-prosjekter har ikke tilgang til et innebygd Attributt for Å kreve HTTPS.

dette stopper Imidlertid Ikke oss fra å skape vår egen.

Nedenfor er et eksempel på hvordan du gjø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 (forespørsel.RequestUri) { Scheme = Uri.UriSchemeHttps, Port = 443}; actionContext.Svar.Topptekst.Plassering = uriBuilder.Uri;} annet actionContext.Svar = forespørsel.CreateResponse (HttpStatusCode.NotFound, "SSL er påkrevd"); }}

i eksemplet ovenfor har jeg opprettet en klasse kalt RequireHttpsAttribute som kommer fra AuthorizationFilterAttribute – klassen, og jeg overstyrer den virtuelle OnAuthorization – metoden.

FOR GET-forespørsler informerer metoden ovenfor klienter om riktig URL ved HJELP AV HTTPS-skjemaet ved å returnere dette i Stedshodet. For alle andre forespørsler, meldingen ‘SSL er nødvendig’ er bare returnert.

Selv om dette er fornuftig når du ringer EN API fra en nettleser, er et av problemene med koden ovenfor at den returnerer en omdirigeringsstatuskode som de FLESTE API-klienter ikke forstår.

avhengig av synspunktet ditt, kan koden ovenfor i stedet endres for å sette HTTP-Statuskoden til noe annet, for Eksempel Dårlig Forespørsel, i stedet for å prøve å omdirigere klienten.

Vi kan implementere noe lignende i .NETTO Kjerne ved å lage vår egen klasse som ApiRequireHttpsAttribute som stammer fra den innebygde RequireHttpsAttribute klassen. Vi kan da overstyre den virtuelle HandleNonHttpsRequest – metoden og angi svarkoden tilsvarende, i henhold til eksempelkoden nedenfor.

/// <sammendrag> / / / Kalles hvis forespørselen ikke mottas over HTTPS.///</ sammendrag>// <param name= "filterContext" > filterkonteksten < / param >beskyttet overstyring ugyldig HandleNonHttpsRequest (AuthorizationFilterContext filterContext){ filterContext.Resultat = ny Statuscoderesultat (400);} 

koden ovenfor angir HTTP-Statuskoden for svaret På Dårlig Forespørsel (400). Det kan endres for å inkludere en melding i svaret eller hva annen tilpasset logikk er nødvendig.

hører du ikke?

Ok, så Vi har sett på hvordan å tvinge API-klienter til å bruke HTTPS når de prøver Å bruke HTTP.

Men Er Dette det beste alternativet?

Beste praksis tilsier at vi bør ha flere lag med sikkerhet, men det tilsier også at vi bør implementere sikkerhet så tidlig som mulig.

faktisk er det sikreste vi kan gjøre i Sammenheng Med Apier, å hindre dem i å lytte på en usikker port i utgangspunktet. Dette rådet er speilet I Microsoft Docs for ASP.NET Kjerne.

Selvfølgelig kan Vi ikke forhindre AT EN API-klient prøver å nå VÅR API på en usikker måte. Men i dette tilfellet er DET FEILEN TIL API-integratoren og ikke noe som vi kan gjøre noe meningsfylt for å forhindre.

Sammendrag

I denne artikkelen har jeg dekket hvordan du håndhever HTTPS på tvers av webappene og Apiene dine, og jeg har diskutert de mest hensiktsmessige og sikre løsningene for begge scenariene.

det viktigste å ta bort er at du bør implementere flere lag med sikkerhet for søknaden din og om mulig håndheve sikkerhet så tidlig som mulig.

Benytt DEG AV HSTS og utnytt kraften i omvendt proxy-konfigurasjon for å håndtere forespørsler på en sikker måte.