Is it possible to launch a string injection attack for a redis query?

Question

I am creating a small token authentication library for my (rails-based) api server that uses redis to store the generated auth tokens. The line I'm worried about is: user_id = $redis.get("auth:#{token}") , where the token is what the authentication_or_request_with_http_token is passed to.

If it were SQL, it would be a huge red flag. String interpolated SQL queries are pretty unsafe. However, as far as I can tell, performing string interpolation on request of a redis key is unsafe.

My source for the above statement is the redis documentation here: http://redis.io/topics/security (under the escaping and nosql injection header line headings), but I wanted to make sure this is the case before I get the Bobby Tables attack.

Answer 1

The documentation you are pointing to is pretty clear:

There is no concept of string escaping in the Redis protocol, so under normal conditions injection is not possible using a regular client library. The protocol uses strings with a length prefix and is completely binary.

Answer 2

There is a small attack vector for these types of string injections. Although the redis documentation clearly states that it is difficult to execute several commands in the database, it does not mention that the key separator (':' in your example) should usually be escaped when used as part of a key.

I saw the redis database using these keys:

• oauth_token:123456 (which contains the hash of the OAuth token parameters) and
• oauth_token:123456:is_temp (containing a boolean property indicating whether the OAuth token is a temporary token)

Trusting the user’s input without escaping, it may result in a GET oauth_token:#{token} , accidentally ending as a GET oauth_token:123456:is_temp (when the token was set by the user 123456:is_temp ).

Therefore, I highly recommend that you properly hide colons from potential user input to make sure your key paths cannot be tricked as follows.

NOTE. . Someone recommended to fix the example above with oauth_token:123456 and oauth_token:is_temp:123456 , but this is incorrect (for the user-supplied token is_temp:123456 ). The correct solution to this problem (without escaping) would be to use the keys oauth_token:info:123456 and oauth_token:is_temp:123456 to make sure that these keys cannot intersect with the content provided by the user (or simply display a colon).

Answer 3

Basically, Redis is not immune to escaping issues when the input line is used verbatim. For example:

 SET mykey <some-attacker-chosen-data> 

However, Redis is not immune to problems arising from the use of invalid input in the context of string interpolation, as Sven Herzberg has shown. To make Sven's example safe, you can simply use the hash and avoid a return to interpolation. Otherwise, use either non-common prefixes to use in combination with key interpolation, or use some basic form of health check on an input that filters out the separator used or better, confirm that the input is actually a number (in a specific example).

So, while Redis does not suffer from typical SQL attack attacks, when you use untrusted input in the context of string interpolation, used to create key names or, even worse, Lua scripts, some caution should be exercised.