Seguridad del depurador
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.
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 asociarse al 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 quiere asociarse 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, networkservicey localservice. Para obtener más información, vea Advertencia de seguridad: Adjuntar a un proceso que pertenezca a un usuario que no sea de confianza puede ser peligroso. Si la información siguiente le resulta sospechosa o no está seguro de su procedencia, no la adjunte 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, consulta Debugging Managed Code.
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 usa el modo de Autenticación de Windows, tenga en cuenta que es peligroso conceder permiso a un usuario que no sea de confianza para que se conecte a msvsmon, porque concede al usuario todos los permisos en el equipo que hospeda a msvsmon.
No depure un proceso desconocido en un equipo remoto: hay posibles vulnerabilidades de seguridad que pueden afectar al equipo en el que se ejecuta el depurador o que podrían poner en peligro a msvsmon. Si es imprescindible depurar un proceso desconocido, intente hacerlo localmente y utilice un firewall para poder localizar cualquier amenaza potencial.
Para obtener información sobre la configuración de msvsmon, vea Configurar el depurador remoto.
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, consulta 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 puedan usar 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. 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.
Consulte Specify symbol (.pdb) and source files (Especificación de símbolo (.pdb) y archivos de origen).
Contenido relacionado
- Configuración y preparación de la depuración
- Primer vistazo al depurador
- Advertencia de seguridad: Adjuntar a un proceso que pertenezca a un usuario que no sea de confianza puede ser peligroso. Si la información siguiente le resulta sospechosa o no está seguro de su procedencia, no la adjunte a este proceso
- Advertencia de seguridad: El depurador debe ejecutar un comando que no es de confianza