On Fri, Dec 11, 2009 at 7:03 PM, Petite Abeille
<petite.abei...@gmail.com> wrote:
>
> On Dec 11, 2009, at 9:55 PM, Paul Bohme wrote:
>
>> Not really. It's a simple fact that escaping user data into a SQL string is
>> using user input as executable. Can't do that in environments that I work
>> in. If it were that easy, we wouldn't still be playing an eternal game of
>> whack-a-mole with SQL injection attacks everywhere.
>
> Hmmm... heard good thing about schema and access right... after all, if the
> schema used to access you data can one perform a select... SQL injection
> become irrelevant, no? In other words, it seems a bit pointless to try to
> secure every single random client access, when one can (and should) instead
> secure the database itself.
It is not that simple. Whilst you can enforce the restriction of not
being able to change the database schema, a malicious user would still
be able to forge an attack seeking an otherwise inaccessible data.
Consider:
--*--
local sql = 'update users set some_attribute = "%s" where username="%s"'
local user_input = {}
user_input.username = 'malicious_user'
user_input.some_attribute =[[" || (select list(email) from users) || "]]
db:execute( string.format( sql, user_input.some_attribute,
user_input.username ) )
--*--
And there you go: full access to the system data. Now imagine what you
can do with the where clause (delete from ... where 1=1)
--rb
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
