Considerazioni specifiche sulla sicurezza per le soluzioni Office

Le funzionalità di sicurezza fornite da Microsoft .NET Framework e Microsoft Office consentono di proteggere le soluzioni Office da potenziali rischi di sicurezza. In questo argomento vengono illustrati alcuni di tali rischi e vengono forniti suggerimenti utili su come proteggersi. Inoltre, sono incluse informazioni su come le impostazioni di sicurezza di Microsoft Office possono influire sulle soluzioni Office.

Si applica a: le informazioni fornite in questo argomento sono valide per i progetti a livello di documento e di applicazione per Microsoft Office 2010 e Microsoft Office System 2007. Per ulteriori informazioni, vedere Funzionalità disponibili in base ai tipi di progetto e applicazioni di Office.

Modifica dello scopo del codice attendibile in un nuovo documento dannoso

È possibile che il codice attendibile progettato per un determinato scopo, ad esempio per il download di informazioni personali per un'applicazione di gestione del personale, venga riutilizzato da un utente malintenzionato in un altro documento, come un foglio di lavoro. Il codice non è in grado di riconoscere che il documento originale non è in esecuzione e può introdurre altre minacce, come la diffusione di informazioni personali o l'esecuzione di codice con maggiori privilegi, in caso di apertura da parte di un diverso utente. In alternativa, l'utente malintenzionato può semplicemente modificare i dati nel foglio di lavoro in modo da determinare un comportamento imprevisto in caso di invio a un altro utente. Modificando i valori, le formule o le caratteristiche di presentazione di un foglio di lavoro collegato al codice, un utente malintenzionato può attaccare un altro utente inviando un file modificato. La modifica dei valori nel foglio di lavoro può inoltre consentire agli utenti di accedere a informazioni che non dovrebbero essere in grado di visualizzare.

• Poiché per l'esecuzione è necessario che il percorso dell'assembly e quello del documento dispongano di evidenze sufficienti, questo tipo di attacco non è facilmente realizzabile. I documenti allegati a messaggi di posta elettronica o su server Intranet, ad esempio, non dispongono di autorizzazioni sufficienti per essere eseguiti.

• Per consentire questo attacco, il codice deve essere scritto in modo da supportare decisioni basate su dati potenzialmente non attendibili. Si supponga di creare un foglio di lavoro che presenta una cella nascosta contenente il nome di un server database. L'utente invia il foglio di lavoro a una pagina ASPX, che tenta di connettersi a tale server utilizzando l'autenticazione SQL e una password hardcoded dell'account sa. Un intruso potrebbe sostituire il contenuto della cella nascosta con un altro nome del computer e ottenere la password dell'account sa. Per evitare questo problema non utilizzare le password hardcoded e verificare sempre gli ID del server a fronte di un elenco interno di server noti come affidabili prima di accedere al server.

Consigli

• Convalidare sempre l'input e i dati, indipendentemente dal fatto che provengano dall'utente, dal documento, da un database, da un servizio Web o da qualsiasi altra origine.

• Prestare attenzione nell'esposizione di determinati tipi di funzionalità, come l'acquisizione di dati privilegiati per conto dell'utente e il relativo inserimento in un foglio di lavoro non protetto.

• A seconda del tipo di applicazione, può rivelarsi utile verificare l'esecuzione del documento originale prima dell'esecuzione di codice, ad esempio verificare che venga eseguito da un documento archiviato in un percorso noto e protetto.

• Se nell'applicazione vengono eseguite operazioni privilegiate, può essere opportuno visualizzare un avviso all'apertura del documento. È ad esempio possibile creare una schermata iniziale o una finestra di dialogo di avvio in cui viene segnalato che l'applicazione accederà a informazioni personali, consentendo all'utente di scegliere se continuare o annullare l'operazione. Se un avviso di questo tipo viene visualizzato da un documento apparentemente innocuo, l'utente finale potrà chiudere l'applicazione prima che si verifichino danni.

Codice bloccato dalla protezione del modello a oggetti di Outlook

In Microsoft Office è possibile limitare l'utilizzo da parte del codice di determinate proprietà, metodi e oggetti nel modello a oggetti. Limitando l'accesso a tali oggetti, è possibile impedire a virus e a programmi distruttivi che agiscono tramite la posta elettronica di utilizzare il modello a oggetti a scopo dannoso. Questa funzionalità di sicurezza è nota come protezione del modello a oggetti di Outlook. In caso di tentativo da parte di un componente aggiuntivo di utilizzare una proprietà o un metodo per cui sono stati imposti determinati limiti, mentre la protezione del modello a oggetti è attivata, in Outlook viene visualizzato un avviso di sicurezza che consente all'utente di interrompere l'operazione in corso oppure di permettere l'accesso alla proprietà o al metodo per un periodo di tempo limitato. Se l'utente interrompe l'operazione, i componenti aggiuntivi di Outlook creati tramite Visual Studio Tools per Office genereranno un'eccezione COMException.

La protezione del modello a oggetti ha effetto sui componenti aggiuntivi in diversi modi, in base al fatto che Outlook venga utilizzato o meno con Microsoft Exchange Server:

• Se Outlook non viene utilizzato con Exchange, l'amministratore può abilitare o disabilitare la protezione del modello a oggetti per tutti i componenti aggiuntivi nel computer.

• Se Outlook viene utilizzato con Exchange, l'amministratore può abilitare o disabilitare la protezione del modello a oggetti per tutti i componenti aggiuntivi nel computer oppure specificare che determinati componenti aggiuntivi possono essere eseguiti senza la protezione del modello a oggetti. È inoltre possibile modificare il comportamento della protezione del modello a oggetti per alcune aree del modello a oggetti. Ad esempio, l'amministratore può consentire automaticamente l'invio di messaggi di posta elettronica da parte dei componenti aggiuntivi, a livello di codice, anche se la protezione del modello a oggetti è attivata.

In Outlook 2007 è stato modificato il comportamento della protezione del modello a oggetti allo scopo di migliorare l'interazione con sviluppatori e utenti, garantendo al tempo stesso la sicurezza di Outlook. Per ulteriori informazioni, vedere Code Security Changes in Outlook 2007 (informazioni in lingua inglese).

Riduzione degli avvisi di sicurezza del modello a oggetti

Per evitare la visualizzazione di avvisi di sicurezza quando si utilizzano proprietà e metodi sottoposti a limitazioni, assicurarsi che il componente aggiuntivo ottenga oggetti Outlook dal campo Application della classe ThisAddIn nel progetto. Per ulteriori informazioni su questo campo, vedere Programmazione di componenti aggiuntivi a livello di applicazione.

Per la protezione del modello a oggetti possono essere considerati attendibili solo gli oggetti Outlook ottenuti da questo oggetto. Al contrario, oggetti ottenuti da un nuovo oggetto Microsoft.Office.Interop.Outlook.Application non vengono considerati attendibili e, se la protezione del modello a oggetti è attivata, le proprietà e i metodi sottoposti a limitazioni genereranno avvisi di sicurezza.

Se la protezione del modello a oggetti è attivata, nell'esempio di codice seguente viene visualizzato un avviso di sicurezza. La proprietà To della classe Microsoft.Office.Interop.Outlook.MailItem è limitata dalla protezione del modello a oggetti. L'oggetto Microsoft.Office.Interop.Outlook.MailItem non viene considerato attendibile perché il codice lo ottiene da un oggetto Microsoft.Office.Interop.Outlook.Application creato tramite l'operatore new invece che dal campo Application.

Private Sub UntrustedCode()
    Dim application As New Microsoft.Office.Interop.Outlook.Application
    Dim mailItem1 As Microsoft.Office.Interop.Outlook.MailItem = _
        TryCast(application.CreateItem( _
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem),  _
        Microsoft.Office.Interop.Outlook.MailItem)
    mailItem1.To = "someone@example.com"
    MessageBox.Show(mailItem1.To)
End Sub

private void UntrustedCode()
{
    Microsoft.Office.Interop.Outlook.Application application =
        new Microsoft.Office.Interop.Outlook.Application();
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        application.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

Nell'esempio di codice seguente viene illustrato come utilizzare la proprietà limitata To di un oggetto Microsoft.Office.Interop.Outlook.MailItem considerato attendibile dalla protezione del modello a oggetti. Il codice utilizza il campo Application attendibile per ottenere l'oggetto Microsoft.Office.Interop.Outlook.MailItem.

Private Sub TrustedCode()
    Dim mailItem1 As Microsoft.Office.Interop.Outlook.MailItem = _
        TryCast(Me.Application.CreateItem( _
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem),  _
        Microsoft.Office.Interop.Outlook.MailItem)
    mailItem1.To = "someone@example.com"
    MessageBox.Show(mailItem1.To)
End Sub

private void TrustedCode()
{
    Microsoft.Office.Interop.Outlook.MailItem mailItem1 =
        this.Application.CreateItem(
        Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as
        Microsoft.Office.Interop.Outlook.MailItem;
    mailItem1.To = "someone@example.com";
    MessageBox.Show(mailItem1.To);
}

Indicazione dei componenti aggiuntivi da considerare attendibili se si utilizza Exchange

Quando si utilizza Outlook con Exchange, gli amministratori possono specificare che per determinati componenti aggiuntivi è consentita l'esecuzione senza la protezione del modello a oggetti. I componenti aggiuntivi di Outlook creati tramite Visual Studio Tools per Office non possono essere considerati attendibili singolarmente, ma solo come gruppo.

In Outlook un componente aggiuntivo viene considerato attendibile in base a un codice hash della DLL del punto di ingresso del componente aggiuntivo. Tutti i componenti aggiuntivi di Outlook destinati a Runtime di Visual Studio Tools per Office utilizzano la stessa DLL per il punto di ingresso (VSTOLoader.dll). In questo modo, se un amministratore considera attendibile uno qualsiasi dei componenti aggiuntivi destinati a Runtime di Visual Studio Tools per Office ai fini dell'esecuzione senza la protezione del modello a oggetti, anche tutti gli altri componenti aggiuntivi destinati a Runtime di Visual Studio Tools per Office verranno considerati attendibili. Per ulteriori informazioni sull'attendibilità di componenti aggiuntivi specifici per l'esecuzione senza la protezione del modello a oggetti, vedere Specificare il metodo utilizzato da Outlook per gestire le caratteristiche di prevenzione dei virus.

Effetto non immediato delle modifiche delle autorizzazioni

Se l'amministratore modifica le autorizzazioni per un documento o un assembly, per rendere effettive le modifiche gli utenti devono chiudere e quindi riavviare tutte le applicazioni di Office.

L'applicazione delle nuove autorizzazioni può essere impedita anche da altre applicazioni che ospitano applicazioni Microsoft Office. Quando vengono modificati i criteri di sicurezza, è consigliabile che gli utenti chiudano tutte le applicazioni che utilizzano Office in modo autonomo o tramite hosting.

Le impostazioni del Centro protezione in Microsoft Office System non influiscono sui componenti aggiuntivi né sulle personalizzazioni a livello di documento

Gli utenti possono impedire il caricamento dei componenti aggiuntivi mediante l'impostazione di un'opzione nel Centro protezione. Tuttavia, i componenti aggiuntivi a livello di applicazione e le personalizzazioni a livello di documento creati tramite Visual Studio Tools per Office non sono interessati da tali impostazioni di attendibilità.

Se l'utente impedisce il caricamento dei componenti aggiuntivi mediante il Centro protezione, non verranno caricati i tipi di componenti aggiuntivi seguenti:

• Componenti aggiuntivi COM gestiti e non gestiti.

• Smart tag gestiti e non gestiti.

• Smart document gestiti e non gestiti.

• Componenti aggiuntivi di automazione gestiti e non gestiti.

• Componenti dati in tempo reale gestiti e non gestiti.

Nelle procedure seguenti viene descritto come utilizzare il Centro protezione per limitare il caricamento dei componenti aggiuntivi in Microsoft Office System 2007. Queste procedure non influiscono sulle personalizzazioni o sui componenti aggiuntivi creati utilizzando Visual Studio Tools per Office.

Per disabilitare i componenti aggiuntivi nelle applicazioni di Microsoft Office 2010, in Excel 2007, PowerPoint 2007 o Word 2007

1. Fare clic sulla scheda File (per le applicazioni di Microsoft Office 2010) o sul pulsante Microsoft Office (per le applicazioni di Microsoft Office 2007).

2. Fare clic sul pulsante Opzioni NomeApplicazione.

3. Nel riquadro delle categorie fare clic su Centro protezione.

4. Nel riquadro dei dettagli fare clic su Impostazioni Centro protezione.

5. Nel riquadro delle categorie fare clic su Componenti aggiuntivi.

6. Nel riquadro dei dettagli selezionare Richiedi che i componenti aggiuntivi di applicazioni siano firmati da un editore attendibile o Disabilita tutti i componenti aggiuntivi applicazioni.

Per disabilitare i componenti aggiuntivi in InfoPath 2007, Outlook 2007, Project 2007 o Visio 2007

1. Scegliere Centro protezione dal menu Strumenti.

2. Nel riquadro delle categorie fare clic su Sicurezza macro.

3. Nel riquadro dei dettagli selezionare Disabilita tutte le macro. Non visualizzare alcun avviso o Disattiva le macro senza firma. Visualizza un avviso per le macro firmate.

4. Nel riquadro delle categorie fare clic su Componenti aggiuntivi.

5. Nel riquadro dei dettagli selezionare Applica le impostazioni di sicurezza delle macro ai componenti aggiuntivi installati.

Vedere anche

Altre risorse

Sicurezza delle soluzioni Office