Consideraciones de seguridad específicas para las soluciones de Office
Las características de seguridad proporcionadas por Microsoft .NET Framework y Microsoft Office pueden ayudarle a proteger sus soluciones de Office contra diversas amenazas de seguridad. En este tema le daremos detalles acerca de esas amenazas y le proporcionaremos varias recomendaciones para que pueda protegerse contra ellas. Asimismo, este artículo también incluye información acerca de cómo influye la configuración de seguridad de Microsoft Office en las soluciones de Office.
Se aplica a: la información de este tema se aplica a proyectos de nivel de documento y proyectos de complementos de VSTO. Consulte Características disponibles por aplicación de Office lication y tipo de proyecto.
El código de confianza se vuelve a usar en un nuevo documento malintencionado
Un atacante podría usar un código de confianza diseñado para un fin determinado (como por ejemplo, descargar información personal para una solicitud de empleo), y volver a usarlo en otro documento, como una hoja de cálculo. El código no tiene modo de detectar que no se está ejecutando en el documento original, así que si lo abre otro usuario pueden surgir otras amenazas, como que se revele información personal o que el código se ejecute con más privilegios de lo establecido anteriormente. Como alternativa, el atacante puede modificar los datos de la hoja de cálculo de forma que, cuando se envía a la víctima, se comporta inesperadamente. Al cambiar los valores, las fórmulas o las características de presentación de una hoja de cálculo vinculada a un código, el usuario malintencionado tiene la posibilidad de atacar a otro usuario enviándole un archivo modificado. De la misma manera, es posible hacer que los usuarios tengan acceso a información que no deberían conocer si se modifican los valores en la hoja de cálculo.
Puesto que la ubicación del ensamblado y la ubicación del documento deben tener suficientes elementos para poder ejecutarse, no es fácil llevar a cabo este ataque. Por ejemplo, los documentos que se envían como datos adjuntos de correos electrónicos o los documentos que se encuentran en servidores de intranet que no son de confianza, no tienen suficientes permisos para ejecutarse.
Para que este ataque sea posible, el propio código debe escribirse de forma que pueda tomar decisiones basadas en datos que potencialmente no sean de confianza. Un ejemplo, es crear una hoja de cálculo con una celda oculta que contenga el nombre de un servidor de base de datos. De ese modo, el usuario envía la hoja de cálculo a una página ASPX que intentará conectarse a ese servidor mediante una autenticación de SQL y una contraseña de SA (administrador de sistema) codificada de forma rígida. El atacante puede reemplazar el contenido de la celda oculta con un nombre de equipo diferente y obtener la contraseña de SA. Para evitar este problema, jamás codifique de forma rígida las contraseñas y, antes de acceder al servidor, compruebe en todo momento el identificador del servidor mediante una lista interna de servidores que sepa que son de confianza.
Recomendaciones
Valide siempre las entradas y los datos, tanto si proceden del usuario, del documento, de una base de datos, de un servicio web o de cualquier otro origen.
Tenga cuidado con ciertos tipos de funcionalidades, como obtener datos confidenciales en nombre del usuario y escribirlos en una hoja de cálculo no protegida.
Dependiendo del tipo de aplicación que use, le será de utilidad comprobar que el documento original se está ejecutando antes de ejecutar cualquier código. Por ejemplo, compruebe que el documento que se está ejecutando está almacenado en una ubicación conocida y segura.
Además, es una buena idea permitir que se muestre una advertencia cuando el documento se abre, si la aplicación realiza acciones con privilegios. Por ejemplo, puede crear una pantalla de presentación o un cuadro de diálogo de inicio que indique que la aplicación obtendrá acceso a información personal del usuario y hacer que el usuario elija si desea continuar o cancelar. Si el usuario final recibe una advertencia de este tipo de un documento aparentemente inocente, podrá salir de la aplicación antes de poner ninguno de sus datos en peligro.
El código está bloqueado por la protección del modelo de objetos de Outlook
Microsoft Office puede restringir el uso de ciertas propiedades, métodos y objetos en el modelo de objetos. Al restringir el acceso a estos objetos, Outlook ayuda a evitar que los gusanos de correo electrónico y los virus usen el modelo de objetos con fines malintencionados. Esta característica de seguridad se conoce como Protección del modelo de objetos de Outlook. Si un complemento vsto intenta usar una propiedad o método restringido mientras la protección del modelo de objetos está habilitada, Outlook muestra una advertencia de seguridad que permite al usuario detener la operación o permitir que el usuario conceda acceso a la propiedad o al método durante un período de tiempo limitado. Si el usuario detiene la operación, los complementos VSTO de Outlook creados mediante soluciones de Office en Visual Studio, crearán un COMException.
La protección del modelo de objetos puede afectar a los complementos VSTO de maneras diferentes, dependiendo de si se utiliza Outlook con Microsoft Exchange Server:
Si no se utiliza Outlook con Exchange, un administrador puede habilitar o deshabilitar la protección del modelo de objetos para todos los complementos VSTO en el equipo.
Si Outlook se usa con Exchange, el administrador puede habilitar o deshabilitar la protección del modelo de objetos de todos los complementos VSTO del equipo o puede permitir que ciertos complementos VSTO se ejecuten sin que se aplique la protección del modelo de objetos. Asimismo, los administradores también pueden modificar el comportamiento de la protección del modelo de objetos en determinadas áreas de ese modelo. Por ejemplo, los administradores pueden permitir automáticamente que los complementos de VSTO envíen correo electrónico mediante programación, incluso si la protección del modelo de objetos está habilitada.
A partir de Outlook 2007, el comportamiento de la protección del modelo de objetos se ha cambiado para mejorar la experiencia del desarrollador y del usuario, a la vez que se mantiene la seguridad de Outlook. Para obtener más información, vea Cambios de seguridad de código en Outlook 2007.
Minimizar las advertencias de protección del modelo de objetos
Para evitar las advertencias de seguridad cuando use propiedades y métodos restringidos, asegúrese de que el complemento VSTO obtenga objetos de Outlook desde el campo Application de la clase ThisAddIn en su proyecto. Para obtener más información sobre este campo, vea Complementos VSTO de programa.
La protección del modelo de objetos solo permitirá aquellos objetos de Outlook obtenidos de este objeto . En cambio, aquellos objetos que se obtengan de un nuevo objeto Microsoft.Office.Interop.Outlook.Application, no serán de confianza y los métodos y propiedades restringidos generarán varias advertencias de seguridad si la protección del modelo de objetos está habilitada.
En el siguiente ejemplo de código se muestra una advertencia de seguridad si está habilitada la protección del modelo de objetos. La propiedad To de la clase Microsoft.Office.Interop.Outlook.MailItem está restringida por la protección del modelo de objetos. El Microsoft.Office.Interop.Outlook.MailItem objeto no es de confianza porque el código lo obtiene de un Microsoft.Office.Interop.Outlook.Application objeto que se crea mediante el operador new , en lugar de obtenerlo del Application campo.
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 usar la propiedad restricted To de un Microsoft.Office.Interop.Outlook.MailItem objeto que es de confianza para la protección del modelo de objetos. El código usa el campo de confianza Application para obtener Microsoft.Office.Interop.Outlook.MailItem.
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 Outlook se utiliza con Exchange, obtener todos los objetos de Outlook desde ThisAddIn.Application no garantiza que el complemento VSTO pueda obtener acceso a todo el modelo de objetos de Outlook. Por ejemplo, si un administrador de Exchange establece Outlook para denegar automáticamente todos los intentos de obtener acceso a la información de dirección mediante el modelo de objetos de Outlook, Outlook no permitirá que el ejemplo de código anterior acceda a la propiedad To, aunque el ejemplo de código use el campo de confianza ThisAddIn.Application .
Especificar qué complementos confiar al usar Exchange
Cuando Outlook se usa con Exchange, los administradores pueden especificar que determinados complementos VSTO se ejecuten sin necesidad de acudir a la protección del modelo de objetos. Los complementos VSTO de Outlook creados mediante el uso de soluciones de Office en Visual Studio, no son de confianza por si mismos; solo se convierten en elementos de confianza si van en grupo.
Outlook confía en un complemento de VSTO basado en un código hash del archivo DLL de punto de entrada del complemento VSTO. Todos los complementos VSTO de Outlook que tienen como destino el entorno de ejecución de 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 de VSTO que tenga como destino el entorno de ejecución de Visual Studio Tools para Office que se ejecute sin encontrar la protección del modelo de objetos, todos los demás complementos de VSTO que tienen como destino el entorno de ejecución de Visual Studio Tools para Office también son de confianza. Para obtener más información sobre cómo confiar en determinados complementos VSTO de modo que se puedan ejecutar en ausencia de la protección del modelo de objetos, consulte 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 usen Office, autónomas o no, cuando se modifican las directivas de seguridad.
La configuración del Centro de confianza en el sistema de Microsoft Office no afecta a los complementos ni a las personalizaciones de nivel de documento
Los usuarios pueden evitar que los complementos VSTO se carguen si activan una opción en el Centro de confianza. Sin embargo, los complementos VSTO 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 VSTO mediante el Centro de confianza, no se cargarán los siguientes tipos de complementos:
Complementos COM VSTO administrados y no administrados.
Documentos inteligentes administrados y no administrados.
Complementos VSTO 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 usar el Centro de confianza para restringir que los complementos de VSTO se carguen en Microsoft Office 2013 y Microsoft Office 2010. Estos procedimientos no afectan a los complementos VSTO o a las personalizaciones creadas mediante el uso de herramientas de desarrollo de Office en Visual Studio.
Para deshabilitar complementos de VSTO en aplicaciones de Microsoft Office 2010 y Microsoft Office 2013
Haga clic en la pestaña Archivo .
Elija el botón Opciones applicationName.
En el panel de categorías, haga clic en Centro de confianza.
En el panel de detalles, haga clic en Configuración del Centro de confianza.
En el panel de categorías, haga clic en Complementos.
En el panel de detalles, seleccione Solicitar que los complementos de la aplicación estén suscritos por un editor de confianza o Deshabilitar todos los complementos de la aplicación.