La utilidad de línea de comandos sqlcmd tiene una función para permitir la sustitución de parámetros, desde los parámetros de la línea de comandos y las variables de entorno. enlace
Si un atacante controla las variables, ¿hay alguna forma de escribir los scripts para que no sean vulnerables a la inyección de SQL o esto es intrínsecamente inseguro en esa situación?
Si el atacante controla las entradas de SQLCMD, entonces pueden hacer cualquier cosa que puedan hacer sus credenciales de inicio de sesión (autorizadas o robadas). Eso es simplemente el funcionamiento normal.
No hagas esto. Esta es una mala práctica si hay alguna entrada desde el exterior que vaya a su SQLCMD.
Si insistes en esto, entonces si quieres usar SQLCMD con la sustitución de parámetros de las variables de entorno (tal vez), probablemente quieras experimentar con credenciales que solo pueden EJECUTARSE dentro de un determinado esquema limitado
CREATE SCHEMA FromSqlCmd AUTHORIZATION myuser
GRANT EXECUTE ON SCHEMA::[FromSqlCmd] TO [myschema_execute];
Dentro de cada procedimiento almacenado, NUNCA concatene lo que se pasa a SQL dinámico.
NUNCA coloque los resultados en una tabla sin una lista blanca; de lo contrario, se está abriendo para la inyección de sql de segundo orden.
Si está considerando Powershell, entonces cjsommer.com tiene un artículo sobre esto : encontró que ninguno de los comandos SQLPS de powershell está protegido contra la inyección, incluso con parámetros.
Si realmente permite que la entrada (validada o no) de otros sea parte de su línea de comando para SQLCMD, entonces se está abriendo para la inyección de línea de comando. El & el carácter es una forma para que un símbolo del sistema ejecute varios comandos; pruébalo con
C: & cd \ & format /? & del /?
Ahora imagine esto en medio de su sqlcmd.
También tenga en cuenta que Powershell utiliza; para separar comandos.
Lea otras preguntas en las etiquetas sql-injection sql-server injection