ASP.NET webapps en API’ s om HTTPS

te vereisen voor elke toepassing die op het web wordt gehost, is het essentieel dat beveiliging vanaf het begin is ingebouwd.
het inschakelen van uw webapplicatie om veilig verkeer via HTTPS te bedienen en het afdwingen van dit beleid is een van de eerste dingen die u moet implementeren en dit is net zo belangrijk voor webapps als voor API ‘ s.

met gevestigde diensten zoals Let ‘ s Encrypt die gratis TLS-certificaten bieden, is er geen dwingende technische of financiële reden meer om HTTPS niet te gebruiken voor uw webapplicaties.
In dit artikel laat ik zien hoe u uw webapplicaties correct kunt configureren, zodat ze HTTPS nodig hebben. ASP.NET en ASP.NET kernprojecten.

https-omleiding

om er zeker van te zijn dat uw site goed beveiligd is, moet u er na het verkrijgen en installeren van een glanzend nieuw SSL/TLS-certificaat zeker van zijn dat HTTPS altijd gebruikt wordt.

voor uw webapps, bijvoorbeeld MVC-toepassingen, kunt u het verkeer configureren om te worden omgeleid van HTTP naar HTTPS.

om verschillende redenen is het nog steeds raadzaam om de standaard HTTP-poort (poort 80) open te houden en uw gebruikers om te leiden naar de Standaard HTTPS-poort (poort 443) voor webtoepassingen die via een browser worden benaderd.

dit maakt deel uit van het officiële best practice advies binnen de Let ‘ s Encrypt documentatie. Top security onderzoeker, Scott Helm, heeft ook een zeer goed artikel dat uitlegt waarom het sluiten van poort 80 is slecht voor de veiligheid in de context van webapplicaties.

in de secties hieronder laat ik zien hoe u HTTPS-omleiding kunt configureren voor ASP.NET en ASP.NET kern webtoepassingen.

ASP.NET webapps

de ASP.NET MVC framework heeft een ingebouwde RequireHttpsAttribute klasse waar we gebruik van kunnen maken.

indien toegepast, zal het attribuut ervoor zorgen dat een redirect-antwoord wordt teruggestuurd naar de client als een verzoek via HTTP in plaats van HTTPS is verzonden.

het kenmerk kan per controller of per actie worden toegepast. Echter, Ik beveel het toepassen van het attribuut wereldwijd om HTTPS omleiding af te dwingen over de hele site, zoals hieronder weergegeven.

filters.Toevoegen (nieuwe RequireHttpsAttribute());

de bovenstaande regel code verschijnt meestal binnen een statische RegisterGlobalFilters methode in een FilterConfig klasse, volgens het onderstaande codefragment.

/// <samenvatting> / / / registreert globale Filters.///</ summary>// / <param name= "filters" >the collection of filters to Registry< / param>public static void RegisterGlobalFilters (GlobalFilterCollection filters){ filters.Toevoegen (nieuwe HandleErrorAttribute ()); filters.Toevoegen (new RequireHttpsAttribute ()); filters.Toevoegen(nieuwe Autorizeattribute)());}

In een ASP.NET toepassing, de RegisterGlobalFilters methode wordt meestal aangeroepen bij het opstarten van de Application_Start methode binnen de Globale.asax dossier.

voordat u verder gaat, is het belangrijk op te merken dat globale filters alleen van toepassing zijn op HTTP-verzoeken die aan uw controllers worden doorgegeven. Daarom is het nog steeds mogelijk voor een client om toegang te krijgen tot statische bestanden zoals stylesheets en scriptbestanden via onveilige HTTP.

u dient ervoor te zorgen dat u relatieve koppelingen gebruikt naar statische bronnen waarnaar u vanuit uw HTML verwijst, of dat u absolute URL ‘ s gebruikt met het HTTPS-schema om ervoor te zorgen dat alle inhoud veilig wordt aangeboden.

regels herschrijven

om uw webtoepassing nog veiliger te maken, kunt u omleiding configureren op het reverse-proxy-niveau, bijvoorbeeld als onderdeel van uw IIS-configuratie. Dit zorgt ervoor dat alle inkomende verzoeken op de juiste manier worden omgeleid.

in het geval van IIS kunt u dit implementeren via een herschrijfregel door het volgende toe te voegen aan uw Web.configuratiebestand.

<rewrite> <rules> <rule name= "HTTP to HTTPS redirect" stopProcessing= "true" > <match url=" (.*)" /> <voorwaarden> <toevoegen ingang="{HTTPS}" patroon="off" ignoreCase="true" /> </voorwaarden> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"redirectType="Permanente" /> </regel> </regels></herschrijven>

IIS-respecteren van de hierboven herschrijven regel bij de behandeling van inkomende verkeer omleiden van onveilige verkeer naar HTTPS voordat het naar uw applicatie code.

zoals bij veel aspecten van beveiliging, denk ik dat het het beste is om meerdere beveiligingslagen te hebben. Als iets faalt of verkeerd is geconfigureerd op één niveau, is een fallback altijd een goede zaak.

. net Core

. net Core heeft ook een ingebouwde RequireHttpsAttribute klasse die kan worden toegepast op een per-controller / actie basis of het kan globaal worden geregistreerd.

algemene registratie kan worden ingesteld binnen de ConfigureServices methode van uw Startup klasse, zoals hieronder wordt aangetoond.

/// <samenvatting> / / / deze methode wordt aangeroepen door de runtime./// Gebruik deze methode om services toe te voegen aan de container.///< / summary> / / / <param name = "services" >the collection of container services< / param>public void Configurereservices (IServiceCollection services){ services.Addcontrollers met weergaven (opties = > opties.Filter.Toevoegen (nieuwe RequireHttpsAttribute()));}

de bovenstaande code doet fundamenteel hetzelfde als in een traditionele ASP.NET project.

echter, in. net Core, kunnen we beter doen dan dit.

. net Core heeft ook ingebouwde https Redirection middleware, die kan worden geconfigureerd met één regel code, zoals hieronder weergegeven.

 app.UseHttpsRedirection ();

de bovenstaande regel code moet worden toegevoegd aan de Configure methode van de Startup klasse. Het grootste deel van de standaard ASP.NET Core web application templates bijvoorbeeld voor MVC, configureer de HTTPS Redirection middleware automatisch.

Hieronder is een voorbeeld van de typische inhoud van de Configure referentiemethode.

/// <samenvatting> / / / deze methode wordt aangeroepen door de runtime./// Gebruik deze methode om de HTTP request pipeline te configureren.///</ 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.Usedevelopexceptionpage ();} else { app.UseExceptionHandler ("/Home / Error"); app.UseHsts ();} app.UseHttpsRedirection (); app.UseStaticFiles (); app.UseRouting (); app.UseAuthorization (); app.UseEndpoints (endpoints => { endpoints.MapControllerRoute (name: "default", pattern: "{controller = Home} / {action = Index} / {id?}"); });}

dus waarom is de HTTPS Redirection middleware beter dan de RequireHttpsAttribute filter?

nou, dankzij de manier waarop ASP.NET Core web apps worden gehost, de middleware https omleidingen worden toegepast op een hoger niveau en daarom aanvragen voor statische bestanden zoals stylesheets en scripts zullen ook worden doorgestuurd in aanvulling op controller-gebonden aanvragen.

HST ‘ s

een ander nuttig stuk ASP.NET Core middleware is de HSTS middleware en het is geconfigureerd in het bovenstaande voorbeeld via de volgende regel code.

 app.UseHsts ();

merk op dat, zoals bij veel van de ingebouwde middleware componenten, veel meer geavanceerde aspecten van ASP.NET Core middleware kan worden geconfigureerd binnen de ConfigureServices methode van uw Opstartklasse.

Wat is HST ‘ s en waarom zouden we het moeten gebruiken?

het probleem met https-omleiding op zichzelf is met dat eerste onveilige verzoek dat in de toepassing komt van een client.

als het eerste inkomende HTTP-verzoek wordt onderschept door een’ man in het midden’, zal de integriteit van het verzoek verloren gaan. Bijvoorbeeld, de klant kan worden omgeleid ergens anders zonder dat ze merken b.v. naar een nep-login pagina.

HSTS staat voor HTTP Strict Transport Security en het helpt het hierboven beschreven probleem op te lossen door de browser te informeren dat een webtoepassing alleen via HTTPS toegankelijk moet zijn.

het doet dit door het retourneren van een strikte-Transport-Security header in het antwoord, zodat volgende verzoeken HTTPS gebruiken zonder verdere omleidingen. De browser caches deze instructie om ervoor te zorgen dat verdere bezoeken aan de site zal worden over HTTPS zonder meer omleidingen.

het allereerste verzoek

Ja, Dat klinkt allemaal geweldig, maar hoe zit het met dat allereerste verzoek?

we hebben het grootste deel van het probleem opgelost, maar we hebben nog steeds niet gereageerd op het allereerste verzoek dat werd ontvangen van een client die onze site nooit eerder heeft bezocht.

om superveilig te zijn en de lus hierop te sluiten, kunnen we onze site registreren om te worden ‘voorgeladen’. Browsers houden een lijst bij van sites die op een ‘preload’ lijst staan en als uw site op deze lijst staat, zult u nooit een onveilig verzoek van een client ontvangen omdat de browser de preload status zal respecteren.

u kunt uw site registreren om te worden voorgeladen door naar de HSTS Preload-website te gaan en een verzoek in te dienen om de site vooraf te laden.

Hieronder is een voorbeeld van een HST-header met de preload-richtlijn gespecificeerd.

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

merk op dat het uiterst belangrijk is dat u uw site grondig test voordat u HST ‘ s in een productieomgeving inschakelt om er zeker van te zijn dat het correct werkt via HTTPS. Dit is vooral belangrijk als u ervoor kiest om uw site vooraf te laden, omdat dit niet gemakkelijk ongedaan kan worden gemaakt en het maanden kan duren voordat uw site uit de preload-lijst is verwijderd.

ik beveel het configureren van HST ‘ s voor uw webapplicaties ten zeerste aan. Of u er ook voor kiest om uw site vooraf te laten laden, hangt af van uw specifieke beveiligingsvereisten.

Uitgaande regels

volgens de sectie regels herschrijven van eerder in dit artikel, kunt u ook HST ‘ s inschakelen op het niveau van reverse proxy.

Hieronder is een voorbeeld van hoe dit te configureren binnen een Web.configuratiebestand als u uw toepassing host in IIS.

<herschrijven> <outboundRules> <rule name= "Add Strict-Transport-Security when HTTPS"enabled="true"> <match serverVariable=" RESPONSE_Strict_Transport_Security"pattern=".*" /> <voorwaarden> <toevoegen ingang="{HTTPS}" patroon="on" ignoreCase="true" /> </voorwaarden> <action type="Herschrijven" waarde="max-age=31536000" /> </regel> </outboundRules></herschrijven>

Nu de HST ‘ s de header instellen voor alle HTTPS-verkeer op uw site.

merk op dat de bovenstaande aanpak zal werken voor zowel traditionele ASP.NET en ASP.NET kerntoepassingen. Je hoeft alleen maar een Web toe te voegen.config bestand naar uw project en zorg ervoor dat de eigenschap ‘Copy to Output Directory’ is ingesteld op ‘Copy if Newer’.

API ‘s

API’ s verschillen nogal wat van normale webtoepassingen die door mensen worden benaderd, zowel in hun ontwerp, beoogde use-cases en veiligheidsoverwegingen.

we behandelen de beste praktijken voor het vereisen van HTTPS voor API ‘ s in de onderstaande paragrafen.

vereist HTTPS?

traditioneel ASP.NET Web API-projecten hebben geen toegang tot een ingebouwd attribuut voor het vereisen van HTTPS.

echter, dit weerhoudt ons niet van het creëren van onze eigen.

Hieronder is een voorbeeld van hoe dit te doen.

/// <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 = nieuwe UriBuilder (aanvraag.RequestUri) { Scheme = Uri.UriSchemeHttps, Port = 443 }; actionContext.Reactie.Header.Location = uriBuilder.Uri;} else actionContext.Antwoord = verzoek.CreateResponse (HttpStatusCode.Niet gevonden, "SSL is vereist"); }}

in het bovenstaande voorbeeld heb ik een class genaamd RequireHttpsAttribute aangemaakt die afgeleid is van de class AuthorizationFilterAttribute en ik overschrijf de virtual OnAuthorization methode.

voor GET-aanvragen informeert de bovenstaande methode cliënten over de juiste URL met behulp van het HTTPS-schema door deze terug te sturen in de Locatiekop. Voor alle andere verzoeken wordt het bericht ‘SSL is required’ gewoon teruggestuurd.

hoewel dit zinvol is wanneer een API wordt aangeroepen vanuit een browser, is een van de problemen met de bovenstaande code dat het een redirect-statuscode retourneert die de meeste API-clients niet zullen begrijpen.

afhankelijk van uw standpunt, kan de bovenstaande code worden gewijzigd om de HTTP-statuscode op iets anders in te stellen, zoals Bad Request, in plaats van te proberen de client om te leiden.

we kunnen iets dergelijks implementeren in .NET Core door het creëren van onze eigen klasse, zoals ApiRequireHttpsAttribute die is afgeleid van de ingebouwde RequireHttpsAttribute klasse. We kunnen dan de virtuele HandleNonHttpsRequest methode overschrijven en de responscode dienovereenkomstig instellen, volgens de voorbeeldcode hieronder.

/// <samenvatting> / / / aangeroepen als het verzoek niet via HTTPS wordt ontvangen.///</ summary>// / <param name= "filterContext" >the filtercontext< / param>protected override void HandleNonHttpsRequest (AuthorizationFilterContext filterContext){ filterContext.Resultaat = Nieuwe StatusCodeResult (400);}

bovenstaande code stelt de HTTP-statuscode in voor het antwoord op slecht verzoek (400). Het kan worden gewijzigd om een bericht op te nemen in het antwoord of welke andere aangepaste logica dan ook vereist is.

niet luisteren?

Ok, dus we hebben gekeken hoe we API-clients kunnen dwingen https te gebruiken wanneer ze HTTP proberen te gebruiken.

is dit echter de beste optie?

beste praktijken schrijven voor dat we meerdere beveiligingslagen moeten hebben, maar het schrijft ook voor dat we beveiliging zo vroeg mogelijk moeten implementeren.

eigenlijk is het veiligste wat we kunnen doen in de context van API ‘ s om te voorkomen dat ze luisteren op een niet-beveiligde poort in de eerste plaats. Dit advies wordt gespiegeld in de Microsoft Docs voor ASP.NET kern.

natuurlijk kunnen we niet voorkomen dat een API-client probeert onze API op een onveilige manier te bereiken. Echter, in dit geval, het is de schuld van de API integrator en niet iets waarvoor we iets betekenisvol kunnen doen om te voorkomen.

samenvatting

In dit artikel heb ik besproken hoe u HTTPS kunt afdwingen in uw webapps en API ‘s en heb ik de meest geschikte en veilige oplossingen voor beide scenario’ s besproken.

het belangrijkste om weg te nemen is dat u meerdere beveiligingslagen voor uw toepassing moet implementeren en waar mogelijk beveiliging zo vroeg mogelijk moet afdwingen.

maak gebruik van HST ‘ s en gebruik de kracht van uw reverse proxy-configuratie om aanvragen op een veilige manier af te handelen.