Introduction
In this article, we will discuss security from the point of view of Redis. It goes through Redis' access control, code security problems, attacks that can be launched from the outside by picking malicious inputs, and other related subjects.
Security model
Redis is intended for use by trusted clients in trusted environments. Clients in the front-end (web side) of a web application that uses Redis as a database, cache, or messaging system will query Redis to generate pages or perform activities requested or triggered by the web application user.
In this situation, the web application mediates access between Redis and untrusted clients (the user browsers accessing the web application).
Untrusted access to Redis should always be mediated through a layer that implements ACLs, validates user input, and decides what actions to do on the Redis instance.
Network security
Everyone but trustworthy clients in the network should have access to the Redis port; hence the servers hosting Redis should be directly accessible only by the computers implementing the Redis application.
The Redis port should be firewalled to prohibit access from the outside in the typical case of a single computer directly exposed to the internet, such as a virtualized Linux instance (Linode, EC2,...) Redis will still be accessible via the loopback interface for clients.
It's worth noting that you can bind Redis to a single interface by adding the following line to the redis.conf file:
bind 127.0.0.1Because of the nature of Redis, failing to protect the port from the outside can have a significant security impact. An external attacker might, for example, destroy the entire data set with a single FLUSHALL command.
Protected mode
Unfortunately, many users do not secure Redis instances against external network access. Many instances are just left online with public IP addresses. When Redis is run with the default configuration (binding all interfaces) and no password, it enters a special mode known as a protected mode. Redis only responds to queries from loopback interfaces in this mode, and clients connecting from other addresses receive an error message explaining the problem and how to configure Redis correctly.
We anticipate that the protected mode will significantly reduce the security risks associated with unprotected Redis instances that are run without proper administration.
However, the system administrator can ignore Redis' error and disable protected mode or manually bind all interfaces.
Authentication
While Redis does not attempt to provide Access Control, it does offer an optional layer of authentication that can be enabled by modifying the redis.conf file.
When the permission layer is enabled, unauthenticated clients will be denied access to Redis. By delivering the AUTH instruction followed by the password, a client can authenticate itself.
The password is set in clear text in the redis.conf file by the system administrator. It should be long enough to prevent brute force attacks for two reasons:
Redis responds to queries quickly. An external client can test a large number of passwords per second.
The password for Redis is saved in the redis.conf file and the client configuration. The password can be very long because the system administrator does not need to remember it.
The authentication layer's objective is to provide an optional layer of redundancy. An external client will still be unable to access the Redis instance without knowing the authentication password if firewalling or any other method established to protect Redis from external attackers fails.
Because the AUTH command, like all other Redis commands, is sent unencrypted, it is vulnerable to eavesdropping by an attacker with sufficient network access.
TLS support
TLS support is available for all communication channels in Redis, including client connections, replication links, and the Redis Cluster bus protocol.
Disallowing specific commands
It is possible to disable commands in Redis or rename them with an unguessable name, limiting typical clients to a limited number of instructions.
A managed Redis instance service, for example, could be offered by a virtualized server provider. In this case, normal users should generally not be able to change the instance's settings using the Redis CONFIG command, but systems that give and remove instances should be able to.
In this circumstance, it is possible to rename or shadow commands from the command table. A statement in the redis can access this feature.conf configuration file. For instance:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52The CONFIG command was renamed to an unguessable name in the preceding example. It's also possible to make it (or any other command) utterly unusable by renaming it to the empty string, as in the following example:
rename-command CONFIG ""Attacks triggered by malicious inputs from external clients
An attacker can launch a particular type of attack from the outside, even if they don't have access to the instance. An attacker could, for example, inject data into Redis that causes pathological (worst-case) algorithm complexity on data structures defined within Redis internals.
An attacker could use a web form to submit a series of strings that are known to hash to the same bucket in a hash table, causing the O(1) expected time (average time) to become the O(N) worst case. This may require more CPU than anticipated, resulting in a Denial of Service.
Redis uses a per-execution, pseudo-random seed, to the hash function to prevent this specific attack.
String escaping and NoSQL injection
Because the Redis protocol has no concept of string escaping, injection is impossible using a standard client library. The protocol is binary-safe and uses prefixed-length strings.
The EVAL and EVALSHA commands are also safe because the Lua scripts they execute obey the same rules.
While it may seem unusual, the application should avoid assembling the Lua script's body with strings obtained from untrustworthy sources.
Code security
Clients have complete access to the command set in a traditional Redis setup, but accessing the instance should never result in the ability to influence the system where Redis is executing.
To prevent buffer overflows, format problems, and other memory corruption issues, Redis employs all of the well-known techniques for building secure code. The ability to manage the server settings using the CONFIG command, on the other hand, allows the client to change the program's working directory and the name of the dump file. Clients can now write RDB Redis files to whatever directory they choose. This is a security vulnerability that could allow an attacker to compromise the system or run untrusted programs as the same user as Redis.
34+ registered 
