Re^4: Preventing malicious T-SQL injection attacks

Comment on Re^4: Preventing malicious T-SQL injection attacks
Re^5: Preventing malicious T-SQL injection attacks by davorg (Chancellor) on Mar 05, 2007 at 16:05 UTC
You can question whatever you want. It's your code, after all. But you need to know the number of parameters in order to create an SQL string with the correct number of placeholders. So DBI checks the number of parameters for you for free. You get an extra layer of defensive programming for no cost. I can't see any reason why you wouldn't want to make use of it. -- <http://dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re^6: Preventing malicious T-SQL injection attacks by Win (Novice) on Mar 05, 2007 at 16:31 UTC
I think that it would be good when SELECT is used in a similar circumstance. But when that particular feature is used with EXEC I believe it is redundant code and therefore is best not used.	[reply]
Re^7: Preventing malicious T-SQL injection attacks by davorg (Chancellor) on Mar 05, 2007 at 16:55 UTC
But what is redundant? What would you remove? Like I said, this is a completely free feature. There is no code in there which specifically checks for the right number of parameters, it's just something that `execute` gives you for free. There is no redundancy. There is nothing to remove. If you find something to remove then I'd love to see it. -- <http://dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re^8: Preventing malicious T-SQL injection attacks by Win (Novice) on Mar 05, 2007 at 17:42 UTC


good chemistry is complicated, and a little bit messy -LW
	PerlMonks

Re^4: Preventing malicious T-SQL injection attacks

The best material for plates (tableware) is: