It's not SQL that has the issue...it's how developers expose it...
Blaming SQL is like blaming the command line...when you've exposed it in
your program (particularly one that uses adopted authority)
On Tue, Feb 25, 2014 at 4:37 PM, James H. H. Lampert <
On 2/25/14 11:39 AM, Buck Calabro wrote:
Seriously, this is called an SQL injection attack. Instead of allowing
the end user to put any free-form text into your WHERE clause, build a
front end where they select the columns and conditions and have your
code construct the WHERE clause.
Fascinating: the Wikipedia article on "SQL Injection" describes
vulnerabilities I never imagined existed. And how even with user input
limited to the ADDLWHERE variable, a "DROP TABLE" statement could be
As if it weren't bad enough that SQL treats all databases, regardless of
their physical structure, as "bags" of sequenceless records. Now to find
out that it has built-in vulnerabilities like this. It makes me wonder
how something so inherently dangerous became an industry standard. Had
it been up to me, I'd have run Chamberlin, Messerly, and Boyce (not to
mention Codd; at least Niklaus Wirth outgrew being a dogmatic ideologue
with the theories that gave us Pascal) out of town on a rail.
Well, I was already planning on building a prompter to automate the
ADDLWHERE process (similar to the one for the QRYSLT clause in the
"OPNQRYF Super-Prompter" I added to QuestView back in 2010). Evidently I
need to not only build it, but make it mandatory (at least that will
simplify it, since it won't have to deal with any manual entry).
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives