Honestly, I appreciate the effort to raise awareness for a critical issue - SQL injection is a real problem. Still, how sincere/realistic is the proposed solution? This is like Dan Quayle promoting abstinence. It's not like any alternative, e.g., NoSQL databases, don't have their own security concerns. Wouldn't improvements to existing clients/tools/frameworks be a better approach?
Fair points. Consider this - if it's been decades and we still no one has been able to make it secure, maybe it's simply insecure. I think the concerns around other database technologies are actually fixable.
That it's easy to design insecurely doesn't mean that noone has been able to make it secure. There are many techniques to avoid various security flaws in SQL (stored procs, using proper arguments instead of string concatination, using proper access control to directly write to tables....). So it IS fixable, it's just a matter of getting people to learn these things before actually using it.
We're still suffering SQL injection attacks that make news headlines more often than monthly, so it's obviously not a solved problem. What you're suggesting is clearly not working, so let's try something new. I suggest deprecating SQL and creating a new interface to relational databases that discourages user input via string concatenation, and you think it's a bad thing...why?
In an ideal world, I'd agree. But in the real world we live in, this has a huge cost: Legacy code, tools built around SQL, enourmous amounts of real life applications handling tons of data every day.
All (serious) SQL-tutorials, books and classes DO discourage string concatenation as a way of building queries. It can be parameterized as it is today, so the problem IS solved. People are just not using the solution, sadly.
I'd rather see an evolutionary move against what you're saying with the existing SQL of today; not a complete deprecation and rewrite/recreation. If we're at the complete recreation point, this could be done to so many things - and it's often similar reasons for it not to be done (existing systems and code bases).
Yeah, agreed. I think the main takeaway is to never build a platform where the easiest or default way of doing things is insecure. Depreciation can be impossible.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Honestly, I appreciate the effort to raise awareness for a critical issue - SQL injection is a real problem. Still, how sincere/realistic is the proposed solution? This is like Dan Quayle promoting abstinence. It's not like any alternative, e.g., NoSQL databases, don't have their own security concerns. Wouldn't improvements to existing clients/tools/frameworks be a better approach?
Fair points. Consider this - if it's been decades and we still no one has been able to make it secure, maybe it's simply insecure. I think the concerns around other database technologies are actually fixable.
That it's easy to design insecurely doesn't mean that noone has been able to make it secure. There are many techniques to avoid various security flaws in SQL (stored procs, using proper arguments instead of string concatination, using proper access control to directly write to tables....). So it IS fixable, it's just a matter of getting people to learn these things before actually using it.
We're still suffering SQL injection attacks that make news headlines more often than monthly, so it's obviously not a solved problem. What you're suggesting is clearly not working, so let's try something new. I suggest deprecating SQL and creating a new interface to relational databases that discourages user input via string concatenation, and you think it's a bad thing...why?
In an ideal world, I'd agree. But in the real world we live in, this has a huge cost: Legacy code, tools built around SQL, enourmous amounts of real life applications handling tons of data every day.
All (serious) SQL-tutorials, books and classes DO discourage string concatenation as a way of building queries. It can be parameterized as it is today, so the problem IS solved. People are just not using the solution, sadly.
I'd rather see an evolutionary move against what you're saying with the existing SQL of today; not a complete deprecation and rewrite/recreation. If we're at the complete recreation point, this could be done to so many things - and it's often similar reasons for it not to be done (existing systems and code bases).
Yeah, agreed. I think the main takeaway is to never build a platform where the easiest or default way of doing things is insecure. Depreciation can be impossible.