¿Merece la pena desde el punto de vista de seguridad limitar al usuario del servidor de base de datos para el sitio web ASP.NET a solo EJECUTAR en procedimientos almacenados?

Hay dos razones principales (de seguridad) para hacer esto, más allá del simple uso de consultas parametrizadas:

• Cumplimiento del tipo de parámetro
• Mínimo privilegio.

El principio de privilegio mínimo requiere que usted permita que cualquier entidad (usuario o aplicación) acceda solo a lo que necesite para realizar la tarea definida. Si no restringe la aplicación web solo a los SP, la aplicación podría ejecutar cualquier consulta arbitraria.
Tenga en cuenta que esto es relevante en dos situaciones: evitar que un atacante, que logró encontrar una vulnerabilidad en su aplicación (inyección de SQL o cualquier otra vulnerabilidad que pudiera permitirle ejecutar código), ejecute consultas SQL maliciosas; y, mucho menos riesgo, los desarrolladores que buscan accesos directos inseguros y no aprobados (o incluso desarrolladores maliciosos).
Al otorgar solo los privilegios de EJECUTAR sobre los SP requeridos, evitará que la aplicación ejecute cualquier consulta que no esté predefinida.

Wrt impone los tipos de parámetros, aunque es posible implementar esto de otras maneras, esto lleva el tipo de imposición a la base de datos, pero antes de que llegue al servidor db. Es decir. usando los tipos que están en realidad definidos en la base de datos, y sin saltar accidentalmente un parámetro.

Tenga en cuenta que para hacer esto correctamente y evitar algunos errores comunes, desea:

1. defina una cuenta de usuario específica para la aplicación ASP.NET
2. asigne la cuenta a un personalizado rol de DB
3. elimine la cuenta de todos los demás roles, como dbo .
4. conceda privilegios EXECUTE al rol de base de datos personalizado que creó
5. elimine todos los demás privilegios en los SP, tablas y otros objetos de base de datos. Esto incluye roles "públicos" predeterminados, y así sucesivamente.
6. asegúrese de que la función de base de datos personalizada no tenga otros privilegios.

Absolutamente.

Pero luego debe tener cuidado con los procedimientos almacenados. Si uno pudiera permitir que se le pasaran consultas arbitrarias, entonces todavía se encuentra atrapado en la misma posición.

El principio de privilegio mínimo viene a la mente aquí, ahora es un poco anecdótico. En PostgreSQL (sí, me doy cuenta de que esta es una pregunta de SQL Server, pero podría ser algo a tener en cuenta) es posible que un usuario sin privilegios escriba una función que sobrecargue (el mismo nombre de función + parámetros) que pueda ser maliciosa consulta. Cuando un usuario privilegiado ejecuta esta consulta, puede pensar que está ejecutando la función de agregar predeterminada cuando en realidad está utilizando la maliciosa. Como desarrollador, sé que estás creando una pesadilla de mantenimiento, porque siempre habrá una consulta "única" que debe escribirse. Entonces, aquí hay una pregunta: cuando creas una nueva cuenta de usuario, si esa es una consulta predefinida, no te has otorgado ninguna protección adicional. Se podría argumentar que, de hecho, lo ha empeorado, ya que ahora permite que un atacante monitoree su sistema de forma indefinida, a menos que supervise constantemente los archivos de registro de los nuevos usuarios. Además, los datos cambian, por lo que la declaración UPDATE es su nuevo peor enemigo, ya que le permite a alguien poner javascript directamente en un registro que se devuelve, ya que estoy hablando por experiencia, todos confían en que los datos de la base de datos ya están protegidos.

Aquí hay un inconveniente desagradable: una vez tuvimos este tipo de reglas, pero no todas las solicitudes de base de datos encajan perfectamente en los procedimientos almacenados. Entonces, lo que sucedió fue que muchos de los desarrolladores creaban manualmente SQL dentro de los procedimientos almacenados y lo ejecutaban allí. Esto llevó a una gran cantidad de código feo y agujeros potenciales desagradables, ya que sp_executsql , al menos en ese momento, se ejecutaría con permisos de nivel sa una vez que estuviera dentro de un proceso almacenado y la entrada de desinfección dentro de los procedimientos de SQL es mucho más fea que la entrada de desinfección Un lenguaje de aplicación moderno.

Comenzamos a ejecutar con permitir operaciones CRUD en tablas y aplicar la parametrización en la capa de aplicación después de que esto saliera a la luz.