¿Cuál es la diferencia entre EJECUTAR COMO USUARIO y EJECUTAR COMO INICIAR SESIÓN que hace que el segundo se comporte inesperadamente?

Recientemente he estado usando EJECUTAR COMO INICIAR SESIÓN para verificar si cierta persona podría o no usar una función de tabla en una de nuestras bases de datos. Las pruebas mostraron que podía pero él reportó repetidamente el fracaso.

La persona usa el inicio de sesión 'WEB' para conectarse a la base de datos y tiene el usuario 'WEB' en esa base de datos asociado con el inicio de sesión 'WEB', así que probé los siguientes scripts:

-- part 1
EXECUTE AS USER = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

-- part 2
EXECUTE AS LOGIN = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

La primera parte estuvo bien con el resultado de:

WEB | WEB | WEB | WEB

Pero el segundo resultado fue un poco confuso:

dbo | WEB | WEB | WEB

¿Cuál es la diferencia entre EJECUTAR COMO USUARIO y EJECUTAR COMO INICIAR SESIÓN que hace que el segundo falle? Además, por supuesto, el primero es el nivel de la base de datos y el segundo es la suplantación del nivel del servidor, de lo que soy consciente y no explica la situación aquí.

sql-server-2008 security

— gemisigo
fuente

El segundo no está "fallando", solo le dice que el inicio de sesión tiene una función de servidor (sysadmin) asignada. ¿Ha verificado los esquemas que solicita el usuario? Tenía eso antes donde el esquema predeterminado de dbo no es el que los desarrolladores esperaban que fuera. Se arregla mejor en el código haciendo referencia completa a la tabla

— Stuart Moore

Siempre se asigna un miembro del sysadmingrupo , incluso si tiene un usuario explícito en la base de datos. Por lo tanto, parece que el inicio de sesión es miembro , por lo tanto , regresa correctamente en el segundo caso.dboWEBsysadminUSER_NAME()dbo

— Remus Rusanu
fuente

Comprobado y confirmado. Era un miembro del administrador de sistemas de hecho. Resultó que este informe llegó a uno de los otros desarrolladores y, en lugar de la solución correcta, simplemente le asignó el rol de administrador del sistema de inicio de sesión. Ni siquiera pensaría en que eso suceda, estoy realmente decepcionado. Vamos a tener una conversación seria cuando regrese. Aprendí algo nuevo hoy, gracias.

— gemisigo

También significa que su aplicación (¿informe?) Tiene permiso de suplantación en un miembro del administrador del sistema. Mire cómo exactamente en la jerarquía de permisos se otorga esto. Es probable que incluso ahora el informe pueda, si lo desea, hacerse pasar por otro sysadminmiembro, por lo que la aplicación de informes es un administrador de sistemas de facto. Es decir. ia un posible vector de ataque de elevación de privilegios, puede ser utilizado por un pirata informático o, más probablemente, por su personal.

— Remus Rusanu

Si la aplicación de informe tiene el permiso IMPERSONATE activado WEBy WEBse eliminó de sysadminentonces, la puerta está cerrada. Pero vale la pena comprobarlo.

— Remus Rusanu

Sí, tendremos que verificar todo lo que afecta a los derechos una vez más para ver si hubo otros problemas "solucionados" de esta manera. No muy feliz en este momento :( Gracias de nuevo, Remus.

— gemisigo