Redis如何处理恶意用户构造无效查询参数的穿透-Redis-PHP中文网

Redis不解析查询参数，穿透问题源于业务层未校验用户输入；需白名单校验键名、空值缓存+布隆过滤器防穿透、禁用高危命令并监控异常行为。

redis如何处理恶意用户构造无效查询参数的穿透

Redis本身不解析查询参数，穿透问题出在业务层

Redis 是一个键值存储，它不理解“参数”“查询”这些概念——GET、HGET、LRANGE 等命令只认键名和固定数量的参数。所谓“恶意构造无效查询参数导致穿透”，实际是上层应用（比如用 redis-py 或 Node.js 的 ioredis）把用户输入直接拼进命令，没校验、没过滤，结果查了不存在的键，又没设缓存，流量直冲下游数据库。

关键点在于：Redis 不会“被穿透”，它只是忠实地执行你发过去的命令；真正被穿透的是你的缓存策略和业务逻辑。

用户输入进 Redis 命令前必须做白名单校验

常见错误是用用户传来的 user_id 直接拼成 user:profile:{user_id}，但没检查 user_id 是否为数字、长度是否合理、是否含冒号或空格等非法字符。一旦攻击者传 user_id=123; DROP TABLE users;（虽然 Redis 不执行 SQL，但若后续拼到 SQL 里就完了），或者传超长字符串触发 OOM，风险就来了。

对所有用户输入的键名片段，用正则严格限制：只允许字母、数字、下划线、短横线，且长度 ≤ 64 字符（^[a-zA-Z0-9_-]{1,64}$）
禁止拼接任意用户输入到键名中；优先用哈希后缀（如 user:profile: + hashlib.md5(user_id.encode()).hexdigest()[:16]）
若必须保留可读键名（如 order:20240517123456），则对时间戳+订单号做格式校验，拒绝非数字、位数不符、日期明显异常的输入

空值缓存 + 布隆过滤器防穿透要配对用

单纯设空值缓存（SET user:profile:999999 "" EX 60）能挡住重复请求，但挡不住海量随机 key 扫描（比如 user:profile:1 到 user:profile:9999999）。这时候布隆过滤器（Bloom Filter）才起作用——它提前告诉你“这个 key 绝对不存在”，不用查 Redis 也不查 DB。

布隆过滤器必须由写入方维护：每次成功写入一个有效 user:profile:{id}，就往过滤器里 add(id)
读取前先 contains(user_id)，返回 false 就直接返回 404，不碰 Redis
不要用 Redis 自带的 BF.RESERVE 做线上主过滤器——它的误判率不可控，且扩容麻烦；推荐用客户端侧轻量实现（如 Python 的 pybloom_live）或独立服务（如 Bitcask + Bloom）
空值缓存 TTL 要比正常缓存短（比如 2 分钟 vs 30 分钟），避免脏数据长期滞留

用 Redis 的 RESP 协议特性识别异常命令模式

有些穿透不是来自业务逻辑漏洞，而是攻击者绕过应用层，直连 Redis 发畸形命令，比如超长 key、嵌套过深的 EVAL 脚本、大量 KEYS * 扫描。Redis 本身虽不鉴权，但可通过配置和监控拦住一部分。

禁用高危命令：在 redis.conf 中加 rename-command KEYS ""、rename-command FLUSHDB ""、rename-command EVAL ""
限制单个命令最大参数个数：通过 maxmemory 和 maxmemory-policy 防 OOM，但更直接的是用代理层（如 Twemproxy 或 redis-exporter + Prometheus alert）检测 command_calls_total{cmd=~"get|hget|lrange"} > 10000 这类突增
开启慢日志：slowlog-log-slower-than 10000（单位微秒），定期抓取 SLOWLOG GET 10，看是否有 GET 命令耗时异常——往往意味着 key 不存在且后端 DB 查询卡住了