Abstract: What is Redis CSRF vulnerability and how can we guarantee the security of Redis? Redis’s CSRF vulnerability was exposed in February 2017, and the author of Redis has fixed the vulnerability in the latest release of Redis 3.2.7. This article briefly introduces the concept of CSRF vulnerability and the best practices to keep Redis instances secure.
What is CSRF?
Cross-site request forgery (CSRF or XSRF), also known as “One Click Attack” or “Session Riding”, is a form of malicious website use.
The figure above shows a simple model of CSRF attacks. A user visits the malicious website Web B, which returns an HTTP message to the user asking the user to visit website Web A. If the user has set Web A as a trusted site, the access request will be executed as if the user sent the request on his/her own.
Redis CSRF Attack Model
Based on the principle of CSRF above, malicious websites may make a user send an HTTP request to Redis. Because Redis supports text protocols, and will not break off the connection in the case of illegal protocols during protocol resolution, the attacker can then add a Redis command after the normal HTTP request to execute the command on Redis. If the user and Redis do not use a password for verification, the Redis command will then be executed normally. The attacker can then encrypt data to extort money, just like the MongoDB ransom incident in January 2017.
Repairing the Kernel
The author of Redis fixed the problem in Redis v3.2.7, implementing special processing for the POST and Host: keywords, logging the events, and disconnecting to avoid execution of subsequent legal requests to Redis.
Redis Security Risks
Earlier, Redis exposed a security vulnerability that hackers may get the root permission of Redis services under certain conditions. The causes of these security vulnerabilities can be primarily attributed to users’ lack of use and understanding of Redis’s security mechanisms, as well as lack of Redis O&M experience. In comparison, Alibaba Cloud ApsaraDB for Redis provides more secure solutions for your on-cloud Redis services.
ApsaraDB for Redis Security Code
Intranet access to avoid Internet access
Alibaba Cloud ApsaraDB for Redis only provides trusted intranet access. You cannot access Alibaba Cloud ApsaraDB for Redis via the Internet.
Physical network isolation
Alibaba Cloud ApsaraDB for Redis’s physical network and user network are physically isolated. Users’ virtual machines are not allowed to directly access the backend physical machine network.
VPC network isolation
If you are an Alibaba Cloud user using the VPC network, only the services in the same VPC are inter-accessible.
Alibaba Cloud ApsaraDB for Redis supports whitelist settings. The feature is currently not available in the console yet. With this feature, you can set a whitelist for allowed users directly using the console.
Alibaba Cloud ApsaraDB for Redis enforces password authentication for instances in the classic network. You are recommended to set a complex password to prevent it from being cracked.
Access permission isolation
Each backend instance of Alibaba Cloud ApsaraDB for Redis is isolated in the ACL and accessible directory. Each instance is only allowed to access the path of its own instance so that inter-instance interference can be avoided.
Disabling dangerous commands
Alibaba Cloud ApsaraDB for Redis disables some dangerous system management commands such as “config” and “save”. If you want to modify this parameter, you need to pass the secondary authentication in the console. This also avoids direct operations on the backend configuration files and management commands.
Alibaba Cloud ApsaraDB for Redis has a complete security monitoring system for physical machines. It regularly scans and updates the security monitoring policies to discover security risks as soon as possible.
Redis cluster password
Native Redis 3.0 cluster version does not support password verification. Alibaba Cloud ApsaraDB for Redis cluster version supports password verification, which improves security.