Considerazione di una stored procedure generica soggetta all'iniezione SQL:
CREATE PROC usp_badproc
@sql NVARCHAR(8000)
AS BEGIN
EXEC(@sql)
END
e operano secondo le ipotesi che
- solo proc legge i dati,
- il contesto operativo ha accesso ad altre risorse e metodi, tra cui
UPDATE
eDELETE
su tabelle sensibili (ad esempiodbo.Users
odbo.CreditCards
), - la firma di proc non può essere modificata
- il contesto di esecuzione di proc non può essere modificato
quali sono i pro e i contro per migliorare questa procedura come:
CREATE PROC usp_badproc
@sql NVARCHAR(8000)
AS BEGIN
BEGIN TRANSACTION
EXEC(@sql)
ROLLBACK TRANSACTION
END
Ovvero, avvolgendo l'esecuzione in una transazione e ripristinandola sempre.
Capisco che in sostanza stai solo spingendo il problema verso il basso (ad esempio, @sql deve finire con COMMIT TRANSACTION
), ma aggiunge alcun vantaggio, anche da una prospettiva reattiva / di registrazione? La transazione può essere contrassegnata in modo da non essere mai recuperabile?
Per essere chiari, non suggerirei mai questo come una soluzione a un rischio di iniezione SQL, sto solo cercando di capirlo ulteriormente e gli strati coinvolti.