This topic describes how the Redis CSRF vulnerability occurs and the security measures available for ApsaraDB for Redis.
Cross-site request forgery (CSRF), also known as One Click Attack or Session Riding, is abbreviated as CSRF or XSRF and is a malicious use of websites.
The preceding figure shows a simplified model of a CSRF attack: You visit a malicious website B. The HTTP information returned by malicious website B requires you to visit website A. However, due to a possible trust relationship between you and website A, this request is executed like what you actually sent.
Redis CSRF attack model
Based on the preceding model of CSRF, a malicious website can require you to send an HTTP request to a Redis instance. Redis supports the text-based protocol. If Redis parses an illegal protocol, it will not disconnect from the connection. At this time, the attacker is able to send Redis commands carried by a valid HTTP request and execute them on Redis. If no password verification is required between you and the Redis instance, the Redis commands can be executed and the data is encrypted for ransom. This is similar to the MongoDB ransomware attack event.
The Redis author fixed this issue in version 3.2.7. The solution is to log statement
execution with keywords
Host: and disconnect from the connection to avoid executing subsequent Redis legal requests.
Redis security risk
In earlier versions, Redis exposed a security vulnerability. Hackers can obtain the root privileges of the Redis service under specific conditions. The main reason for this security vulnerability is that users do not know much about the security mechanism of Redis and are inexperienced in Redis operations and maintenance. At the same time, Redis does not provide robust security protection mechanisms. ApsaraDB for Redis provides more secure Redis services. We recommend that you use ApsaraDB for Redis as your Redis services in the cloud.
Security policies of ApsaraDB for Redis
Support internal access instead of access from the Internet
ApsaraDB for Redis provides trusted internal access. You cannot directly access ApsaraDB for Redis from the Internet if you do not apply for a public endpoint.
Physical network isolation
The network where ApsaraDB for Redis instances are deployed are physically isolated from the network from which you want to access ApsaraDB for Redis instances. You cannot directly access the network of backend servers.
Support VPC for network isolation
If you are an Alibaba Cloud user and deploy a virtual private cloud (VPC) to connect your services, only the services in the same VPC can access each other.
ApsaraDB for Redis supports whitelist settings. You can configure a whitelist of IP addresses that can be used to access ApsaraDB for Redis instances in the ApsaraDB for Redis console.
ApsaraDB for Redis forcibly enables password authentication for instances deployed in a classic network. You can set a complex password to avoid password cracking.
ApsaraDB for Redis isolates each instance at the backend based on permission settings and file directories. Each instance can access only its own path. This avoids mutual effects among instances.
Disable Risky commands
ApsaraDB for Redis disables some risky system management commands such as config and save. To modify parameters, you must perform two-factor authentication in the ApsaraDB for Redis console. This also avoids direct operations on the backend configuration files and management commands.
ApsaraDB for Redis features comprehensive security monitoring for physical machines, regular scanning and updated security monitoring policies, and can detect security risks in early stages.
Password authentication for cluster instances of ApsaraDB for Redis
The cluster version of Redis 3.0 does not support password authentication. Cluster instances of ApsaraDB for Redis support password authentication. This improves security performance.