Usar una transacción como mitigación contra la inyección de SQL

Question

Usar una transacción como mitigación contra la inyección de SQL

#1 de Tophandour (1 votos)

1

Considerando un procedimiento genérico almacenado que está sujeto a la inyección de SQL:

CREATE PROC usp_badproc
    @sql NVARCHAR(8000)
AS BEGIN
    EXEC(@sql)
END

y operando bajo los supuestos de que

el proceso solo lee datos,
el contexto operativo tiene acceso a otros recursos y métodos, incluidos UPDATE y DELETE en tablas sensibles (por ejemplo, dbo.Users o dbo.CreditCards ),
no se puede cambiar la firma del proceso
el contexto de ejecución del proceso no se puede cambiar

¿cuáles son los pros y los contras para mejorar este procedimiento como:

CREATE PROC usp_badproc
    @sql NVARCHAR(8000)
AS BEGIN
    BEGIN TRANSACTION
    EXEC(@sql)
    ROLLBACK TRANSACTION
END

Es decir, envolver la ejecución en una transacción y revertirla siempre.

Comprendo que, en esencia, solo está reduciendo el nivel del problema (por ejemplo, @sql ahora tiene que terminar con COMMIT TRANSACTION ), pero ¿agrega algún beneficio, incluso desde una perspectiva reactiva / de registro? ¿Se puede marcar la transacción de una manera que nunca sea recuperable?

Para ser claros, nunca sugeriría esto como una solución a un riesgo de inyección de SQL, solo estoy tratando de entenderlo mejor y las capas involucradas.

sql-injection

pregunta mlhDev 10.07.2018 - 21:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas sql-injection

Recomendaciones oficiales para antivirus en servidores Windows Autenticación con script OWASP ZAP

score 1 · Accepted Answer

El servidor Sql tiene un registro de todas las transacciones, por lo que al menos podría tener un registro de lo que se ejecutó (a menos que el atacante también borre el registro de transacciones). Puede recibir un mensaje de error en algún lugar y, siempre que no se borre ese registro, también lo tendrá. Por otra parte, es posible que el servidor SQL esté configurado para transacciones implícitas, de modo que cada declaración obtenga su propia transacción y se registre de todos modos.

En cuanto a los contras, no creo que esto realmente logre nada, por lo que su problema no se soluciona. Más trabajo y ofuscar, esconder o crear la ilusión de solucionar un problema de seguridad es una gran estafa. Revertir la transacción solo importa hasta que el atacante descubra que solo tienen que agregar COMMIT TRANSACTION al final de la inyección. Al menos cuando lo probé utilizando el enfoque más obvio, recibí un error cuando golpeó ROLLBACK TRANSACTION , entonces saltará a cualquier manejo de errores que tenga y quién sabe qué podría omitir si esto fuera solo una parte de un proceso. Sin embargo, una inyección mejor elaborada no generaría un error.

En general, me alegra que esto sea solo un interés académico porque no creo que gane nada. Tampoco pierdes mucho, pero ¿por qué pasar por el esfuerzo si no estás solucionando el problema?