> 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,'bar')" 1 foo
What is our recommendation for such a use case? The following come to my
a) Simply do NOT pass dynamic values to eval
-- or --
b) Abuse the KEYS, 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 /
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.
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en