lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hash: SHA1

On 10/03/10 19:57, Jorge wrote:
> "The vulnerability is present when user input is either incorrectly
> filtered for string literal escape characters embedded in SQL statements
> or user input is not strongly typed and thereby unexpectedly executed.
> It is an instance of a more general class of vulnerabilities that can
> occur whenever one programming or scripting language is embedded inside
> another."

Yeah, this is very misleading.

SQL injection is an *output* problem, usually caused by mixing
user-supplied data with executable SQL code in the same string.

Any sane SQL library should provide query formatters to avoid this. So
instead of:

SQL("SELECT foo FROM thing WHERE field = " .. value) do this:

SQL("SELECT foo FROM thing WHERE field = ?", value)

The SQL library will compile the query and replace the ? placeholder
with a reference to the value. Your data and your code are completely
separate, therefore no SQL injection can ever happen. (The placeholder
is replaced at the bytecode stage, after compilation happens.)

The short version is: SQL queries should *always* be constant strings.
If you have to construct your queries from stringops, something is wrong.

This is something that should be hammered home in every SQL text ever,
but there's still a lot of docs (such as the wiki you quote) which still
don't get it right, with the result that SQL injection just will not go
away, despite being very easy to fix. (I invite you to search for 'sql injection' and shudder.)

Why yes, I *was* bitten by this when I wrote a program that used SQL;
how ever did you guess?

- -- 
┌─── ───── ─────
│ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚
│ 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓.
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -