Re: string:sub

[joao lobato <btnfdp.lobato@...>]

Absolutely. Every "complaint" listed about string.sub should be
addressed in application code rather than changing the standard lib.

On 3/11/10, Eike Decker <zet23t@googlemail.com> wrote:
> I think this is going too much off topic. I think Roberto made the
> point pretty clear when writing
>
>> At any position i, you need the index (i - 1) to get the empty string.
>> For i > 1 this is not a problem, but for i==1 you need the index 0.
>
> ... why 0 is a valid value to pass to string.sub.
> I don't see any problem with the string.sub implementation the way it is.
>
> Eike
>
> 2010/3/10 David Given <dg@cowlark.com>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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)
>>
>> ...you 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
>> TheDailyWTF.com 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?
>>
>> - --
>> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
>> │
>> │ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚
>> │ 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iD8DBQFLmAbpf9E0noFvlzgRAltrAKDF6dAYAyWXxKp1W1TPpv7E+ECy7wCcDJxF
>> Qp06/0CtUcElemETSpSzxBs=
>> =sqPo
>> -----END PGP SIGNATURE-----
>>
>