Qual è la differenza tra EXECUTE AS USER e EXECUTE AS LOGIN che fa comportare inaspettatamente il secondo?

Recentemente ho usato EXECUTE AS LOGIN per verificare se una determinata persona poteva o non poteva usare una funzione di tabella in uno dei nostri database. I test hanno dimostrato che poteva, ma ha ripetutamente segnalato un fallimento.

La persona usa il login "WEB" per connettersi al database e ha l'utente "WEB" in quel database associato al login "WEB", quindi ho provato i seguenti script:

-- 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 prima parte andava bene con il risultato di:

WEB | WEB | WEB | RAGNATELA

Ma il secondo risultato è stato un po 'confuso:

dbo | WEB | WEB | RAGNATELA

Qual è la differenza tra EXECUTE AS USER e EXECUTE AS LOGIN che fa fallire il secondo? Inoltre, ovviamente, il primo è a livello di database e il secondo è la rappresentazione a livello di server, di ciò di cui sono a conoscenza e non spiega la situazione qui.

sql-server-2008 security

— gemisigo
fonte

Il secondo non sta "fallendo", ti sta solo dicendo che al login è assegnato un ruolo server (sysadmin). Hai controllato gli schemi richiesti dall'utente? Lo avevo già visto dove lo schema predefinito di dbo non era quello che gli sviluppatori si aspettavano che fosse. Meglio corretto nel codice facendo riferimento completo alla tabella

— Stuart Moore,

Un membro del sysadmingruppo viene sempre associato dbo, anche se ha un utente esplicito nel database. Quindi sembra che il login WEBsia membro sysadmin, quindi USER_NAME()ritorna correttamente dbonel secondo caso.

— Remus Rusanu
fonte

Controllato e confermato Era davvero un membro di amministratore di sistema. Si è scoperto che questo rapporto ha raggiunto uno degli altri sviluppatori e invece della soluzione corretta ha semplicemente assegnato il ruolo di amministratore di sistema di accesso. Non penserei nemmeno che ciò accada, sono veramente deluso. Parleremo seriamente quando tornerà. Oggi ho imparato qualcosa di nuovo, grazie.

— gemisigo,

Significa anche che l'applicazione (report?) Ha l'autorizzazione impersonale su un membro sysadmin. Guarda come viene concesso esattamente nella gerarchia dei permessi. È probabile che anche adesso il report possa, se lo desidera, impersonare un altro sysadminmembro, quindi l'applicazione di reporting è un amministratore di fatto. Vale a dire. tra l'altro un possibile vettore di attacco di privilegi, può essere utilizzato da un hacker o, più probabilmente, dal tuo staff.

— Remus Rusanu,

Se l'app repor dispone dell'autorizzazione IMPERSONATE WEBed è WEBstata rimossa da sysadminallora la porta viene chiusa. Ma vale la pena controllare comunque.

— Remus Rusanu,

Sì, dovremo controllare ancora una volta tutto ciò che riguarda i diritti per vedere se c'erano altri problemi "risolti" in questo modo. Non molto felice adesso :( Grazie ancora, Remus.

— Gemisigo,