Utilizzo di una transazione come mitigazione contro l'iniezione SQL

Question

Utilizzo di una transazione come mitigazione contro l'iniezione SQL

#1 da (1 voti)

1

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 e DELETE su tabelle sensibili (ad esempio dbo.Users o dbo.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.

sql-injection

posta mlhDev 10.07.2018 - 21:37

fonte

1 risposta

Leggi altre domande sui tag sql-injection

Autenticazione con OWASP ZAP Script È qualcosa di simile a fail2ban necessario per un accesso ssh con chiave solo per una frequenza limitata (senza password) ssh?

score 1 · Accepted Answer

Il server SQL ha un registro di tutte le transazioni, quindi almeno è possibile avere una registrazione di ciò che è stato eseguito (a meno che l'autore dell'attacco non abbia cancellato anche il log delle transazioni). È possibile che venga visualizzato un messaggio di errore da qualche parte e fino a quando tale registro non viene cancellato anche tu avrai quello. Quindi, di nuovo, è possibile che Sql Server sia impostato su transazioni implicite, quindi ciascuna istruzione ottiene la propria transazione e viene comunque registrata.

Per quanto riguarda gli svantaggi, non penso che tutto ciò avvenga davvero così il tuo problema non è stato risolto. Più lavoro e offuscamento, occultamento o creazione dell'illusione di risolvere un problema di sicurezza è un grosso problema. Il rollback della transazione è importante solo fino a quando l'aggressore non capisce che devono solo aggiungere COMMIT TRANSACTION alla fine della loro iniezione. Almeno quando l'ho provato usando l'approccio più ovvio, ho ricevuto un errore quando ha colpito ROLLBACK TRANSACTION , quindi salterà a qualsiasi errore di gestione e chi sa cosa potrebbe saltare se questa fosse solo una parte di un processo. Tuttavia un'iniezione perfezionata non genererebbe un errore.

Nel complesso, sono contento che questo sia solo interesse accademico perché non penso che tu guadagni nulla. Non perdi neanche troppo, ma perché fare lo sforzo se non risolvi il problema?