On Dec 11, 2009, at 10:33 PM, Romulo wrote:
> 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.
Hmmm... I guess it's getting late for me, but... I'm not quite sure how trying
to address any of these issues on the client side is going to help you out.
(1) Use proper database level security (schemes, grants, etc)
(2) Shared accounts (aka application accounts) are a recipe for disaster
In general, use the database level mechanism which already address these
issues. Reimplementing pseudo access control on the client side is not going to
be of much help.
> Now imagine what you
> can do with the where clause (delete from ... where 1=1)
Well, if the authenticated database session doesn't have grants to
delete/update/insert/execute anything, then... the DDL generated by the client
is rather irrelevant, no?
For example, Exploits of a Mom, is self inflicted pain:
http://xkcd.com/327/
And yes, securing a database if more than simply "sanitizing database input".
While database centric development is not very glamourous those days, there is
a lot to learn from it:
http://thehelsinkideclaration.blogspot.com/2009/03/helsinki-declaration-observation-1.html
In any case, we are getting carried away from LuaSQL proper, so lets move on :)
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
