2 Realized I was missing something with how I crafted my injection
source | link

Sql Server has a log of all transactions so at least you could possibly have a record of what was run (unless the attacker also erased the transaction log). You'll probablyYou may get an error message somewhere and as long as that log isn't erased you'll have that as well. Then again, you may have Sql Server set to implicit transactions so each statement gets its own transaction and gets logged anyway.

As far as cons, I don't think that this really accomplishes anything so your issue isn't fixed. More work and obfuscating, hiding, or creating the illusion of fixing a security issue is a pretty big con. Rolling back the transaction only matters until the attacker figures out that they just have to add COMMIT TRANSACTION to the end of their injection. At least when I tried it using the most obvious approach, I got an error when it hit ROLLBACK TRANSACTION so then it will jump to whatever error handling you have and who knows what it might skip if this was just one part of a process. A better crafted injection wouldn't generate an error, though.

Overall, I'm glad that this is just academic interest because I don't think you gain anything. You don't lose terribly much either but why go through the effort if you're not fixing the issue?

Sql Server has a log of all transactions so at least you could possibly have a record of what was run (unless the attacker also erased the transaction log). You'll probably get an error message somewhere and as long as that log isn't erased you'll have that as well. Then again, you may have Sql Server set to implicit transactions so each statement gets its own transaction and gets logged anyway.

As far as cons, I don't think that this really accomplishes anything so your issue isn't fixed. More work and obfuscating, hiding, or creating the illusion of fixing a security issue is a pretty big con. Rolling back the transaction only matters until the attacker figures out that they just have to add COMMIT TRANSACTION to the end of their injection. At least when I tried it, I got an error when it hit ROLLBACK TRANSACTION so then it will jump to whatever error handling you have and who knows what it might skip if this was just one part of a process.

Overall, I'm glad that this is just academic interest because I don't think you gain anything. You don't lose terribly much either but why go through the effort if you're not fixing the issue?

Sql Server has a log of all transactions so at least you could possibly have a record of what was run (unless the attacker also erased the transaction log). You may get an error message somewhere and as long as that log isn't erased you'll have that as well. Then again, you may have Sql Server set to implicit transactions so each statement gets its own transaction and gets logged anyway.

As far as cons, I don't think that this really accomplishes anything so your issue isn't fixed. More work and obfuscating, hiding, or creating the illusion of fixing a security issue is a pretty big con. Rolling back the transaction only matters until the attacker figures out that they just have to add COMMIT TRANSACTION to the end of their injection. At least when I tried it using the most obvious approach, I got an error when it hit ROLLBACK TRANSACTION so then it will jump to whatever error handling you have and who knows what it might skip if this was just one part of a process. A better crafted injection wouldn't generate an error, though.

Overall, I'm glad that this is just academic interest because I don't think you gain anything. You don't lose terribly much either but why go through the effort if you're not fixing the issue?

1
source | link

Sql Server has a log of all transactions so at least you could possibly have a record of what was run (unless the attacker also erased the transaction log). You'll probably get an error message somewhere and as long as that log isn't erased you'll have that as well. Then again, you may have Sql Server set to implicit transactions so each statement gets its own transaction and gets logged anyway.

As far as cons, I don't think that this really accomplishes anything so your issue isn't fixed. More work and obfuscating, hiding, or creating the illusion of fixing a security issue is a pretty big con. Rolling back the transaction only matters until the attacker figures out that they just have to add COMMIT TRANSACTION to the end of their injection. At least when I tried it, I got an error when it hit ROLLBACK TRANSACTION so then it will jump to whatever error handling you have and who knows what it might skip if this was just one part of a process.

Overall, I'm glad that this is just academic interest because I don't think you gain anything. You don't lose terribly much either but why go through the effort if you're not fixing the issue?