This topic describes the cross-site request forgery (CSRF) vulnerability in Redis and the security policies of Tair (Redis OSS-compatible).
How CSRF works
Cross-site request forgery (CSRF), also known as One Click Attack or Session Riding, is a class of attack where a malicious site tricks a user's browser into sending a request to a trusted site on the user's behalf.
In the simplified model above, a user visits malicious website B. Website A responds with content that causes the user's browser to send an HTTP request to website B. Because website B trusts the user, it processes the request as if the user initiated it directly.
Redis CSRF attack model
Redis is particularly vulnerable to CSRF because of how it handles its text-based protocol. When Redis encounters malformed protocol data during parsing, it does not automatically close the connection. An attacker can exploit this by appending Redis commands to a legitimate HTTP request. If no password authentication is configured, those commands execute directly on the Redis server.
Attackers use this technique to encrypt data stored in Redis and demand a ransom — a pattern similar to earlier ransomware attacks that targeted MongoDB.
Kernel fix in Redis 3.2.7
Redis 3.2.7 addresses this vulnerability by detecting HTTP-style input: if Redis encounters statements containing the POST and Host: keywords during protocol parsing, it logs the event and closes the connection immediately, preventing any subsequent commands from running.
Security risks in earlier Redis versions
Earlier versions of Redis expose a vulnerability that can allow attackers to gain root privileges of the Redis service under specific conditions. The root causes are:
Insufficient understanding of Redis security assumptions among operators
Lack of operations and maintenance experience with Redis
Limited built-in security protection mechanisms in Redis itself
Security policies of Tair (Redis OSS-compatible)
Redis was designed to run inside a trusted network, accessed only by trusted clients. Exposing a Redis instance directly to the internet — or to any environment where untrusted clients can reach its TCP port — creates significant risk. Tair (Redis OSS-compatible) enforces this security model through multiple layers of protection, some enabled by default and others that you configure.
Network isolation (always on)
Tair instances run on an internal network and are not accessible from the internet by default. You must explicitly apply for a public endpoint to expose an instance externally. The network where Tair instances are deployed is physically isolated from external access networks, so backend servers are never directly reachable.
VPC isolation (always on for VPC deployments)
If your services run inside a virtual private cloud (VPC), only resources within the same VPC can access your Tair instance. Traffic from outside the VPC is blocked automatically.
IP whitelists (requires configuration)
Configure an IP whitelist in the console to restrict which IP addresses can connect to a Tair instance. Only addresses on the whitelist are allowed through.
Password authentication (always on for classic network instances)
Tair requires password authentication for all instances deployed in the classic network. Use a complex password to reduce the risk of password cracking.
Password authentication for cluster instances (always on)
Native Redis 3.0 clusters do not support password authentication. Tair cluster instances support password authentication by default, adding access control to cluster deployments.
Permission isolation (always on)
Each backend Tair instance operates with isolated permissions and its own set of accessible directories. Instances access resources only through their own paths, preventing interference between instances.
High-risk command restrictions (always on)
Tair disables high-risk system management commands such as config and save. To modify instance parameters, use two-factor authentication in the console instead of issuing commands directly. This protects backend configuration files from unauthorized changes.
Security monitoring (always on)
Tair continuously monitors physical machines for security anomalies, runs regular scans, and updates security monitoring policies to detect risks early.