cum să configurați ASP.NET aplicațiile Web și API-urile necesită HTTPS

pentru orice aplicație găzduită pe web, este esențial ca securitatea să fie încorporată de la început.
activarea aplicației dvs. web pentru a servi trafic securizat prin HTTPS și aplicarea acestei politici este unul dintre primele lucruri pe care ar trebui să le implementați și acest lucru este la fel de important pentru aplicațiile web ca și pentru API-uri.

cu servicii bine stabilite, cum ar fi Let ‘ s Encrypt, care oferă certificate TLS gratuite, nu mai există niciun motiv tehnic sau financiar convingător pentru a nu utiliza HTTPS pentru aplicațiile dvs. web.
în acest articol, vă demonstrez cum să configurați corect aplicațiile web astfel încât să necesite HTTPS și să acopăr exemple pentru ambele ASP.NET și ASP.NET proiecte de bază.

redirecționare HTTPS

pentru a vă asigura că site-ul dvs. este securizat corespunzător, după obținerea și instalarea unui nou certificat SSL/TLS strălucitor, veți dori să vă asigurați că HTTPS este întotdeauna utilizat.

pentru aplicațiile dvs. web, de exemplu, aplicațiile MVC, puteți configura traficul pentru a fi redirecționat de la HTTP la HTTPS.

din mai multe motive, este recomandabil să păstrați portul HTTP implicit (portul 80) deschis și să redirecționați utilizatorii către portul HTTPS implicit (portul 443) pentru aplicațiile web accesate printr-un browser.

aceasta face parte din sfaturile oficiale privind cele mai bune practici din documentația Let ‘ s Encrypt. Cercetătorul de securitate de top, Scott Helm, are, de asemenea, un articol foarte bun care explică de ce închiderea portului 80 este proastă pentru securitate în contextul aplicațiilor web.

în secțiunile de mai jos demonstrez cum se configurează redirecționarea HTTPS pentru ASP.NET și ASP.NET aplicații web de bază.

ASP.NET aplicații web

ASP.NET cadru MVC convenabil are un built-in RequireHttpsAttribute clasa pe care le putem beneficia de.

când este aplicat, atributul va determina trimiterea unui răspuns de redirecționare către client dacă o solicitare a fost trimisă prin HTTP în loc de HTTPS.

atributul poate fi aplicat fie pe bază de controler, fie pe bază de acțiune. Cu toate acestea, recomand cu tărie aplicarea atributului la nivel global pentru a impune redirecționarea HTTPS pe întregul site, așa cum se arată mai jos.

 filtre.Adauga (RequireHttpsAttribute nou());

linia de cod de mai sus apare de obicei într-o metodă statică RegisterGlobalFilters într-o clasă FilterConfig, conform fragmentului de cod de mai jos.

/// <rezumat> / / / înregistrează filtre globale.///< / rezumat> / / / < param name="filtre" >colecția de filtre pentru a înregistra</param> public static void RegisterGlobalFilters(filtre GlobalFilterCollection){ filtre.Adăuga(New HandleErrorAttribute ()); filtre.Adăuga(nou RequireHttpsAttribute ()); filtre.Adaugă (nou AuthorizeAttribute());}

într-un ASP.NET aplicație ,metoda RegisterGlobalFilters este de obicei apelată la pornire din metoda Application_Start din cadrul Global.dosarul asax.

înainte de a trece mai departe, este important să rețineți că filtrele globale se vor aplica numai cererilor HTTP care sunt transmise controlorilor dvs. Prin urmare, este încă posibil ca un client să acceseze fișiere statice, cum ar fi foi de stil și fișiere script prin HTTP nesigur.

ar trebui să aveți grijă să utilizați link-uri relative la orice resurse statice la care faceți referire din HTML sau să utilizați URL-uri absolute cu schema HTTPS pentru a vă asigura că tot conținutul este servit în siguranță.

rescrie reguli

pentru a face aplicația web și mai sigură, puteți configura redirecționarea la nivel proxy invers, de exemplu, ca parte a configurației IIS. Acest lucru vă va asigura că toate cererile primite sunt redirecționate în mod corespunzător.

în cazul IIS, puteți implementa acest lucru printr-o regulă de rescriere adăugând următoarele pe Web.fișier de configurare.

<rescrie ><reguli ><rule name="HTTP la HTTPS redirect" stopProcessing="adevărat"> <match url="(.*)" /> <condiții> <Adăugare intrare="{HTTPS}" model="oprit" ignoreCase="adevărat" /> </condiții> <Tip acțiune="redirecționare" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </regulă> </reguli></rewrite>

IIS va respecta regula de rescriere de mai sus atunci când gestionează traficul de intrare, redirecționând traficul nesigur către https înainte de a ajunge la codul aplicației.

ca și în multe aspecte ale securității, cred că cel mai bine este să aveți mai multe straturi de securitate la locul lor. Dacă ceva eșuează sau este configurat greșit la un nivel, a avea o rezervă este întotdeauna un lucru bun.

. net Core

. net Core are, de asemenea, o clasă încorporată RequireHttpsAttribute care poate fi aplicată fie pe bază de control/acțiune, fie poate fi înregistrată la nivel global.

înregistrarea globală poate fi configurată în cadrul metodei ConfigureServices a clasei dvs. Startup, după cum se demonstrează mai jos.

/// <rezumat> / / / această metodă este apelată de runtime./// Utilizați această metodă pentru a adăuga servicii în container.///< / rezumat> / / / < param name="Servicii" >colectarea serviciilor de containere</param>public Void ConfigureServices(IServiceCollection services){ Servicii.AddControllersWithViews (opțiuni => opțiuni.Filtre.Adauga (RequireHttpsAttribute nou()));}

codul de mai sus face același lucru fundamental ca într-un tradițional ASP.NET proiect.

cu toate acestea, în.Net Core, putem face mai bine decât aceasta.

. net Core are, de asemenea, middleware de redirecționare HTTPS încorporat, care poate fi configurat cu o singură linie de cod, așa cum se arată mai jos.

 app.UseHttpsRedirection ();

linia de cod de mai sus trebuie adăugată la metoda Configure a clasei Startup. Cea mai mare parte a standardului ASP.NET șabloane de aplicații web de bază, de exemplu, pentru MVC, configurați automat middleware-ul de redirecționare HTTPS.

mai jos este un exemplu de conținut tipic al metodei Configure pentru referință.

/// <rezumat> / / / această metodă este apelată de runtime./// Utilizați această metodă pentru a configura conducta de solicitare HTTP./// </rezumat>/// <param name="app">obiectul constructor de aplicații utilizat pentru a configura conducta de cerere</param>/// <param name="env">mediul de găzduire web aplicația rulează în</param>configurare publică a vidului(aplicația IApplicationBuilder, iwebhostenvironment env){ dacă (env.IsDevelopment ()) {aplicație.UseDeveloperExceptionPage ();} else { app.UseExceptionHandler ("/acasă / eroare"); app.UseHsts ();} aplicație.UseHttpsRedirection (); aplicație.UseStaticFiles (); aplicație.UseRouting (); aplicație.Useautorization (); app.UseEndpoints (endpoints => { endpoints.MapControllerRoute (nume: "implicit", model: "{controller=acasă}/{action=Index}/{id?}"); });}

deci, de ce este middleware-ul de redirecționare HTTPS mai bun decât filtrul RequireHttpsAttribute?

Ei bine, datorită modului în care ASP.NET aplicațiile web de bază sunt găzduite, redirecționările https middleware sunt aplicate la un nivel superior și, prin urmare, cererile de fișiere statice, cum ar fi foile de stil și scripturile, vor fi, de asemenea, redirecționate pe lângă solicitările legate de controler.

HSTS

o altă piesă utilă de ASP.Net core middleware este HSTS middleware și este configurat în exemplul de mai sus prin următoarea linie de cod.

 app.UseHsts ();

rețineți că, la fel ca în multe dintre componentele middleware încorporate, multe aspecte mai avansate ale ASP.NET Core middleware poate fi configurat în ConfigureServices metoda de clasa de pornire.

ce este HSTS și de ce ar trebui să-l folosim?

problema cu redirecționarea HTTPS pe cont propriu este cu acea primă solicitare nesigură care vine în aplicație de la un client.

dacă prima solicitare HTTP primită este interceptată de un ‘om în mijloc’, integritatea cererii va fi pierdută. De exemplu, clientul ar putea fi redirecționat în altă parte fără ca acesta să observe, de exemplu, o pagină de conectare falsă.

HSTS înseamnă HTTP Strict Transport Security și ajută la rezolvarea problemei descrise mai sus, informând browserul că o aplicație web ar trebui accesată numai prin HTTPS.

face acest lucru returnând un antet Strict-Transport-Security în răspuns, astfel încât cererile ulterioare să utilizeze HTTPS fără alte redirecționări. Browserul memorează în cache această instrucțiune pentru a se asigura că vizitele ulterioare pe site vor fi peste HTTPS fără alte redirecționări.

prima cerere

da, toate sună grozav, dar ce zici de prima cerere?

am rezolvat cea mai mare parte a problemei, dar încă nu ne-am ocupat de prima solicitare primită de la un client care nu a vizitat niciodată site-ul nostru.

pentru a fi super-sigur și a închide bucla în acest sens, putem înregistra site-ul nostru pentru a fi ‘preîncărcat’. Browserele păstrează o listă de site-uri care se află pe o listă de preîncărcare și dacă site-ul dvs. se află pe această listă, atunci nu veți primi niciodată o solicitare nesigură de la un client, deoarece browserul va onora starea de preîncărcare.

puteți înregistra site-ul dvs. pentru a fi preîncărcat accesând site-ul web preîncărcat HSTS și trimițând o solicitare de preîncărcare a acestuia.

mai jos este un exemplu de antet HSTS cu Directiva de preîncărcare specificată.

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

rețineți că este extrem de important să testați site-ul dvs. cu atenție înainte de a activa HSTS într-un mediu de producție pentru a vă asigura că funcționează corect prin HTTPS. Acest lucru este deosebit de important dacă alegeți să preîncărcați site-ul dvs., deoarece acest lucru nu poate fi ușor anulat și ar putea dura luni de zile pentru a elimina site-ul dvs. din lista de preîncărcare.

vă recomand să configurați HSTS pentru aplicațiile dvs. web. Indiferent dacă alegeți sau nu să aveți site-ul dvs. preîncărcat, va depinde de cerințele dvs. specifice de securitate.

reguli de ieșire

conform secțiunii reguli de rescriere de la începutul acestui articol, puteți activa și HSTS la nivel proxy invers.

mai jos este un exemplu de cum să configurați acest lucru într-un Web.fișier de configurare dacă găzduiți aplicația în IIS.

<rewrite ><outboundRules ><rule name="adăugați Strict-Transport-securitate atunci când HTTPS" enabled="true"> <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".* "/> <condiții> < add input=" {HTTPS} "pattern =" on "ignoreCase=" true " / > < / condiții > <action type=" Rewrite "value =" max-age=31536000" /> </regula></outboundRules></rescrie>

acum antetul HSTS va fi setat pentru tot traficul HTTPS de pe site-ul dvs.

rețineți că abordarea de mai sus va funcționa atât pentru tradiționale ASP.NET și ASP.NET aplicații de bază. Trebuie doar să adăugați un Web.config fișier pentru proiectul dumneavoastră și asigurați-vă că că ‘Copy la ieșire Directory’ proprietate este setat la ‘Copy dacă mai nou’.

API-urile

API-urile diferă destul de mult de aplicațiile web normale accesate de oameni, atât în ceea ce privește designul, cazurile de utilizare intenționate, cât și considerentele de securitate.

vom acoperi cele mai bune practici pentru solicitarea HTTPS pentru API-uri în secțiunile de mai jos.

necesită HTTPS?

tradiționale ASP.NET proiectele API web nu au acces la un atribut încorporat pentru solicitarea HTTPS.

cu toate acestea, acest lucru nu ne împiedică să creăm propria noastră.

mai jos este un exemplu de cum se face acest lucru.

/// <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 = UriBuilder nou (cerere.RequestUri) {Scheme = Uri.UriSchemeHttps, Port = 443}; actionContext.Răspuns.Anteturi.Locație = uriBuilder.Uri;} else actionContext.Răspuns = cerere.CreateResponse(HttpStatusCode.NotFound, "SSL este necesar"); }}

în exemplul de mai sus, am creat o clasă numită RequireHttpsAttribute care derivă din clasa AuthorizationFilterAttribute și suprascriu metoda virtuală OnAuthorization.

pentru solicitări GET, metoda de mai sus informează clienții despre adresa URL corectă folosind schema HTTPS returnând acest lucru în antetul locației. Pentru toate celelalte solicitări, mesajul ‘SSL is required’ este pur și simplu returnat.

deși acest lucru are sens atunci când apelați un API dintr-un browser, una dintre problemele cu codul de mai sus este că returnează un cod de stare de redirecționare pe care majoritatea clienților API nu îl vor înțelege.

în funcție de punctul dvs. de vedere, codul de mai sus ar putea fi modificat în schimb pentru a seta codul de stare HTTP la altceva, cum ar fi o solicitare necorespunzătoare, în loc să încercați să redirecționați clientul.

putem implementa ceva similar în .Net Core prin crearea propriei noastre clase, cum ar fi ApiRequireHttpsAttribute care derivă din clasa RequireHttpsAttribute încorporată. Putem apoi să suprascriem metoda virtuală HandleNonHttpsRequest și să setăm Codul De răspuns în consecință, conform Codului eșantion de mai jos.

/// <rezumat> / / / numit dacă cererea nu este primită prin HTTPS.///< / rezumat> / / / < param name="filterContext" >contextul filtrului</param>protejat suprascrie void HandleNonHttpsRequest(AuthorizationFilterContext filterContext){ filterContext.Rezultat = nou StatusCodeResult(400);} 

codul de mai sus setează codul de stare HTTP pentru răspunsul la solicitarea necorespunzătoare (400). Ar putea fi modificat pentru a include un mesaj în răspuns sau orice altă logică personalizată este necesară.

nu asculți?

Ok, așa că am analizat cum să forțăm clienții API să utilizeze HTTPS ori de câte ori încearcă să utilizeze HTTP.

cu toate acestea, este aceasta cea mai bună opțiune?

cele mai bune practici dictează că ar trebui să avem mai multe straturi de securitate, dar, de asemenea, dictează că ar trebui să implementăm securitatea cât mai curând posibil.

de fapt, cel mai sigur lucru pe care îl putem face în contextul API-urilor este să le împiedicăm să asculte pe un port nesecurizat în primul rând. Acest sfat este reflectat în documentele Microsoft pentru ASP.NET miezul.

desigur, nu putem împiedica un client API să încerce să ajungă la API-ul nostru într-un mod nesigur. Cu toate acestea, în acest caz, este vina integratorului API și nu ceva pentru care putem face ceva semnificativ pentru a preveni.

rezumat

în acest articol, am acoperit modul de aplicare a HTTPS în aplicațiile web și API-urile dvs. și am discutat despre cele mai potrivite și mai sigure soluții pentru ambele scenarii.

lucrul cheie de luat este că ar trebui să implementați mai multe straturi de securitate pentru aplicația dvs. și, acolo unde este posibil, să impuneți securitatea cât mai curând posibil.

face uz de HSTS și pârghie puterea de configurare proxy inversă să se ocupe de cereri într-un mod sigur.