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 dei computer
Archiviazione di Azure
WCF

Implementare Content Security Policy (CSP) e disabilitare il contenuto JavaScript inline

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti An Introduction to Content Security Policy (Introduzione a Content Security Policy) Content Security Policy Reference (Informazioni di riferimento su Content Security Policy), Security features (Funzionalità di sicurezza), Introduction to content security policy (Introduzione a Content Security Policy), (È possibile usare use CSP?)
Passi

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 criteri basati su un elenco elementi consentiti: un sito Web può dichiarare un set di domini attendibili da cui possono essere caricati contenuti attivi, 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 2 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à 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. Infatti il dominio di destinazione non sarà nell'elenco elementi consentiti di CSP.
  • Difesa contro il clickjacking: il clickjacking è 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 clickjacking 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 clickjacking.
  • 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 (e.g., <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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti XSS Protection Filter (Filtro di protezione XSS)
Passi

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 impedisce 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 2 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 Compilare
Tecnologie applicabili Generico
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
Passi 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 a contenuto JavaScript di terze parti solo da origini attendibili

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi Solo le origini attendibili devono fare riferimento al contenuto JavaScript di terze parti. Gli endpoint di riferimento devono sempre essere in SSL.

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

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti OWASP Clickjacking Defense Cheat Sheet (Foglio informativo di OWASP sulla difesa contro il clickjacking), IE Internals - Combating ClickJacking With X-Frame-Options (IEInternals: lotta al clickjacking con X-Frame-Options)
Passi

Il clickjacking, noto anche come "attacco di tipo UI redress", si verifica quando un utente malintenzionato usa più livelli trasparenti o opachi per ingannare un utente che vuole fare clic nella pagina principale e indurlo invece a fare clic su un pulsante o su un collegamento in un'altra pagina.

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 clickjacking, 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 file web.config IIS. Frammento di codice di Web.config che non devono mai essere inseriti in un frame:

    <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 Compilare
Tecnologie applicabili Web Form, MVC 5
Attributi N/D
Riferimenti N/D
Passi

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="http://example.com" />
      </customHeaders>
    </httpProtocol>

Esempio

Se non è disponibile l'accesso a Web.config, CORS può essere configurato aggiungendo il codice CSharp seguente:

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

Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo "Access-Control-Allow-Origin" venga impostato su un set finito e attendibile di origini. Se la configurazione non è corretta (ad esempio, se si imposta il valore come "*"), i siti dannosi potranno attivare richieste multiorigine per l'applicazione Web senza alcuna restrizione, rendendo in questo modo l'applicazione vulnerabile agli attacchi CSRF.

Abilitare l'attributo ValidateRequest nelle pagine ASP.NET

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

La convalida della richiesta, una funzionalità di ASP.NET sin dalla versione 1.1, impedisce al server di accettare contenuti che includono HTML non codificato. Questa funzionalità è progettata per impedire alcuni attacchi script injection in cui il codice script client o HTML può essere inconsapevolmente inviato a un server, archiviato e quindi presentato ad altri utenti. È tuttavia vivamente consigliabile convalidare tutti i dati di input e codificarli con HTML, se 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 della richiesta non è supportata e non fa parte della pipeline MVC 6.

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

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi

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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti IE8 Security Part V: Comprehensive Protection (Sicurezza di IE8 parte V: protezione completa), MIME type (Tipo MIME)
Passi 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 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 Compilare
Tecnologie applicabili Generico
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)
Passi 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 Compilare
Tecnologie applicabili SQL Azure, locale
Attributi N/D, versione SQL: V12
Riferimenti Come configurare un firewall per il database SQL di Azure, Configurare Windows Firewall per l'accesso al motore di database
Passi 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 Compilare
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
Passi

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 venga impostato su un set finito e attendibile di origini. Se la configurazione non è corretta (ad esempio, se si imposta il valore come "*"), i siti dannosi potranno attivare richieste multiorigine per l'API senza alcuna restrizione, rendendo in questo modo 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("http://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 Compilare
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)
Passi

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("http://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("http://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 venga impostato su un set finito e attendibile di origini. Se la configurazione non è corretta (ad esempio, se si imposta il valore come "*"), i siti dannosi potranno attivare richieste multiorigine per l'API senza alcuna restrizione, rendendo in questo modo 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 Generico
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)
Passi 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 Generico
Attributi N/D
Riferimenti N/D
Passi 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 Compilare
Tecnologie applicabili Generico
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)
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 in seguito il sistema operativo conservi un record definitivo di come è stato avviato. Crittografare le partizioni del sistema operativo che usano Bitlocker ed eventuali partizioni aggiuntive anche nel caso in cui archivino dati sensibili.

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

Titolo Dettagli
Componente Dispositivo IoT
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi Non abilitare né disattivare funzionalità o servizi del sistema operativo non necessari per il funzionamento della soluzione. Se, ad esempio, 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 IoT sul campo con Bitlocker

Titolo Dettagli
Componente Gateway IoT sul campo
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 in seguito il sistema operativo conservi un record definitivo di come è stato avviato. Crittografare le partizioni del sistema operativo che usano Bitlocker ed eventuali partizioni aggiuntive anche nel caso in cui archivino 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 Generico
Attributi N/D
Riferimenti N/D
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi Opzione gateway: Hub IoT di Azure
Riferimenti Panoramica della gestione dei dispositivi con l'hub IoT, How to update Device Firmware (Come aggiornare il firmware di un dispositivo)
Passi 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 dei computer
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi Assicurarsi che i dispositivi abbiano controlli di sicurezza degli endpoint, 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 Generico
Attributi N/D
Riferimenti Guida alla sicurezza di Archiviazione di Azure: gestione delle chiavi dell'account di archiviazione
Passi

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 con Azure Active Directory. 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Supporto di CORS per i servizi di archiviazione di Azure
Passi 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 Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passi

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 Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passi 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);