kuinka määrittää ASP.NET verkkosovellukset ja sovellusliittymät vaativat HTTPS

minkä tahansa Webissä isännöidyn sovelluksen osalta on tärkeää, että tietoturva on sisäänrakennettu alusta alkaen.
verkkosovelluksen mahdollistaminen turvalliseen liikenteeseen HTTPS: n kautta ja tämän käytännön noudattaminen on yksi ensimmäisistä asioista, jotka sinun pitäisi ottaa käyttöön.tämä on yhtä tärkeää verkkosovelluksissa kuin Sovellusliittymissäkin.

vakiintuneissa palveluissa, kuten Let ‘ s Encrypt, jotka tarjoavat ilmaisia TLS-varmenteita, ei ole enää mitään pakottavaa teknistä tai taloudellista syytä olla käyttämättä HTTPS: tä verkkosovelluksissasi.
tässä artikkelissa osoitan, miten verkkosovellukset konfiguroidaan oikein siten, että ne vaativat HTTPS: tä ja Katan esimerkkejä molemmista ASP.NET ja ASP.NET Ydinprojekteja.

HTTPS-uudelleenohjaus

varmistaaksesi, että sivustosi on suojattu oikein, hanki ja asenna kiiltävä uusi SSL/TLS-varmenne varmistamalla, että HTTPS on aina käytössä.

verkkosovelluksissa, esim. MVC-sovelluksissa, voit määrittää liikenteen ohjattavaksi HTTP: stä HTTPS: ään.

monista syistä on edelleen suositeltavaa pitää HTTP-oletusportti (portti 80) auki ja ohjata käyttäjät oletusarvoiseen HTTPS-porttiin (portti 443) verkkosovelluksille, joita käytetään selaimen kautta.

tämä on osa virallista parhaiden käytäntöjen neuvontaa Let ‘ s Encrypt-dokumentaatiossa. Huipputurvatutkija Scott Helmillä on myös erittäin hyvä artikkeli, joka selittää, miksi portin 80 sulkeminen on tietoturvan kannalta huono asia verkkosovellusten yhteydessä.

alla olevissa jaksoissa osoitan, miten HTTPS-uudelleenohjaus määritetään ASP.NET ja ASP.NET Core web-sovellukset.

ASP.NET verkkosovellukset

ASP.NET MVC frameworkissa on sopivasti sisäänrakennettu RequireHttpsAttribute – luokka, jota voimme hyödyntää.

käytettäessä attribuutti aiheuttaa uudelleenohjausvastauksen lähetettäväksi takaisin asiakkaalle, jos pyyntö lähetettiin HTTP: n eikä HTTPS: n kautta.

määritettä voidaan soveltaa joko ohjainkohtaisesti tai toimintakohtaisesti. Suosittelen kuitenkin, että määritettä sovelletaan maailmanlaajuisesti HTTPS-uudelleenohjauksen täytäntöönpanemiseksi koko sivustolla, kuten alla on esitetty.

 suodattimet.Lisää (uusi RequireHttpsAttribute());

yllä oleva koodirivi esiintyy tyypillisesti staattisessa RegisterGlobalFilters – menetelmässä FilterConfig – luokassa alla olevan koodinpätkän mukaisesti.

/// <Yhteenveto> / / / rekisteröi maailmanlaajuiset Suodattimet./// < / summary>/ / <param name="filters">the collection of filters to register< / param>public staattinen void RegisterGlobalFilters(GlobalFilterCollection filters){ filters.Lisää (uusi HandleErrorAttribute ()); suodattimet.Lisää (uusi RequireHttpsAttribute ()); suodattimet.Add (Uusi AuthorizeAttribute());}

vuonna ASP.NET RegisterGlobalFilters – menetelmää kutsutaan yleensä käynnistettäessä Application_Start-menetelmästä globaalissa.asax-tiedosto.

ennen kuin siirryt eteenpäin, on tärkeää huomata, että maailmanlaajuiset suodattimet koskevat vain HTTP-pyyntöjä, jotka välitetään ohjaimillesi. Siksi asiakkaan on edelleen mahdollista käyttää staattisia tiedostoja, kuten tyylisivuja ja komentosarjatiedostoja epävarmojen HTTP-tiedostojen kautta.

sinun tulee huolehtia siitä, että käytät suhteellisia linkkejä kaikkiin staattisiin resursseihin, joihin viittaat HTML-ohjelmassasi, tai käytä absoluuttisia URL-osoitteita HTTPS-järjestelmän kanssa varmistaaksesi, että kaikki sisältö tarjoillaan turvallisesti.

Rewrite rules

jotta verkkosovelluksesi olisi entistä turvallisempi, voit määrittää uudelleenohjauksen käänteisvälitystasolla esim.osana IIS-määritystäsi. Tämä varmistaa, että kaikki saapuvat pyynnöt ohjataan asianmukaisesti.

IIS: n tapauksessa voit toteuttaa tämän uudelleenkirjoitussäännön avulla lisäämällä seuraavan Webiisi.asetustiedosto.

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

IIS noudattaa yllä olevaa uudelleenkirjoitussääntöä käsitellessään saapuvaa liikennettä ja ohjaa epävarmaa liikennettä https: lle ennen kuin se saavuttaa sovelluskoodisi.

monien turvallisuusnäkökohtien tapaan katson, että on parasta, että käytössä on useita turvallisuuskerroksia. Jos jokin epäonnistuu tai jollakin tasolla tapahtuu väärin, varasuunnitelma on aina hyvä asia.

. Net Core

. Net Core on myös sisäänrakennettu RequireHttpsAttribute-luokka, jota voidaan soveltaa joko ohjaus – /toimintoperusteisesti tai se voidaan rekisteröidä maailmanlaajuisesti.

Maailmanlaajuinen rekisteröinti voidaan ottaa käyttöön ConfigureServices – menetelmällä Startup – luokassasi, kuten alla esitetään.

/// <Yhteenveto> / / tätä menetelmää kutsutaan suorituksen aikana./// Käytä tätä menetelmää palveluiden lisäämiseen säiliöön./// </summary>/ / <param name="services">the collection of container services< / param>public void ConfigureServices(IServiceCollection services){ services.AddControllersWithViews (options => options.Suodatin.Lisää (uusi RequireHttpsAttribute()));}

edellä koodi tekee saman asian pohjimmiltaan kuin perinteisessä ASP.NET projekti.

. Net-ytimessä pystymme kuitenkin parempaan.

. Net-ytimessä on myös sisäänrakennettu HTTPS-Uudelleenohjausväliohjelmisto, joka voidaan konfiguroida yhdellä koodirivillä, kuten alla on esitetty.

 app.UseHttpsRedirection ();

edellä mainittu koodirivi on lisättävä Configure – menetelmään, joka kuuluu Startup – luokkaan. Suurin osa standardista ASP.NET Core web-sovellusmallit esim. MVC, määritä HTTPS uudelleenohjaus väliohjelmisto automaattisesti.

alla on esimerkki Configure viitemenetelmän tyypillisestä sisällöstä.

/// <Yhteenveto> / / tätä menetelmää kutsutaan suorituksen aikana./// Käytä tätä menetelmää HTTP-pyyntöputken määrittämiseen./// </summary>// <param name="app">the application builder object used to configure the request pipeline</ param>/<param name="env">the web hosting environment the application is running in</ param>public void Configure(IApplicationBuilder app iwebhostenvironment env){ if (env.IsDevelopment ()) {app.UseDeveloperExceptionPage ();} else { app.UseExceptionHandler ("/Home / Error"); sovellus.UseHsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); sovellus.Use authorization (); app.UseEndpoints (endpoints => {endpoints.MapControllerRoute (name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); });}

miksi HTTPS-Uudelleenohjausvälisarja on siis parempi kuin RequireHttpsAttribute – suodatin?

hyvin, kiitos tavasta, että ASP.NET verkkosovelluksia isännöidään, väliohjelmiston HTTPS-uudelleenohjauksia sovelletaan korkeammalla tasolla ja siksi myös staattisia tiedostoja, kuten tyylisivuja ja skriptejä, koskevat pyynnöt uudelleenohjataan ohjaimiin sidottujen pyyntöjen lisäksi.

HSTS

toinen hyödyllinen ASP-kappale.NET Core middleware on HSTS-väliohjelmisto ja se on määritetty yllä olevassa esimerkissä seuraavalla koodirivillä.

 app.UseHsts ();

huomaa, että kuten monet sisäänrakennetut väliohjelmiston komponentit, monet kehittyneemmät näkökohdat ASP.NET Core middleware voidaan määrittää Käynnistysluokan ConfigureServices – menetelmällä.

mikä on HSTS ja miksi sitä pitäisi käyttää?

yksin HTTPS-uudelleenohjauksen ongelma on siinä ensimmäisessä epävarmassa pyynnössä, joka tulee sovellukseen asiakkaalta.

jos “mies keskellä” nappaa ensimmäisen saapuvan HTTP-pyynnön, pyynnön eheys menetetään. Asiakas voitaisiin esimerkiksi ohjata jonnekin muualle heidän huomaamattaan esimerkiksi tekaistulle kirjautumissivulle.

HSTS on lyhenne sanoista HTTP Strict Transport Security ja se auttaa ratkaisemaan yllä kuvatun ongelman ilmoittamalla selaimelle, että verkkosovellusta saa käyttää vain HTTPS: n kautta.

se tekee tämän palauttamalla vastauksessa tiukan Liikenneturvaotsikon niin, että myöhemmät pyynnöt käyttävät HTTPS: tä ilman muita uudelleenohjauksia. Selain kätkee tämän ohjeen varmistaakseen, että lisävierailut sivustolla ovat HTTPS: n yläpuolella ilman uudelleenohjauksia.

aivan ensimmäinen pyyntö

kyllä, että kaikki kuulostaa hyvältä, mutta entä se aivan ensimmäinen pyyntö?

olemme ratkaisseet suurimman osan ongelmasta, mutta emme ole vieläkään käsitelleet ensimmäistä pyyntöä, joka on saatu asiakkaalta, joka ei ole koskaan aiemmin vieraillut sivustollamme.

jotta voimme olla superturvallisia ja sulkea silmukan tästä, voimme rekisteröidä sivustomme “esiladatuksi”. Selaimet pitävät luetteloa sivustoista, jotka ovat “preload” – luettelossa, ja jos sivustosi on tässä luettelossa, et koskaan saa epävarmaa pyyntöä asiakkaalta, koska selain kunnioittaa preload-tilaa.

voit rekisteröidä sivustosi esiladattavaksi menemällä HSTS Preload-sivustolle ja lähettämällä pyynnön sen esiladaamisesta.

alla on esimerkki HSTS-otsakkeesta, jonka esijännitysdirektiivi on määritelty.

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

huomaa, että on erittäin tärkeää, että testaat sivustosi perusteellisesti ennen kuin otat HSTS: n käyttöön tuotantoympäristössä sen varmistamiseksi, että se toimii oikein HTTPS: n päällä. Tämä on erityisen tärkeää, jos päätät esilatata sivustosi, koska tätä ei voi helposti peruuttaa ja saattaa kestää kuukausia saada sivustosi poistettua esilatausluettelosta.

suosittelen HSTS: n määrittämistä verkkosovelluksiisi. Se, valitsetko myös sivustosi esiladatun, riippuu erityisistä turvallisuusvaatimuksistasi.

Outbound rules

kuten tämän artikkelin aiemmassa Rewrite rules-osiossa, voit ottaa HSTS: n käyttöön myös käänteisen välityspalvelimen tasolla.

alla on esimerkki siitä, miten tämä määritetään verkossa.config-tiedosto, jos isännöit hakemustasi IIS: ssä.

<rewrite> <outboundRules> <rule name="Add Strict-Transport-Security when HTTPS" enabled="true"> <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".* "/> < conditions> < add input="{HTTPS}" pattern= " on "ignoreCase= "true"/> < / conditions> <action type=" Rewrite"value=" max-age=31536000" /> </sääntö> </outboundRules>< / rewrite>

nyt HSTS-otsikko asetetaan kaikelle sivustosi HTTPS-liikenteelle.

huomaa, että edellä mainittu lähestymistapa toimii molemmissa perinteisissä ASP.NET ja ASP.NET Ydinsovellukset. Sinun tarvitsee vain lisätä Web.config tiedosto projektiin ja varmista, että ‘Kopioi Tulostushakemistoon’ ominaisuus on asetettu ‘Kopioi jos uudempi’.

sovellusliittymät

sovellusliittymät eroavat melko paljon tavallisista verkkosovelluksista, joita ihmiset käyttävät, sekä suunnittelultaan, käyttötarkoitukseltaan että turvallisuusnäkökohdiltaan.

kerromme alla olevista osioista parhaat käytännöt HTTPS: n vaatimiseen sovellusliittymiä varten.

vaativat HTTPS: tä?

perinteinen ASP.NET Web API-projekteilla ei ole pääsyä sisäänrakennettuun attribuuttiin HTTPS: n vaatimiseksi.

tämä ei kuitenkaan estä meitä luomasta omaa.

alla on esimerkki siitä, miten tämä tehdään.

/// <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 = Uusi UriBuilder(request.RequestUri) { Scheme = Uri.UriSchemeHttps: / / www.is. FI / haku/? query = 443 }; actionContext.Vastaus.Otsikko.Location = uriBuilder.Uri;} else actionconteksti.Vastaus = pyyntö.CreateResponse (HttpStatusCode.Ei löytynyt, "vaaditaan SSL"); }}

yllä olevassa esimerkissä olen luonut RequireHttpsAttribute – nimisen luokan, joka juontuu AuthorizationFilterAttribute – luokasta ja ohitan virtuaalisen OnAuthorization – menetelmän.

GET-pyynnöissä yllä oleva menetelmä ilmoittaa asiakkaille oikean URL-osoitteen HTTPS-järjestelmän avulla palauttamalla tämän sijainti-otsikossa. Kaikkiin muihin pyyntöihin viesti “SSL vaaditaan” yksinkertaisesti palautetaan.

vaikka tämä on järkevää, kun soitat API: ta selaimesta, yksi edellä mainitun koodin ongelmista on se, että se palauttaa uudelleenohjauksen tilakoodin, jota useimmat API-asiakkaat eivät ymmärrä.

näkökulmastasi riippuen yllä olevaa koodia voitaisiin sen sijaan muuttaa niin, että HTTP-tilakoodi asetettaisiin johonkin muuhun, kuten huonoon pyyntöön, sen sijaan, että asiakas yritettäisiin ohjata uudelleen.

voimme toteuttaa jotain vastaavaa .NETTOYDIN luomalla oman luokan, kuten ApiRequireHttpsAttribute , joka juontuu sisäänrakennetusta RequireHttpsAttribute luokasta. Tämän jälkeen voimme ohittaa virtuaalisen HandleNonHttpsRequest – menetelmän ja asettaa vastauskoodin sen mukaisesti alla olevan näytekoodin mukaisesti.

/// <Yhteenveto> / / soittaa, jos pyyntö ei vastaanota HTTPS: n kautta./// </summary>// <param name="filterContext">the filter context</ param>protected override void HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Tulos = Uusi StatusCodeResult (400);}

yllä oleva koodi asettaa HTTP-tilakoodin huonoon pyyntöön vastaamiselle (400). Sitä voidaan muuttaa sisällyttämään viesti vastaukseen tai mitä tahansa muuta mukautettua logiikkaa tarvitaan.

ei kuunnellut?

Ok, joten olemme tutkineet, miten pakotamme API-asiakkaat käyttämään HTTPS: tä aina, kun he yrittävät käyttää HTTP: tä.

onko tämä kuitenkin paras vaihtoehto?

paras käytäntö edellyttää, että meillä on oltava useita turvallisuuskerroksia, mutta se myös määrää, että meidän on toteutettava turvallisuus mahdollisimman varhaisessa vaiheessa.

itse asiassa varmin asia, jonka voimme tehdä API-ohjelmointirajapintojen yhteydessä, on estää heitä kuuntelemasta ei-turvatussa portissa. Tämä neuvo on peilattu Microsoft Docs varten ASP.NET ydin.

tietenkään emme voi estää API-asiakasta yrittämästä tavoittaa API: ta epävarmalla tavalla. Tässä tapauksessa se on kuitenkin API-integraattorin vika eikä asia, jonka estämiseksi voimme tehdä mitään mielekästä.

Yhteenveto

tässä artikkelissa olen käsitellyt HTTPS: n käyttöönottoa verkkosovelluksissasi ja Sovellusliittymissäsi ja olen keskustellut sopivimmista ja turvallisimmista ratkaisuista molempiin skenaarioihin.

olennaista on, että sovellukseesi otetaan käyttöön useita suojauskerroksia ja jos mahdollista, toteuta tietoturva mahdollisimman varhaisessa vaiheessa.

Hyödynnä HSTS: ää ja hyödynnä reverse proxy-asetuksesi voimaa pyyntöjen käsittelemiseksi turvallisesti.