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 ((')
+ %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.


Return to Archive home page | Return to MIDRANGE.COM home page