Infrastruttura di sicurezza: gestione della configurazione - Procedure di mitigazione

Prodotto o servizio Articolo
Applicazione Web
Database
API Web
Dispositivo IoT
Gateway IoT sul campo
Gateway IoT cloud
Limite di Trust del computer
Archiviazione di Azure
WCF

Implementare i criteri di sicurezza del contenuto (CSP) e disabilitare JavaScript inline

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Introduzione ai criteri di sicurezza dei contenuti, Informazioni di riferimento sui criteri di sicurezza dei contenuti, Introduzione ai criteri di sicurezza dei contenuti, È possibile usare CSP?
Passaggi

Content Security Policy (CSP) è un meccanismo di sicurezza avanzato, uno standard W3C, che consente ai proprietari di applicazioni Web di avere il controllo del contenuto incorporato nel sito. CSP viene aggiunto come intestazione della risposta HTTP nel server Web e viene applicato sul lato client dai browser. Si tratta di un criterio basato su elenco consentito: un sito Web può dichiarare un set di domini attendibili da cui è possibile caricare contenuto attivo, ad esempio JavaScript.

CSP offre i seguenti vantaggi per la sicurezza:

  • Protezione da XSS: se una pagina è vulnerabile a XSS, un utente malintenzionato può sfruttarlo in due modi:
    • Inserimento di <script>malicious code</script>. Questo exploit non funzionerà a causa della restrizione di base 1 di CSP
    • Inserimento di <script src="http://attacker.com/maliciousCode.js"/>. Questo exploit non funzionerà perché il dominio controllato dall'utente malintenzionato non sarà incluso nell'elenco di domini consentiti di CSP
  • Controllo sull'esfiltrazione dei dati: se un contenuto dannoso in una pagina Web prova a connettersi a un sito Web esterno e a sottrarre dati, la connessione verrà interrotta da CSP. Ciò è dovuto al fatto che il dominio di destinazione non sarà incluso nell'elenco consentito del provider di servizi di configurazione
  • Difesa contro il click-jacking: il click-jacking è una tecnica di attacco con la quale un antagonista può inserire in un frame un sito Web originale e forzare gli utenti a fare clic sugli elementi dell'interfaccia utente. Attualmente la difesa contro il click-jacking si basa sulla configurazione dell'intestazione della risposta X-Frame-Options. Non tutti i browser supportano questa intestazione e, con il passare del tempo, CSP diventerà uno dei modi standard per difendersi dal click-jacking
  • Creazione di report sugli attacchi in tempo reale: se si verifica un attacco di tipo injection in un sito Web abilitato per CSP, i browser attiveranno automaticamente una notifica per un endpoint configurato sul server Web. In questo modo, CSP funge da sistema di avviso in tempo reale.

Esempio

Criteri di esempio:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com 

Questi criteri consentono il caricamento degli script solo dal server dell'applicazione Web e dal server Google Analytics. Gli script caricati da altri siti verranno rifiutati. Quando CSP viene abilitato in un sito Web, le funzionalità seguenti vengono automaticamente disabilitate per mitigare gli attacchi XSS.

Esempio

Gli script inline non verranno eseguiti. Di seguito sono riportati esempi di script inline.

<script> some JavaScript code </script>
Event handling attributes of HTML tags (for example, <button onclick="function(){}">
javascript:alert(1);

Esempio

Le stringhe non verranno valutate come codice.

Example: var str="alert(1)"; eval(str);

Abilitare il filtro XSS del browser

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti XSS Protection Filter (Filtro di protezione XSS)
Passaggi

La configurazione dell'intestazione della risposta X-XSS-Protection controlla il filtro di cross-site scripting del browser. Questa intestazione della risposta può avere i valori seguenti:

  • 0: Disabilita il filtro.
  • 1: Filter enabled Se viene rilevato un attacco di tipo cross-site scripting, per arrestare l'attacco, il browser purifica la pagina.
  • 1: mode=block : Filter enabled. Invece di purificare la pagina, quando viene rilevato un attacco XSS, il browser impedirà il rendering della pagina
  • 1: report=http://[YOURDOMAIN]/your_report_URI : Filter enabled. Il browser purificherà la pagina e segnalerà la violazione.

Si tratta di una funzione di Chromium che utilizza i report sulle violazioni CSP per inviare i dettagli all'URI scelto. Le ultime due opzioni sono considerate valori sicuri.

Le applicazioni ASP.NET devono disabilitare la traccia e il debug prima della distribuzione

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Panoramica del debug di ASP.NET, Panoramica dell'analisi di ASP.NET, Procedura: Abilitare l'analisi per un'applicazione ASP.NET, Procedura: Abilitare il debug per applicazioni ASP.NET
Passaggi Quando l'analisi viene abilitata per la pagina, ogni browser che la richiede ottiene anche le informazioni di analisi contenenti i dati sul flusso di lavoro e sullo stato del server interno. Tali informazioni possono essere relative alla sicurezza. Quando il debug viene abilitato per la pagina, gli errori che si verificano sul server restituiscono dati di analisi dello stack completa presentati al browser. Tali dati possono esporre informazioni relative alla sicurezza sul flusso di lavoro del server.

Accedere solo a JavaScript di terze parti da origini attendibili

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi È consigliabile fare riferimento a JavaScript di terze parti solo da origini attendibili. Gli endpoint di riferimento devono sempre essere in TLS.

Assicurarsi che le pagine ASP.NET autenticate incorporino difese contro attacchi di tipo UI redress o click-jacking

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti OWASP click-jacking Defense Cheat Sheet (Foglio informativo di OWASP sulla difesa contro il click-jacking), IE Internals - Combating click-jacking With X-Frame-Options (IEInternals: lotta al click-jacking con X-Frame-Options)
Passaggi

Il click-jacking, noto anche come "attacco di correzione dell'interfaccia utente", è quando un utente malintenzionato usa più livelli trasparenti o opachi per ingannare un utente a fare clic su un pulsante o un collegamento in un'altra pagina quando intendevano fare clic sulla pagina di primo livello.

Questa sovrapposizione si ottiene creando una pagina dannosa con un iframe, che carica la pagina della vittima. L'utente malintenzionato assume quindi il controllo dei clic destinati alla pagina e li instrada a un'altra pagina, quasi certamente di proprietà di un'altra applicazione o dominio oppure di entrambi. Per impedire gli attacchi di tipo click-jacking, impostare le intestazioni della risposta HTTP X-Frame-Options appropriate che indicano al browser di non consentire l'inserimento in frame da altri domini

Esempio

L'intestazione X-FRAME-OPTIONS può essere impostata tramite IIS web.config. Frammento di codice Web.config per i siti che non devono mai essere framed:

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="DENY"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

Esempio

Codice di Web.config per siti che devono essere inseriti in un frame solo dalle pagine nello stesso dominio:

    <system.webServer>
        <httpProtocol>
            <customHeader>
                <add name="X-FRAME-OPTIONS" value="SAMEORIGIN"/>
            </customHeaders>
        </httpProtocol>
    </system.webServer>

Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato nelle applicazioni Web ASP.NET

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Web Form, MVC 5
Attributi N/D
Riferimenti N/D
Passaggi

La sicurezza del browser impedisce a una pagina Web di creare richieste AJAX per un altro dominio. Questa restrizione è nota come criteri di corrispondenza dell'origine e impedisce a un sito dannoso di leggere dati sensibili da un altro sito. In alcuni casi può tuttavia essere necessario esporre in modo sicuro le API che gli altri siti possono utilizzare. Cross Origin Resource Sharing (CORS) è uno standard W3C che consente a un server di ridurre i criteri di corrispondenza dell'origine. Con CORS un server può consentire in modo esplicito alcune richieste multiorigine e rifiutarne altre.

CORS è più sicuro e flessibile delle tecniche precedenti, ad esempio JSONP. In sostanza, abilitando CORS sarà possibile aggiungere alcune intestazioni della risposta HTTP (Access-Control-*) all'applicazione Web in due modi.

Esempio

Se è disponibile l'accesso a Web.config, CORS può essere aggiunto tramite il codice seguente:

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name="Access-Control-Allow-Origin" value="https://example.com" />
      </customHeaders>
    </httpProtocol>

Esempio

Se l'accesso a web.config non è disponibile, è possibile configurare CORS aggiungendo il codice C# seguente:

HttpContext.Response.AppendHeader("Access-Control-Allow-Origin", "https://example.com")

Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo "Access-Control-Allow-Origin" sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consente ai siti dannosi di attivare richieste tra le origini all'applicazione >Web senza restrizioni, rendendo l'applicazione vulnerabile agli attacchi CSRF.

Abilitare l'attributo ValidateRequest nelle pagine ASP.NET

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Web Form, MVC 5
Attributi N/D
Riferimenti Request Validation - Preventing Script Attacks (Convalida della richiesta: prevenzione degli attacchi basati su script)
Passaggi

Convalida della richiesta, una caratteristica di ASP.NET dalla versione 1.1, impedisce al server di accettare contenuti contenenti HTML non codificato. Questa funzionalità è progettata per aiutare ad evitare alcuni attacchi intrusivi di script in base ai quali il codice di script client o HTML può essere inconsapevolmente inviato a un server, archiviato e quindi presentato ad altri utenti. Raccomandiamo ancora vivamente di convalidare tutti i dati di input e di codificarli HTML quando appropriato.

La convalida della richiesta viene eseguita confrontando tutti i dati di input con un elenco di valori potenzialmente pericolosi. Se viene rilevata una corrispondenza, ASP.NET genera HttpRequestValidationException. Per impostazione predefinita, la funzionalità di convalida della richiesta è abilitata.

Esempio

Questa funzionalità può essere tuttavia disabilitata a livello di pagina:

<%@ Page validateRequest="false" %> 

o a livello di applicazione.

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

Si noti che la funzionalità di convalida delle richieste non è supportata e non fa parte della pipeline MVC6.

Usare le versioni più recenti ospitate in locale delle librerie JavaScript

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi

Gli sviluppatori che usano librerie JavaScript standard, ad esempio JQuery, devono usare versioni approvate delle comuni librerie JavaScript che non contengono difetti di sicurezza noti. È consigliabile usare la versione più recente delle librerie, perché contiene aggiornamenti della sicurezza per le vulnerabilità note delle versioni precedenti.

Se la versione più recente non può essere usata per motivi di compatibilità, è consigliabile usare la versione inferiore a quella minima.

Versioni minime accettabili:

  • JQuery
    • JQuery 1.7.1
    • JQueryUI 1.10.0
    • JQuery Validate 1.9
    • JQuery Mobile 1.0.1
    • JQuery Cycle 2.99
    • JQuery DataTables 1.9.0
  • Ajax Control Toolkit
    • Ajax Control Toolkit 40412
  • Web Form ASP.NET e Ajax
    • Web Form ASP.NET e Ajax 4
    • ASP.NET Ajax 3.5
  • ASP.NET MVC
    • ASP.NET MVC 3.0

Non caricare mai librerie JavaScript da siti esterni, ad esempio reti CDN pubbliche.

Disabilitare l'analisi MIME automatica

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti IE8 Security Part V: Comprehensive Protection (Sicurezza di IE8 parte V: protezione completa), MIME type (Tipo MIME)
Passaggi L'intestazione X-Content-Type-Options è un'intestazione HTTP che consente agli sviluppatori di specificare che il contenuto non deve essere sottoposto ad analisi MIME. Questa intestazione è progettata per mitigare gli attacchi basati sull'analisi MIME. Per ogni pagina che potrebbe includere contenuti controllabili dall'utente, è necessario usare l'intestazione HTTP X-Content-Type-Options:nosniff. Per abilitare l'intestazione necessaria a livello globale per tutte le pagine nell'applicazione, eseguire una di queste operazioni.

Esempio

Aggiungere l'intestazione nel file web.config se l'applicazione è ospitata da Internet Information Services (IIS) 7 o versione successiva.

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
</customHeaders>
</httpProtocol>
</system.webServer>

Esempio

Aggiungere l'intestazione tramite il Application_BeginRequest globale

void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers["X-Content-Type-Options"] = "nosniff";
}

Esempio

Implementare un modulo HTTP personalizzato

public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
  return;
if (application.Response.Headers["X-Content-Type-Options "] != null)
  return;
application.Response.Headers.Add("X-Content-Type-Options ", "nosniff");
}
}

Esempio

È possibile abilitare l'intestazione necessaria solo per pagine specifiche aggiungendola a singole risposte:

this.Response.Headers["X-Content-Type-Options"] = "nosniff";

Rimuovere le intestazioni del server standard nei siti Web di Microsoft Azure per evitare la creazione di impronte digitali

Titolo Dettagli
Componente Applicazione Web
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi Tipo di ambiente: Azure
Riferimenti Removing standard server headers on Windows Azure Web Sites (Rimozione di intestazioni del server standard nei siti Web di Microsoft Azure)
Passaggi Intestazioni come Server, X-Powered-By e X-AspNet-Version rivelano informazioni sul server e sulle tecnologie sottostanti. È consigliabile eliminare queste intestazioni evitando così di creare impronte digitali dell'applicazione

Configurare Windows Firewall per l'accesso al motore di database

Titolo Dettagli
Componente Database
Fase SDL Compilazione
Tecnologie applicabili SQL Azure, locale
Attributi N/D, versione SQL: V12
Riferimenti Come configurare un firewall database SQL di Azure, Configurare Windows Firewall per l'accesso motore di database
Passaggi I sistemi firewall consentono di impedire l'accesso non autorizzato alle risorse del computer. Per accedere a un'istanza del motore di database di SQL Server tramite un firewall, è necessario configurare il firewall sul computer che esegue SQL Server per consentire l'accesso.

Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato nell'API Web ASP.NET

Titolo Dettagli
Componente API Web
Fase SDL Compilazione
Tecnologie applicabili MVC 5
Attributi N/D
Riferimenti Enabling Cross-Origin Requests in ASP.NET Web API 2 (Abilitazione di richieste multiorigine nell'API Web ASP.NET 2), API Web ASP.NET: supporto di CORS nell'API Web ASP.NET 2
Passaggi

La sicurezza del browser impedisce a una pagina Web di creare richieste AJAX per un altro dominio. Questa restrizione è nota come criteri di corrispondenza dell'origine e impedisce a un sito dannoso di leggere dati sensibili da un altro sito. In alcuni casi può tuttavia essere necessario esporre in modo sicuro le API che gli altri siti possono utilizzare. Cross Origin Resource Sharing (CORS) è uno standard W3C che consente a un server di ridurre i criteri di corrispondenza dell'origine.

Con CORS un server può consentire in modo esplicito alcune richieste multiorigine e rifiutarne altre. CORS è più sicuro e flessibile delle tecniche precedenti, ad esempio JSONP.

Esempio

In App_Start/WebApiConfig.cs aggiungere il codice seguente al metodo WebApiConfig.Register.

using System.Web.Http;
namespace WebService
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // New code
            config.EnableCors();

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }
    }
}

Esempio

L'attributo EnableCors può essere applicato ai metodi di azione in un controller, come segue:

public class ResourcesController : ApiController
{
  [EnableCors("http://localhost:55912", // Origin
              null,                     // Request headers
              "GET",                    // HTTP methods
              "bar",                    // Response headers
              SupportsCredentials=true  // Allow credentials
  )]
  public HttpResponseMessage Get(int id)
  {
    var resp = Request.CreateResponse(HttpStatusCode.NoContent);
    resp.Headers.Add("bar", "a bar value");
    return resp;
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "PUT",                          // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  [EnableCors("http://localhost:55912",       // Origin
              "Accept, Origin, Content-Type", // Request headers
              "POST",                         // HTTP methods
              PreflightMaxAge=600             // Preflight cache duration
  )]
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
}

Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo EnableCors sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consentirà ai siti dannosi di attivare richieste tra le origini all'API senza restrizioni, >rendendo quindi l'API vulnerabile agli attacchi CSRF. EnableCors può essere decorato a livello di controller.

Esempio

Per disabilitare CORS in un determinato metodo di una classe, l'attributo DisableCors può essere usato come illustrato sotto:

[EnableCors("https://example.com", "Accept, Origin, Content-Type", "POST")]
public class ResourcesController : ApiController
{
  public HttpResponseMessage Put(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  public HttpResponseMessage Post(Resource data)
  {
    return Request.CreateResponse(HttpStatusCode.OK, data);
  }
  // CORS not allowed because of the [DisableCors] attribute
  [DisableCors]
  public HttpResponseMessage Delete(int id)
  {
    return Request.CreateResponse(HttpStatusCode.NoContent);
  }
}
Titolo Dettagli
Componente API Web
Fase SDL Compilazione
Tecnologie applicabili MVC 6
Attributi N/D
Riferimenti Enabling Cross-Origin Requests (CORS) in ASP.NET Core 1.0 (Abilitazione di richieste multiorigine (CORS) in ASP.NET Core 1.0)
Passaggi

In ASP.NET Core 1.0 CORS può essere abilitato usando il middleware o MVC. Quando si usa MVC per abilitare CORS, vengono usati gli stessi servizi CORS, ma non il middleware CORS.

Approccio 1 Abilitazione di CORS con il middleware: per abilitare CORS per l'intera applicazione, aggiungere il middleware CORS alla pipeline di richieste usando il metodo di estensione UseCors. Si possono specificare criteri multiorigine quando si aggiunge il middleware CORS usando la classe CorsPolicyBuilder. A questo scopo è possibile procedere in due modi:

Esempio

Il primo consiste nel chiamare UseCors con un operatore lambda. L'operatore lambda accetta un oggetto CorsPolicyBuilder:

public void Configure(IApplicationBuilder app)
{
    app.UseCors(builder =>
        builder.WithOrigins("https://example.com")
        .WithMethods("GET", "POST", "HEAD")
        .WithHeaders("accept", "content-type", "origin", "x-custom-header"));
}

Esempio

Il secondo consiste nel definire uno più criteri CORS denominati e quindi nel selezionare i criteri per nome in fase di esecuzione.

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("AllowSpecificOrigin",
            builder => builder.WithOrigins("https://example.com"));
    });
}
public void Configure(IApplicationBuilder app)
{
    app.UseCors("AllowSpecificOrigin");
    app.Run(async (context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
}

Approccio 2 Abilitazione di CORS in MVC: in alternativa gli sviluppatori possono usare MVC per applicare CORS specifici per azione, per controller o a livello globale per tutti i controller.

Esempio

Per azione: per specificare un criterio CORS per un'azione specifica, aggiungere l'attributo [EnableCors] all'azione. Specificare il nome del criterio.

public class HomeController : Controller
{
    [EnableCors("AllowSpecificOrigin")] 
    public IActionResult Index()
    {
        return View();
    }

Esempio

Per controller:

[EnableCors("AllowSpecificOrigin")]
public class HomeController : Controller
{

Esempio

A livello globale:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.Configure<MvcOptions>(options =>
    {
        options.Filters.Add(new CorsAuthorizationFilterFactory("AllowSpecificOrigin"));
    });
}

Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo EnableCors sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consentirà ai siti dannosi di attivare richieste tra le origini all'API senza restrizioni, >rendendo quindi l'API vulnerabile agli attacchi CSRF.

Esempio

Per disabilitare CORS per un controller o un'azione, usare l'attributo [DisableCors].

[DisableCors]
    public IActionResult About()
    {
        return View();
    }

Crittografare le sezioni dei file di configurazione dell'API Web contenenti dati sensibili

Titolo Dettagli
Componente API Web
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI (Procedura: Crittografare le sezioni di configurazione in ASP.NET 2.0 usando DPAPI), Specifica di un provider di configurazione protetta, Using Azure Key Vault to protect application secrets (Uso di Azure Key Vault per proteggere i segreti dell'applicazione)
Passaggi I file di configurazione, ad esempio Web.config e appsettings.json, vengono spesso usati per memorizzare informazioni sensibili, inclusi nomi utente, password, stringhe di connessione del database e chiavi di crittografia. Se non si proteggono queste informazioni, l'applicazione è vulnerabile agli utenti malintenzionati che ottengono informazioni sensibili, ad esempio nomi account utente e password, nomi dei database e nomi dei server. In base al tipo di distribuzione (Azure/locale), crittografare le sezioni sensibili dei file config usando DPAPI o servizi come Azure Key Vault.

Assicurarsi che tutte le interfacce amministrative siano protette con credenziali sicure

Titolo Dettagli
Componente Dispositivo IoT
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Tutte le interfacce amministrative esposte dal dispositivo o dal gateway sul campo devono essere protette con credenziali sicure. Anche tutte le altre interfacce esposte, ad esempio WiFi, SSH, condivisioni file e FTP, devono essere protette con credenziali sicure. Non si devono usare le password vulnerabili predefinite.

Assicurarsi che un codice sconosciuto non possa essere eseguito sui dispositivi

Titolo Dettagli
Componente Dispositivo IoT
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Enabling Secure Boot and BitLocker Device Encryption on Windows 10 IoT Core (Abilitazione dell'avvio protetto e della crittografia dispositivo BitLocker in Windows 10 IoT Core)
Passaggi L'avvio protetto UEFI limita il sistema consentendo solo l'esecuzione di file binari firmati da un'autorità specificata. Questa funzionalità impedisce l'esecuzione di codice sconosciuto sulla piattaforma e il potenziale indebolimento del comportamento di sicurezza. Abilitare l'avvio protetto UEFI e limitare l'elenco di autorità di certificazione considerate attendibili per la firma del codice. Firmare tutto il codice distribuito nel dispositivo usando una delle autorità attendibili.

Crittografare il sistema operativo e altre partizioni del dispositivo IoT con BitLocker

Titolo Dettagli
Componente Dispositivo IoT
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Windows 10 IoT Core implementa una versione lightweight della crittografia dispositivo BitLocker, che dipende fortemente dalla presenza di un modulo TPM nella piattaforma, incluso il protocollo preOS necessario in UEFI che esegue le misurazioni necessarie. Queste misurazioni preOS assicurano che il sistema operativo in un secondo momento abbia un record definitivo della modalità di avvio del sistema operativo. Crittografare le partizioni del sistema operativo usando BitLocker e qualsiasi altra partizione anche nel caso in cui archiviino dati sensibili.

Assicurarsi che sui dispositivi siano abilitati solo servizi/funzionalità minime

Titolo Dettagli
Componente Dispositivo IoT
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Non abilitare né disattivare funzionalità o servizi del sistema operativo non necessari per il funzionamento della soluzione. Ad esempio, se il dispositivo non richiede la distribuzione di un'interfaccia utente, installare Windows IoT Core in modalità headless.

Crittografare il sistema operativo e altre partizioni del gateway sul campo IoT con BitLocker

Titolo Dettagli
Componente Gateway IoT sul campo
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Windows 10 IoT Core implementa una versione lightweight della crittografia dispositivo BitLocker, che dipende fortemente dalla presenza di un modulo TPM nella piattaforma, incluso il protocollo preOS necessario in UEFI che esegue le misurazioni necessarie. Queste misurazioni preOS assicurano che il sistema operativo in un secondo momento abbia un record definitivo della modalità di avvio del sistema operativo. Crittografare le partizioni del sistema operativo usando BitLocker e qualsiasi altra partizione anche nel caso in cui archiviino dati sensibili.

Assicurarsi che le credenziali di accesso predefinite del gateway sul campo vengano modificate durante l'installazione

Titolo Dettagli
Componente Gateway IoT sul campo
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Assicurarsi che le credenziali di accesso predefinite del gateway sul campo vengano modificate durante l'installazione

Assicurarsi che il gateway nel cloud implementi un processo per mantenere aggiornato il firmware dei dispositivi connessi

Titolo Dettagli
Componente Gateway IoT cloud
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi Opzione gateway: Hub IoT di Azure
Riferimenti hub IoT Gestione dispositivi Panoramica, Aggiornamento dei dispositivi per hub IoT di Azure esercitazione con l'immagine di riferimento Raspberry Pi 3 B+.
Passaggi LWM2M è un protocollo di Open Mobile Alliance per la gestione dei dispositivi IoT. Gestione dei dispositivi dell'hub IoT di Azure consente di interagire con dispositivi fisici tramite processi del dispositivo. Assicurarsi che il gateway nel cloud implementi a processo per mantenere regolarmente aggiornati il dispositivo e gli altri dati di configurazione usando Gestione dei dispositivi dell'hub IoT di Azure.

Assicurarsi che i dispositivi abbiano i controlli di sicurezza degli endpoint configurati in base ai criteri organizzativi

Titolo Dettagli
Componente Limite di Trust del computer
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Assicurarsi che i dispositivi dispongano di controlli di sicurezza end-point, ad esempio BitLocker per la crittografia a livello di disco, antivirus con firme aggiornate, firewall basato su host, aggiornamenti del sistema operativo, criteri di gruppo e così via, configurati in base ai criteri di sicurezza dell'organizzazione.

Assicurare una gestione sicura delle chiavi di accesso alle risorse di archiviazione di Azure

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Guida alla sicurezza di Archiviazione di Azure: gestione delle chiavi dell'account di archiviazione
Passaggi

Archiviazione chiavi: è consigliabile archiviare le chiavi di accesso alle risorse di archiviazione di Azure in Azure Key Vault come segreto e fare in modo che le applicazioni recuperino la chiave dall'insieme di credenziali delle chiavi. È consigliabile per i motivi seguenti:

  • L'applicazione non avrà mai una chiave di archiviazione hardcoded in un file di configurazione, eliminando la possibilità che qualcuno possa ottenere l'accesso alle chiavi senza un'autorizzazione specifica.
  • L'accesso alle chiavi può essere controllato tramite Microsoft Entra ID. Il proprietario dell'account può quindi concedere l'accesso solo alle applicazioni che devono recuperare le chiavi da Azure Key Vault. Le altre applicazioni non riusciranno ad accedere alle chiavi se non vengono loro concesse autorizzazioni specifiche.
  • Rigenerazione delle chiavi: è consigliabile avere un processo attivo per rigenerare le chiavi di accesso alle risorse di archiviazione di Azure per motivi di sicurezza. I dettagli su perché e come pianificare la rigenerazione delle chiavi sono documentati nell'articolo di riferimento Guida alla sicurezza di Archiviazione di Azure.

Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato in Archiviazione di Azure

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Compilazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Supporto di CORS per i servizi di archiviazione di Azure
Passaggi Archiviazione di Azure consente di abilitare CORS (Condivisione risorse tra le origini). Per ogni account di archiviazione è possibile specificare i domini che possono accedere alle risorse in tale account di archiviazione. Per impostazione predefinita, CORS è disabilitato in tutti i servizi. È possibile abilitare CORS con l'API REST o la libreria client di archiviazione per chiamare uno dei metodi che impostano i criteri del servizio.

Abilitare la funzionalità di limitazione dei servizi di WCF

Titolo Dettagli
Componente WCF
Fase SDL Compilazione
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passaggi

Se non si imposta un limite all'uso delle risorse di sistema, potrebbe verificarsi un problema di esaurimento risorse e infine di Denial of Service.

  • SPIEGAZIONE: Windows Communication Foundation (WCF) offre la possibilità di limitare le richieste di servizio. Se si consentono troppe richieste client, un sistema può riempirsi ed esaurire le risorse. Al contrario, consentire solo un numero ridotto di richieste per un servizio può impedire ai legittimi utenti di usare il servizio. Ogni singolo servizio deve essere ottimizzato e configurato per consentire la quantità appropriata di risorse.
  • SUGGERIMENTI Abilitare la funzionalità di limitazione del servizio di WCF e impostare limiti appropriati per l'applicazione.

Esempio

Di seguito è riportato un esempio di configurazione con la funzionalità di limitazione abilitata:

<system.serviceModel> 
  <behaviors>
    <serviceBehaviors>
    <behavior name="Throttled">
    <serviceThrottling maxConcurrentCalls="[YOUR SERVICE VALUE]" maxConcurrentSessions="[YOUR SERVICE VALUE]" maxConcurrentInstances="[YOUR SERVICE VALUE]" /> 
  ...
</system.serviceModel> 

Diffusione di informazioni di WCF tramite i metadati

Titolo Dettagli
Componente WCF
Fase SDL Compilazione
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passaggi I metadati possono consentire agli utenti malintenzionati di ottenere informazioni sul sistema e di pianificare un attacco. I servizi WCF possono essere configurati per esporre i metadati. I metadati offrono informazioni dettagliate sui servizi e non devono essere trasmessi negli ambienti di produzione. Le proprietà HttpGetEnabled / HttpsGetEnabled della classe ServiceMetaData definiscono se un servizio esporrà i metadati.

Esempio

Il codice seguente indica a WCF di trasmettere i metadati di un servizio.

ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb); 

Non trasmettere i metadati del servizio in un ambiente di produzione. Impostare le proprietà HttpGetEnabled/HttpsGetEnabled della classe ServiceMetaData su false.

Esempio

Il codice seguente indica a WCF di non trasmettere i metadati di un servizio.

ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
smb.HttpGetEnabled = false; 
smb.HttpGetUrl = new Uri(EndPointAddress); 
Host.Description.Behaviors.Add(smb);