> If we want to argue serious stuff we should take this in mind:
> 1) in SQL you need to quote values, so "normal" users simply using the
> default API that most SQL client libs provided (in the past at least)
> were adding security
> issues all around the code. Similarly in C if you don't pay explicit
> attention you'll cause a buffer overflow, and so forth.
> 2) In Redis there is no way to "quote" a value, it's not needed, there
> is no injection. The proposed case is the same of as if in an SQL
> application I create *my stored procedure* using user provided input.
> So it's not the same at all.
I agree that the normal Redis protocol is not vulnerable to injection, and
that escaping strings is not required for the normal commands.
I am specifically speaking about the eval use case, where the lua script is
evaluated directly on the server side. This lua script *completely
bypasses*the redis client library, the redis wire protocol and the
redis server - so
there is no chance for any of those layers to prevent injection (again, I
am not saying these layers should prevent injection).
Lets say a developer wants to pass a dynamic value to the lua script. In
the example below (picked from the docs), lets say the string *bar* is a
dynamic, end user provided string.
eval "return redis.call('set',KEYS[1],'bar')" 1 foo
What is our recommendation for such a use case? The following come to my
mind :
a) Simply do NOT pass dynamic values to eval
-- or --
b) Abuse the KEYS[2], even though *bar* isn't a key. This will confuse the
redis client libraries who expect the parameters to be keys that they can
interpret in case of a cluster.
-- or --
c) Learn how to escape lua strings, and to do it correctly
I am not saying Redis should introduce any more bells and whistles. But we
should at least document the preferred way of solving this on the wiki /
faq's.
--Sri
On 29 February 2012 22:56, Daniel Schnell <210...@googlemail.com> wrote:
> > That's a design choice, and ultimately Antirez's call.
> > My point of view is that if you design a gun and you let
> > "won't let stupid people who try to shoot their feet get hurt"
> > in the list of requirements, you won't make a very good gun.
> With Redis beeing the new kid on the block and its boosting popularity you
> have to anticipate people that want to use it for all kind of things that
> you probably think as of "stupid". But these people are not necessarily
> "stupid" but have a different anticipation or background. I would like that
> the notion of remarks about "stupid" people would change to a more
> respectful treatment here on this forum.
> What I can see from this thread (>30 posts now) is that there should be a
> FAQ entry on the Redis home page for what Redis should not be used for or
> what the security design - or lack of - is, because that is clearly missing.
> Regards,
> Daniel.
> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To post to this group, send email to redis-db@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redis-db@googlegroups.com.
To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/redis-db?hl=en.
