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 Microsoft Office 2010 y 2007 Microsoft Office System. Para obtener más información, 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 cumplir un objetivo concreto (por ejemplo, descargar información personal para una solicitud de empleo) y volver a utilizarlo en otro documento (como una hoja de cálculo). El código no sabe que el documento original no se está ejecutando, y puede exponerse a otras amenazas (como la revelación de información personal o la ejecución de código 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, tanto si proceden del usuario como del documento, de una base de datos, de 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 está ejecutando antes de ejecutarse el código (por ejemplo, comprobar si se está ejecutando desde un documento almacenado en una ubicación conocida y 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 el guardiá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 el guardián del modelo de objetos de Outlook. Si un complemento intenta utilizar una propiedad o un método restringido cuando está habilitado el guardiá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, los complementos de Outlook creados mediante Visual Studio Tools para Office iniciarán una excepción COMException.
El guardiá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 el guardiá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 el guardiá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 del guardián del modelo de objetos. Los administradores también pueden modificar el comportamiento del guardiá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 el guardián del modelo de objetos está habilitado.
Outlook 2007 cambia el comportamiento de protección del modelo de objetos para mejorar la experiencia del desarrollador y del usuario al mismo tiempo que ayuda a mantener la seguridad de Outlook. Para obtener más información, vea Code Security Changes in Outlook 2007.
Minimizar las advertencias del guardiá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.
El guardián del modelo de objetos sólo 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 el guardián del modelo de objetos está habilitado.
En el ejemplo de código siguiente se muestra una advertencia de seguridad si el guardián del modelo de objetos está habilitado. La propiedad To de la clase Microsoft.Office.Interop.Outlook.MailItem está restringida por el guardiá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 el guardiá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 del guardián del modelo de objetos. Los complementos de Outlook creados mediante Visual Studio Tools para Office no pueden gozar individualmente de confianza, sino 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 Motor en tiempo de ejecución 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 Motor en tiempo de ejecución 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 Motor en tiempo de ejecución 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. No obstante, los complementos de nivel de aplicación y las personalizaciones de nivel de documento creados mediante Visual Studio Tools para Office no se verán 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.
Etiquetas inteligentes administradas y no administradas.
Documentos inteligentes administrados y no administrados.
Complementos de automatización administrados y no administrados.
Componentes de datos en tiempo real administrados y no administrados.
Nota
Las etiquetas inteligentes están desusadas en Excel 2010 y Word 2010. Para obtener más información, vea Información general sobre etiquetas inteligentes.
En los siguientes procedimientos se describe cómo los usuarios pueden utilizar el Centro de confianza para restringir que se carguen complementos en Microsoft Office System 2007. Estos procedimientos no afectan a los complementos ni a las personalizaciones creados con Visual Studio Tools para Office.
Para deshabilitar los complementos en aplicaciones de Microsoft Office 2010, Excel 2007, PowerPoint 2007 o Word 2007
Haga clic en la pestaña Archivo (en aplicaciones de Microsoft Office 2010) o en el botón Microsoft Office (en aplicaciones de 2007 Microsoft Office).
Haga clic en el botón Opciones de NombreDeAplicación.
En el panel Categorías, haga clic en Centro de confianza.
En el panel Detalles, haga clic en Trust Center Settings.
En el panel Categorías, haga clic en Complementos.
En el panel Detalles, seleccione Require Application Add-ins to be Signed by Trusted Publisher o Disable all Application Add-ins.
Para deshabilitar los complementos en InfoPath 2007, Outlook 2007, Project 2007 o Visio 2007
En el menú Herramientas, haga clic en Centro de confianza.
En el panel Categorías, haga clic en Seguridad de macros.
En el panel Detalles, seleccione No Warnings and Disable All Macros o Warnings for signed macros; all unsigned macros are disabled.
En el panel Categorías, haga clic en Complementos.
En el panel Detalles, seleccione Apply macro security settings to installed add-ins.