Consideraciones de seguridad específicas para soluciones de Office

Las características de seguridad que incluyen Microsoft .NET Framework y Microsoft Office pueden ayudarle a proteger las soluciones de Office contra posibles amenazas de seguridad.En este tema se explican algunas de esas amenazas y se proporcionan algunas recomendaciones de protección.También se incluye información sobre cómo afecta la configuración de seguridad de Microsoft Office a las soluciones de Office.

Se aplica a: La información de este tema se aplica a los proyectos de nivel de documento y los proyectos de nivel de aplicación para Office 2013 y Office 2010. Vea Características disponibles por aplicación y tipo de proyecto de Office.

El código de confianza se manipula en un documento nuevo malintencionado

Un atacante podría tomar código de confianza concebido para un propósito determinado, por ejemplo, descargar información personal para una aplicación de uso, y reutilizarlo en otro documento, como una hoja de cálculo.El código no sabe que el documento original no se está ejecutando, y puede abrir otras amenazas, como información personal que revela o código la ejecución con más privilegios, cuando lo abre otro usuario.Otra posibilidad consiste en que el atacante modifique simplemente los datos de la hoja de cálculo de modo que, cuando se envíe a la víctima, se comporte de forma inesperada.Mediante la introducción de cambios en los valores, las fórmulas o las características de presentación de una hoja de cálculo vinculada a código, un usuario malintencionado puede atacar a otro usuario enviándole un archivo modificado.También puede darse la posibilidad de que los usuarios obtengan acceso a información que, supuestamente, no deberían conocer mediante la modificación de valores en la hoja de cálculo.

Dado que tanto la ubicación del ensamblado como la del documento deben tener evidencia suficiente para la ejecución, no es fácil llevar a cabo este ataque.Por ejemplo, los documentos de datos adjuntos en mensajes de correo electrónico o en servidores de intranet que no son de confianza no disponen de permisos suficientes para la ejecución.

Para que este ataque sea posible, el propio código debe escribirse de modo que tome decisiones basadas en datos potencialmente no fidedignos.Un ejemplo es la creación de una hoja de cálculo que tiene una celda oculta que contiene el nombre de un servidor de bases de datos.El usuario envía la hoja de cálculo a una página ASPX, que intenta conectarse a ese servidor utilizando autenticación SQL y una contraseña de acceso al servidor incluida en el código.Un atacante podría reemplazar el contenido de la celda oculta con un nombre de equipo diferente y obtener la contraseña de acceso al servidor.Para evitar este problema, nunca incluya contraseñas en el código y siempre compruebe si el identificador del servidor aparece en una lista de servidores que se han confirmado como buenos antes de tener acceso al servidor.

Recomendaciones

• Valide siempre la entrada y los datos, si procede del usuario, documentos, de una base de datos, un servicio web, o de cualquier otro origen.

• Tenga cuidado con la exposición de tipos concretos de funcionalidad, como por ejemplo, la obtención de datos con privilegios en nombre del usuario y su colocación en una hoja de cálculo no protegida.

• Dependiendo del tipo de aplicación, puede ser conveniente comprobar si el documento original se ejecuta antes de ejecutar cualquier código.Por ejemplo, compruebe que está ejecutando desde un documento almacenado en una ubicación conocida, segura.

• Puede ser recomendable que se muestre una advertencia cuando el documento se abre si la aplicación realiza acciones con privilegios.Por ejemplo, se puede crear una pantalla de presentación o un cuadro de diálogo de inicio donde se especifique el acceso de la aplicación a información personal y se ofrezca al usuario la posibilidad de continuar o cancelar la acción.Si un usuario final observa una advertencia de este tipo en un documento aparentemente inocente, puede salir de la aplicación sin poner nada en riesgo.

El código está bloqueado por la restricción del modelo de objetos de Outlook

Microsoft Office puede restringir el uso en el código de ciertas propiedades, métodos y objetos del modelo de objetos.Al restringir el acceso a estos objetos, Outlook ayuda a evitar que los gusanos de correo electrónico y virus utilicen el modelo de objetos para propósitos malintencionados.Esta característica de seguridad se conoce como restricción del modelo de objetos de Outlook.Si un complemento intenta utilizar una propiedad o un método restringido cuando está habilitada la restricción del modelo de objetos, Outlook muestra una advertencia de seguridad que permite al usuario detener la operación u otorgar acceso a la propiedad o al método por un tiempo limitado.Si el usuario detiene la operación, Outlook agregar- INS creado con soluciones de Office en Visual Studio producirá COMException.

La restricción del modelo de objetos puede afectar a los complementos de diferentes maneras, dependiendo de si Outlook se utiliza con Microsoft Exchange Server:

• Si Outlook no se utiliza con Exchange, un administrador puede habilitar o deshabilitar la restricción del modelo de objetos para todos los complementos ubicados en el equipo.

• Si Outlook se utiliza con Exchange, un administrador puede habilitar o deshabilitar la restricción del modelo de objetos para todos los complementos ubicados en el equipo, o bien, el administrador puede especificar que determinados complementos se ejecuten sin la presencia de la restricción del modelo de objetos.Los administradores también pueden modificar el comportamiento de la restricción del modelo de objetos para determinadas áreas del modelo de objetos.Por ejemplo, los administradores pueden permitir automáticamente que los complementos envíen correos electrónicos mediante programación, incluso si la restricción del modelo de objetos está habilitada.

A partir de Outlook 2007, el comportamiento de la restricción del modelo de objetos ha cambiado para mejorar la experiencia del desarrollador y el usuario mientras ayuda a mantener la seguridad de Outlook.Para obtener más información, vea Code Security Changes in Outlook 2007.

Minimizar las advertencias de la restricción del modelo de objetos

Para evitar las advertencias de seguridad cuando utiliza propiedades y métodos restringidos, asegúrese de que su complemento obtiene los objetos de Outlook del campo Application de la clase ThisAddIn del proyecto.Para obtener más información sobre este campo, vea Programar complementos de nivel de aplicación.

La restricción del modelo de objetos solo puede confiar en los objetos de Outlook obtenidos de este objeto.En cambio, los objetos obtenidos de un nuevo objeto Microsoft.Office.Interop.Outlook.Application no son de confianza, y los métodos y propiedades restringidos generarán advertencias de seguridad si la restricción del modelo de objetos está habilitada.

En el ejemplo de código siguiente se muestra una advertencia de seguridad si la restricción del modelo de objetos está habilitada.La propiedad To de la clase Microsoft.Office.Interop.Outlook.MailItem está limitada por la restricción del modelo de objetos.El objeto Microsoft.Office.Interop.Outlook.MailItem no es de confianza porque el código lo obtiene desde un objeto Microsoft.Office.Interop.Outlook.Application creado mediante el operador new en lugar de obtenerlo desde el 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);
}

En el ejemplo de código siguiente se muestra cómo utilizar la propiedad restringida To de un objeto Microsoft.Office.Interop.Outlook.MailItem en el que confía la restricción del modelo de objetos.El código utiliza el campo de confianza Application para obtener 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);
}

[!NOTA]

Si se utiliza Outlook con Exchange, obtener todos los objetos de Outlook desde ThisAddIn.Application no garantiza que el complemento tenga acceso a todo el modelo de objetos de Outlook.Por ejemplo, si un administrador de Exchange configura Outlook de modo que deniegue automáticamente todos los intentos de obtener acceso a la información de direcciones mediante el modelo de objetos de Outlook, Outlook no permitirá que el anterior ejemplo de código obtenga acceso a la propiedad To, aunque se utilice el campo ThisAddIn.Application de confianza en el ejemplo de código.

Especificar los complementos de confianza al utilizar Exchange

Cuando Outlook se utiliza con Exchange, los administradores pueden especificar que determinados complementos se ejecuten sin la presencia de la restricción del modelo de objetos.Outlook agregar- INS creado con soluciones de Office en Visual Studio no pueden gozar individualmente; son de confianza solo como grupo.

Outlook confía en un complemento basado en un código hash del archivo DLL de punto de entrada del complemento.Todos los complementos de Outlook que tienen como destino Runtime de Microsoft Visual Studio Tools para Office usan el mismo archivo DLL de punto de entrada (VSTOLoader.dll).Esto significa que si un administrador confía en cualquier complemento destinado a Runtime de Microsoft Visual Studio Tools para Office para que se pueda ejecutar en ausencia de la protección del modelo de objetos, todos los demás complementos destinados a Runtime de Microsoft Visual Studio Tools para Office también serán de confianza.Para obtener más información sobre cómo confiar en determinados complementos de modo que se puedan ejecutar en ausencia de la protección del modelo de objetos, vea Especificación del método usado por Outlook para administrar las características de prevención de virus.

Los cambios de permisos no surten efecto inmediatamente

Si el administrador ajusta los permisos de un documento o de un ensamblado, los usuarios deben salir y reiniciar todas las aplicaciones de Office para que los cambios surtan efecto.

Otras aplicaciones que hospedan aplicaciones de Microsoft Office también pueden impedir que se exijan nuevos permisos.Los usuarios deben salir de todas las aplicaciones que utiliza Office, autónomas o no, cuando se modifican las directivas de seguridad.

La configuración del centro de confianza de Microsoft Office System no afecta a las personalizaciones de complementos o de nivel de documento

Los usuarios pueden evitar que los complementos se carguen si activan una opción en el Centro de confianza.Sin embargo, agregar- INS en la aplicación y las personalizaciones de nivel de documento creados con las soluciones de Office en Visual Studio no se ven afectados por esta configuración.

Si el usuario impide que se carguen los complementos mediante el Centro de confianza, no se cargarán los siguientes tipos de complementos:

• Complementos COM administrados y no administrados.

• Documentos inteligentes administrados y no administrados.

• Complementos de automatización administrados y no administrados.

• Componentes de datos en tiempo real administrados y no administrados.

Los procedimientos siguientes describen cómo los usuarios pueden utilizar Centro de confianza para limitar agregar- INS de carga en Microsoft Office 2013 y Microsoft Office 2010.Estos procedimientos no afectan a agregar- INS o a las personalizaciones creados con las herramientas de desarrollo de Office en Visual Studio.

Para deshabilitar agregar- INS en las aplicaciones de Microsoft Office 2010 y Microsoft Office 2013

1. Elija la ficha Archivo .

2. Elija el botón ApplicationName Opciones .

3. En el panel categorías, elija Centro de confianza.

4. En el panel de detalles, elija Configuración del Centro de confianza.

5. En el panel categorías, elija Complementos.

6. En el panel Detalles, seleccione Require Application Add-ins to be Signed by Trusted Publisher o Disable all Application Add-ins.

Vea también

Otros recursos

Asegurar las soluciones de Office