Seguridad del depurador

Artículo
08/10/2011

La posibilidad de depurar otro proceso le confiere amplios poderes que, de otra forma, no tendría, especialmente al depurar de forma remota. Un depurador malintencionado podría infligir daños generalizados en el equipo depurado. Debido a esto, hay restricciones sobre quién puede depurar. Para obtener más información, vea Permisos de depuración remota.

Sin embargo, muchos desarrolladores no comprenden que la amenaza de seguridad también puede presentarse en la dirección contraria. Es posible que el código malintencionado del proceso depurado comprometa la seguridad del equipo desde donde se depura: hay una serie de ataques de seguridad contra los que es preciso protegerse.

Procedimientos recomendados para la seguridad

Hay una relación de confianza implícita entre el código que se depura y el depurador. Si está dispuesto a depurar código, también debería ejecutarlo. Lo importante es que debe poder confiar en lo que está depurando. Si no tiene confianza, no debería depurarlo, o debería hacerlo desde un equipo que pueda poner en riesgo y en un entorno aislado.

Para reducir la superficie de ataque potencial, se debería deshabilitar la depuración de los equipos de producción. Por la misma razón, nunca se debería habilitar indefinidamente.

Seguridad de la depuración administrada

Las siguientes recomendaciones generales se aplican a toda la depuración administrada.

Se debe tener cuidado al asociar al proceso de un usuario que no sea de confianza: si lo hace, está dando por sentado que es digno de confianza. Si intenta asociar a un proceso de un usuario que no es de confianza, aparecerá un cuadro de diálogo de confirmación con una advertencia de seguridad que le preguntará si desea asociar al proceso. " Los "usuarios de confianza" son, además del propio usuario, un conjunto de usuarios estándar definidos generalmente en los equipos en los que se ha instalado .NET Framework, como aspnet, localsystem, networkservice y localservice. Para obtener más información, vea Advertencia de seguridad: La asociación a un proceso de un usuario que no es de confianza puede ser peligrosa. Si la información siguiente parece sospechosa o no está seguro, no asocie a este proceso.
Se debe tener cuidado al descargar un proyecto de Internet y cargarlo en Visual Studio. Esta práctica es muy arriesgada incluso sin depuración. Si lo hace, está dando por sentado que el proyecto y el código que contiene son dignos de confianza.

Para obtener más información, vea Depurar código administrado.

Seguridad de la depuración remota

La depuración local suele ser más segura que la depuración remota. La depuración remota aumenta la superficie total que se puede analizar.

El Monitor de depuración remota de Visual Studio (msvsmon.exe) se utiliza en la depuración remota, y hay varias recomendaciones de seguridad para configurarlo. La configuración preferida del modo de autenticación es Autenticación de Windows, porque el modo Sin autenticación no es seguro. Si se utiliza el modo de Autenticación de Windows, se debe tener en cuenta que, tal como se indicará en un cuadro de diálogo de advertencia, es peligroso conceder permiso para conectarse a msvsmon a un usuario que no es de confianza.

No depure un proceso desconocido en un equipo remoto: existe un riesgo de ataques que pueden afectar al equipo en el que se ejecuta el depurador o que podrían poner en peligro a msvsmon.exe, el Monitor de depuración remota de Visual Studio. Si es imprescindible depurar un proceso desconocido, intente hacerlo localmente y utilice un firewall para poder localizar cualquier amenaza potencial.

Para obtener más información, vea Instalación de la depuración remota.

Seguridad de la depuración de servicios Web

La depuración local es más segura, pero como probablemente Visual Studio no esté instalado en el servidor Web, quizás no pueda realizarla. Normalmente, los servicios Web se depuran de forma remota, excepto durante el desarrollo. Por tanto, las recomendaciones de seguridad para la depuración remota también se aplican a la depuración de servicios Web. A continuación se indican algunos procedimientos adicionales recomendados para la seguridad. Para obtener más información, vea Debugging XML Web Services.

No habilite la depuración en un servidor Web que esté en peligro.
Asegúrese de que el servidor Web es seguro antes de realizar la depuración. Si no está totalmente seguro, no lo depure.
Extreme las precauciones si depura un servicio Web expuesto en Internet.

Componentes externos

Tenga en cuenta el estado de confianza de los componentes externos con los que interactúa su programa, sobre todo si usted no ha escrito el código. Tenga también en cuenta los componentes que pueda utilizar Visual Studio o el depurador.

Símbolos y código fuente

Las dos herramientas siguientes de Visual Studio merecen una reflexión acerca de la seguridad:

Servidor de origen, que proporciona las versiones de código fuente desde un repositorio de código fuente. Resulta útil cuando no se tiene la versión actual del código fuente de un programa. Para obtener más información, vea Cómo: Obtener código fuente utilizando el servidor de origen y Advertencia de seguridad: El depurador debe ejecutar un comando que no es de confianza.
Servidor de símbolos, que se utiliza para proporcionar los símbolos necesarios para depurar un bloqueo durante una llamada del sistema. Para obtener más información, vea Cómo: Especificar el comportamiento de carga y las ubicaciones de los símbolos y Cómo: Utilizar un servidor de símbolos.