I think I've come up with a solution to the SQL injection issue here.
In the first place, since this is a general-purpose access utility for
any file that can be accessed via JDBC, not some kind of public portal
into specific records of a specific file, presumably anybody who wanted
to do anything intentionally malicious would be using, say, SQuirreL.
At any rate, in the example call,
rs1 = jdbc_ExecQryCS( conn : %UCS2('Select * '
+ ' from ' + %TRIM(QUALTBL) + ' WHERE ((')
+ %TRIM(WHERECLAUSE1) + %UCS2(') ') + %TRIM(ORWHERE1)
+ %UCS2(') AND (') + %UCS2(%TRIM(ADDLWHERE))
+ %UCS2(') ORDER BY ' + ORDERBY));
"WHERECLAUSE1" and "ORWHERE1" together form an elaborate,
programmatically-generated WHERE clause used not to restrict access, but
as the key to forcing SQL to mimic the behavior of RLA, whereas
"ADDLWHERE" is what the user adds, in order to find specific records of
interest. And note that ADDLWHERE is ANDed with the
WHERECLAUSE1/ORWHERE1 combination, and is at a nonzero nesting level of
parentheses.
Thus, in order to break out of the AND, ADDLWHERE would have to
internally drop to a negative nesting level of parentheses (very easy to
detect, and the most it would get you would be a malfunction of the
RLA-mimicry), and in order to break out of the statement (assuming
neither the driver nor the engine shuts you down for trying), you would
need a semicolon outside of a quoted string.
So if we scan ADDLWHERE, looking for single-quote, semicolon,
left-paren, and right-paren, we can easily detect (1) unbalanced quotes,
(2) semicolons outside of quoted strings, and (3) parens outside of
quoted strings, which could lead to (4) a negative nesting level, or (5)
unbalanced parens.
And I've also run some tests, and determined that if I deliberately feed
jdbc_ExecQry a bad query that returns null instead of a result set, then
immediately feed it a good query, it does return a result set on the
good query.
--
JHHL
midrange.com
