In un contesto di produzione, spesso è preferibile evitare di esporre un sito ASP.NET Core direttamente sul web, sfruttando invece un reverse proxy. Questa soluzione offre infatti diversi vantaggi, sia dal punto di vista della sicurezza, ma soprattuto pratico:
- TLS termination: installando i certificati TLS sul reverse proxy, lasciando la comunicazione tra il proxy e i web server in HTTP;
- Routing, tramite cui esporre più applicazioni logicamente distinte dietro il medesimo dominio;
- Load balancing, distribuendo il traffico su diversi web server in modo da ottenere una maggiore scalabilità.
Per chi dovesse essere interessato, abbiamo parlato di questo argomento in un precedente evento su ASPItalia.com:
https://media.aspitalia.com/events/devconf12-yarp.media
Un aspetto importante da tenere sempre presente, in questo contesto, è che il nostro sito web riceverà il traffico solo in maniera indiretta, pertanto se provassimo ad accedere all'HttpRequest corrente, vedremmo informazioni non aggiorante: per esempio, l'indirizzo IP del chiamante che non sarà quello dell'utente effettivo, ma quello del reverse proxy, o l'host della richiesta che (in alcuni casi) potrebbe non corrispondere all'indirizzo vero a proprio invocato dall'utente.
Le implicazioni sono ovvie: pensiamo al caso del logging, o voler restringere gli IP ammessi a una certa regione geografica, o la generazione del ReturnUrl nel caso di redirect a un identity provider in fase di autenticazione.
Come ovviare a questo problema? Ogni reverse proxy inoltrerà questo tipo di informazioni tramite degli header standard:
- X-Forwarded-For, contentente l'IP del chiamante;
- X-Forwarded-Proto, contenente il protocollo originale (HTTP o HTTPS);
- X-Forwarded-Host, che invece contiene l'host originario.
In ASP.NET Core, possiamo attivare una funzionalità chiamata ForwardedHeaders per reimpostare l'HttpRequest tenendo in considerazione anche questi header.
Nel file Program.cs dobbiamo innanzi tutto configurare il servizio specificando di quali headers vogliamo fare il forward:
builder.Services.Configure<ForwardedHeadersOptions>(options => { options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost; });
Successivamente, ci basta aggiungere il corrispondente middleware, di solito nella posizione più esterna nella pipeline di ASP.NET Core:
var app = builder.Build(); app.UseForwardedHeaders(); // altri middleware qui
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Leggere i dati di configurazione di ASP.NET Core da Azure Key Vault
Montare blob e file share su Azure App Service
Catturare la telemetria degli eventi di output cache in ASP.NET Core
Eliminare spazio inutilizzato in un Azure Container Registry
Migrare un repository git da Azure DevOps a GitHub
Gestire il fallimento di uno step in un workflow di GitHub
Creare un router per Single Page Application con l'evento navigate
Sfruttare la local cache del browser tramite gli ETag in ASP.NET Core
Effettuare test di carico con Azure Load Testing
AWS Lambda Cold Start in C# e...
Utilizzare l'attributo HTML inert per disabilitare gli eventi
I più letti di oggi
- Ecco la roadmap di ASP.NET 5: il rilascio definitivo nel corso del primo trimestre 2016
- Sfruttare la local cache del browser tramite gli ETag in #aspnetcore https://aspit.co/cfc di @crad77 #webapi #aspnetmvc #blazor #cache
- Scegliere Kestrel o HTTP.sys come webserver per ASP.NET Core
- Proteggersi dagli attacchi di Open Redirect in ASP.NET Core MVC
- Creare un array al volo
- Creare una libreria riutilizzabile con Angular - parte 2