Timeline for Why did SQL injection prevention mechanism evolve into the direction of using parameterized queries?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 16, 2016 at 19:23 | comment | added | JimmyJames | @SantiBailors To add to what Useless wrote, I agree that if you are concatenating SQL with user input, you are still subject to SQLI but that's not the only reason you might concatenate Strings together to generate parameterized statements is if you have variable numbers of parameters. Templates work well for this kind of thing like what MyBatis/IBatis provides. | |
| Sep 16, 2016 at 15:16 | comment | added | Useless | You might safely concatenate a query from a bunch of constant strings though, at configuration time. It doesn't mean you're concatenating arbitrary user input. | |
| Sep 14, 2016 at 16:27 | comment | added | TomTom | Ah, off by 2 years. Amazing - I was actually part of the technical beta for a project I was in... yeah, it was added back then. Before that - you better used prepared statements for performance ;) Actually stored procedures. So, there are factual reasons - databases are complex and are around a LONG time. | |
| Sep 14, 2016 at 15:35 | comment | added | Mike Dimmick | Plan caching for dynamic SQL was in fact added to SQL Server 7.0, in 1998 - sqlmag.com/database-performance-tuning/… | |
| Sep 14, 2016 at 14:37 | comment | added | TomTom | Yes, but as I said - by the time they were invented, dynamic SQL came with a quite decent performance hit ;) Even today people tell you that dynamic SQL query plans in sql server are not reused (which is wrong since - hm - as I said some point between 2000 and 2007 - so QUITE long). At that old time you really wanted PREPARED statements if you run sql multiple times ;) | |
| Sep 14, 2016 at 14:13 | comment | added | JimmyJames | Having parameterized queries does not eliminate the ability to do string concatenation. You can do string concatenation to generate a parameterized query. Just because a feature is useful doesn't mean it's always a good choice for a given problem. | |
| Sep 14, 2016 at 13:54 | comment | added | TomTom | Two actually. First, it is not always totally trivial - why deal with memory allocation etc. when it is not needed. But second, in ancient times performance caching sql database side was not exactly that great - compilation SQL was expensive. As side effect of using one sql prepared statements (which is where parameters come from), exeuction plans could be reused. SQL Server introduced auto parameterization (to reuse query plans even without parameters - they are deducted and implied) I think either 2000 or 2007 - somewhere in between, IIRC. | |
| Sep 14, 2016 at 13:50 | comment | added | Dennis | thanks. Why was there a need to avoid string concatenation? It seems to me like that would be a useful feature. Did someone have an issue with it? | |
| Sep 14, 2016 at 11:44 | history | answered | TomTom | CC BY-SA 3.0 |