4 ms·

So you're saying... Properly escaping queries is a bad idea because you might forget to do it and if you forget to do it then it doesn't work. Here's a funny

So you're saying... Properly escaping queries is a bad idea because you might forget to do it and if you forget to do it then it doesn't work. Here's a funny thought, though. I remember, many years ago, doing a code review and noticing something odd. The very smart developer who always used parameterized queries had written a simple insert into table X. It was all properly parameterized. Table X, however, had an on insert trigger which called a stored proc which was about eight pages long. In that stored proc, two of the parameters were concatenated into a select which was then eval-ed, thus leading to a very serious injection possibility. So, in response to your last paragraph, yes, you still have to think about injection possibility even if you use prepared statements. Really, that should be the first rule of designing for security: ALWAYS think.

tptacek 17y ago
That third paragraph, refering to dynamic SQL inside of a stored procedure, happens often enough that I thought it made sense to bring it up here several months ago: http://news.ycombinator.com/item?id=824594 http://news.ycombinator.com/item?id=824594 You'd do well to read the rest of the recommendations in that thread as well. I cannot understand why anyone would opt for concatenated SQL over parameterized queries when both were available. It seems like simple, ignorant arrogance. As a contractor for small businesses who won't have their code reviewed by people like us, developers like you should be especially sensitive to this issue; your customers are going to be screwed over by that code long after you've moved on.