¿Se puede utilizar xp_cmdshell de manera segura dentro de un proceso almacenado y hay situaciones en las que realmente no hay otra opción? En otras palabras, ¿debería su uso dentro de un proceso almacenado siempre ser marcado como un problema de seguridad (como lo recomienda un analizador de código fuente conocido)?
Dicho de otra manera, ¿estaría de acuerdo con la siguiente declaración (cita directa)?
La función xp_cmdshell no se puede usar de manera segura. No debe utilizarse.
Siempre es un riesgo . Siempre debe ser revisado . Puede ser adecuadamente mitigado .
Hay usos legítimos, a veces necesidades, ¡pero observa tu opinión de cerca!
Apagar xp_CmdShell es un poco como poner un velo sobre la carne podrida. Aporta a la mesa una falsa sensación de seguridad y las moscas aún pueden llegar a la carne. Permíteme explicarte.
¿Quién puede usar xp_CmdShell? Está bien. Solo las personas / inicios de sesión de aplicaciones con privilegios "SA" o las personas con las que cometió el horrible error de otorgarle un proxy pueden usarlo.
Siguiente pregunta. Si tiene xp_CmdShell desactivado, ¿quiénes son las únicas personas que pueden volver a encenderlo? Corregir de nuevo! Solo las personas / aplicaciones con privilegios "SA" pueden volver a activarlo.
Entonces, ¿cuál es el verdadero problema de que xp_CmdShell sea un riesgo de seguridad? La respuesta es que xp_CmdShell NO es un riesgo de seguridad. La mala seguridad es el único riesgo de seguridad. Si un pirata informático o un usuario interno malintencionado ingresa al sistema con "SA" privs, entonces pueden activar xp_CmdShell en cualquier momento. Sí, esa acción se registra pero solo proporciona un testimonio documentado de que faltaba una falta de seguridad para empezar.
Girar xp_CmdShell no hace nada por seguridad, excepto para proporcionar una oportunidad para que esa parte del código de un pirata informático vuelva a activarlo.
Lo diré de nuevo. xp_CmdShell no es un riesgo de seguridad. Sólo la mala seguridad es un riesgo de seguridad. Arregla tu seguridad y luego enciende xp_CmdShell. Es una herramienta maravillosa y se la está perdiendo debido a malas prácticas de seguridad y mitos.
Creo que "no se debe usar" es probablemente un buen consejo. Eso no es un categórico "Es siempre inseguro", sino más bien un reconocimiento de que xp_cmdshell es peligroso y su uso es motivo de preocupación y un examen cuidadoso.
E incluso si cree que sabe cómo evitar los riesgos de seguridad, xp_cmdshell probablemente no sea la mejor herramienta para usar. Lo más probable es que haya una mejor solución (una que, por fortuna, también es menos riesgosa).
Para enfatizar la respuesta de jl01 (a la que le di un +1) ...
Por extraño que parezca, una buena medida de un SQL Server correctamente protegido y seguro es tener realmente habilitado xp_CmdShell. Lo que quiero decir con esto es que si su sistema es lo suficientemente seguro, no debería preocuparse por asuntos triviales como la habilitación Y USO DE xp_CmdShell.
Especialmente a partir de SQL Server 2005, virtualmente no hay razón por la cual cualquier usuario que no sea DBA debería tener privilegios mayores que PUBLIC y EXECUTE en procedimientos almacenados en un sistema correctamente bloqueado. De hecho, implementado correctamente, los usuarios con privilegios PUBLIC deben poder ejecutar un procedimiento almacenado que contenga llamadas a xp_CmdShell sin poder ejecutar xp_CmdShell directamente.
Creo que es irónico que MS haya creado el proxy de shell de comandos para permitir que los usuarios de bajos recursos ejecuten xp_CmdShell directamente cuando ni siquiera deberían poder ver una tabla.
¿Qué tipo de seguridad se usa en su entorno de SQL Server, Mixto o Integrado (Windows)? ¿Cuántos hay en la función sysadmin SQL Server? Las mejores prácticas de MS requieren una autenticación integrada (sin inicio de sesión, sin inicio de sesión de SQL) y solo dos en la función de servidor de sysadmin SQL Server. Afirmo que seguir estas mejores prácticas mitiga en gran medida la exposición de uno. Además, xp_cmdshell (modo pre sqlcmd y pre-Powershell) ofrece la posibilidad de copiar archivos de registro de transacciones desde el servidor de producción al servidor DR a cientos de millas de distancia de un trabajo programado del Agente SQL. Aquí no hay maldad, pero como dice el cartel, "depende".
Lea otras preguntas en las etiquetas sql-injection databases