Esempi di impostazioni di sicurezza consigliate per ASP.NET

Esempi di impostazioni di sicurezza consigliate per ASP.NET

In questo articolo vedremo alcune regole utili per la sicurezza di un sito web realizzato in ASP.NET.

Il seguente sono le impostazioni che consiglio di utilizzare:

<system.web>
       (1) <httpRuntime requestValidationMode="4.5" enableVersionHeader="false" targetFramework="4.7.2" maxRequestLength="51200" fcnMode="Single" />
       (2) <pages validateRequest="true" />

</system.web>

...

<system.webServer>

<httpProtocol>
         (3)   <customHeaders>
                <remove name="X-Powered-By" />
                <add name="X-Content-Type-Options" value="nosniff" />
                <remove name="X-XSS-Protection" />
                <add name="X-Xss-Protection" value="1; mode=block" />
                <remove name="Strict-Transport-Security" />
                <add name="Strict-Transport-Security" value="max-age=10886400" />
                <remove name="X-Content-Type-Options" />
                <remove name="X-Frame-Options" />
                <add name="X-Frame-Options" value="sameorigin" />
            </customHeaders>
 </httpProtocol>

...

<rewrite>
       (4)     <outboundRules rewriteBeforeCache="true">
                <rule name="Remove Server header">
                    <match serverVariable="RESPONSE_Server" pattern=".+" />
                    <action type="Rewrite" value="Unknown" />
                </rule>
            </outboundRules>          
        </rewrite>

</system.webServer>

 

Commentiamo il codice (1), in grassetto le opzion relative alla sicurezza indispensabili :

Le opzioni di configurazione specificate includono:

  • requestValidationMode="4.5": questa opzione specifica la versione del sistema di convalida delle richieste utilizzato dall'applicazione. Nel caso specifico, viene utilizzata la versione 4.5.
  • enableVersionHeader="false": questa opzione disabilita l'inclusione dell'intestazione di versione HTTP nelle risposte dell'applicazione.
  • targetFramework="4.7.2": questa opzione specifica la versione del framework di destinazione utilizzata dall'applicazione. Nel caso specifico, viene utilizzata la versione 4.7.2 di .NET Framework.
  • maxRequestLength="51200": questa opzione specifica la dimensione massima delle richieste HTTP che possono essere gestite dall'applicazione, espressa in kilobyte. Nel caso specifico, viene impostato un limite di 51200 KB (ovvero 50 MB).
  • fcnMode="Single": questa opzione specifica la modalità di gestione delle funzioni di callback del framework ASP.NET. Nel caso specifico, viene utilizzata la modalità "Single", che significa che tutte le funzioni di callback vengono gestite dallo stesso thread del pool di thread dell'applicazione.

In generale, queste opzioni di configurazione sono utilizzate per impostare il comportamento dell'applicazione ASP.NET in vari aspetti, come la sicurezza, le prestazioni e la gestione delle risorse. Tuttavia, senza il contesto completo dell'applicazione, non è possibile fornire un commento più dettagliato sull'efficacia di queste impostazioni.

 

Commentiamo il codice (2):

L'attributo "validateRequest" è impostato su "true", il che significa che le richieste HTTP che contengono caratteri potenzialmente pericolosi o codice HTML non valido verranno automaticamente rifiutate dal server. Questo meccanismo di convalida delle richieste viene utilizzato per prevenire attacchi di tipo cross-site scripting (XSS) o injection di codice malevolo.

In generale, è consigliabile mantenere questa impostazione su "true" per garantire la sicurezza dell'applicazione web e dei dati sensibili che essa gestisce. Tuttavia, in alcuni casi particolari potrebbe essere necessario disabilitare la convalida delle richieste, ad esempio se l'applicazione deve gestire dati provenienti da fonti non attendibili o se si ha la necessità di utilizzare codice HTML personalizzato. In tali casi, è importante prestare attenzione alla sicurezza dell'applicazione e adottare misure di prevenzione degli attacchi XSS o di injection di codice.

 

Commentiamo il codice (3):

le impostazioni specificate includono:

  • remove/add name="X-Powered-By": questa opzione rimuove l'header "X-Powered-By", che di solito viene incluso nelle risposte HTTP per indicare la tecnologia utilizzata dal server web.
  • add name="X-Content-Type-Options" value="nosniff": questa opzione include l'header "X-Content-Type-Options" con il valore "nosniff", che indica ai browser di non interpretare i contenuti delle risorse come se fossero di tipo MIME diverso da quello indicato nel Content-Type header.
  • remove/add name="X-XSS-Protection": questa opzione rimuove l'header "X-XSS-Protection", che di solito viene incluso nelle risposte HTTP per abilitare o disabilitare la protezione XSS integrata nei browser. Viene quindi aggiunto l'header "X-Xss-Protection" con il valore "1; mode=block", che abilita la protezione XSS e impedisce ai browser di visualizzare le pagine che contengono codice malevolo.
  • remove/add name="Strict-Transport-Security": questa opzione rimuove l'header "Strict-Transport-Security", che di solito viene incluso nelle risposte HTTP per abilitare il protocollo HTTPS e garantire che le comunicazioni tra il browser e il server siano criptate. Viene quindi aggiunto l'header "Strict-Transport-Security" con il valore "max-age=10886400", che abilita il protocollo HTTPS e specifica la durata massima della cache per il valore.
  • remove/add name="X-Content-Type-Options": questa opzione rimuove l'header "X-Content-Type-Options" (già incluso in precedenza), e ne aggiunge uno nuovo con valore "nosniff".
  • remove/add name="X-Frame-Options": questa opzione rimuove l'header "X-Frame-Options", che di solito viene incluso nelle risposte HTTP per impedire l'inclusione di pagine in un frame di un'altra pagina web. Viene quindi aggiunto l'header "X-Frame-Options" con il valore "sameorigin", che consente l'inclusione di pagine solo in frame dello stesso dominio.

In generale, queste impostazioni di configurazione sono utilizzate per migliorare la sicurezza dell'applicazione web, impedendo attacchi di tipo XSS, clickjacking e altre minacce alla sicurezza. Tuttavia, è importante prestare attenzione alla compatibilità con i browser e adottare misure di sicurezza aggiuntive per prevenire attacchi noti o emergenti.

 

Commentiamo il codice (4):

Il codice fornito rappresenta un'opzione di configurazione per la riscrittura degli header di risposta HTTP in uscita utilizzando le regole di riscrittura degli URL (URL Rewrite) in IIS (Internet Information Services) per ASP.NET.

In particolare, il codice specifica una regola di riscrittura delle risposte in uscita che rimuove l'header "Server" e lo sostituisce con il valore "Unknown". L'header "Server" viene normalmente incluso nelle risposte HTTP per indicare il tipo di server web utilizzato per gestire la richiesta, ma può rappresentare una potenziale minaccia per la sicurezza se diventa noto a potenziali attaccanti, che potrebbero utilizzarlo per cercare di sfruttare eventuali vulnerabilità note del server.

La regola di riscrittura specifica che si applica solo alle risposte in uscita e che deve essere eseguita prima della memorizzazione nella cache. Inoltre, la regola utilizza la corrispondenza (match) sul serverVariable RESPONSE_Server, che indica l'header Server nella risposta HTTP, e specifica un valore di pattern ".+" per indicare che qualsiasi valore dell'header deve essere corrisposto.

Infine, l'azione (action) specificata è "Rewrite", che indica che il valore dell'header deve essere riscritto con il valore "Unknown". In questo modo, l'header "Server" viene rimosso e sostituito con un valore meno esplicito e potenzialmente meno rivelatore.

Questa configurazione può migliorare la sicurezza dell'applicazione web, impedendo ai potenziali attaccanti di raccogliere informazioni sul tipo di server web utilizzato per gestire le richieste, riducendo così il rischio di attacchi mirati contro eventuali vulnerabilità note del server. Tuttavia, è importante notare che la rimozione dell'header "Server" può anche interferire con alcuni meccanismi di reporting o di diagnostica del server, e può non essere compatibile con tutte le applicazioni web.

 

 

Buon lavoro!

We use cookies

Utilizziamo i cookie sul nostro sito Web. Alcuni di essi sono essenziali per il funzionamento del sito, mentre altri ci aiutano a migliorare questo sito e l'esperienza dell'utente (cookie di tracciamento). Puoi decidere tu stesso se consentire o meno i cookie. Ti preghiamo di notare che se li rifiuti, potresti non essere in grado di utilizzare tutte le funzionalità del sito.