Redis注入攻击到底是谁在搞事，背后真相你可能没想过

说到网络攻击,大家可能更熟悉SQL注入或者跨站脚本，但“Redis注入攻击”这个词听起来就有点陌生，甚至会觉得是不是搞错了，Redis不是一个很快的内存数据库吗？它又不是传统的关系型数据库，怎么也会被注入？这正是问题的关键所在，我们都忽略了它，但搞事的人可没有。

要弄清楚是谁在搞事,我们先得明白Redis在当今互联网里扮演的角色，根据多位资深运维工程师在技术社区如知乎和CSDN上的分享，Redis早就不是简单的缓存工具了，它因为速度快，经常被用来做缓存、会话存储，甚至在一些场景下被当作轻量级的消息队列或主数据库来用，更重要的是，很多开发者为了方便，会用Redis来存储一些敏感信息，比如用户的会话数据、临时的验证码，甚至是经过序列化的用户对象。

攻击者是怎么“注入”的呢？这里的“注入”和SQL注入的逻辑不太一样，但目的一样：操控数据，网络安全研究者“道哥”在其公众号文章中曾点明，Redis注入攻击的核心往往不是攻击Redis服务器本身的一个漏洞，而是利用了应用程序与Redis交互方式的不安全。

搞事的第一类人,是那些专门寻找“配置错误”的扫描者，很多开发者或运维人员可能因为疏忽，将Redis服务暴露在公网上，并且没有设置密码认证，或者使用了极其简单的密码，这就好比把家里的金库大门敞开，还贴了个“欢迎光临”的纸条，攻击者利用自动化工具，在全球范围内扫描这些暴露的Redis服务，一旦发现，他们就能直接连上去，为所欲为，他们可能干些什么呢？一位名叫“余弦”的安全专家在FreeBuf上提到，一种常见的搞事手法是“数据污染”，攻击者会向你的Redis里写入一些恶意的键值对，比如篡改会话信息，把一个普通用户的权限提升为管理员，下次这个用户登录时，应用程序从Redis读取了被篡改的会话，攻击就成功了，这就像是在你的仓库里，偷偷把货物标签换掉，让你自己把危险品当成宝贝运出去。

更绝的是,如果Redis是以高权限运行的，攻击者甚至能通过Redis的配置命令，将内存中的数据写入服务器磁盘的任意位置，比如写入一个SSH公钥，从而直接获取服务器的root权限，这种攻击方式在几年前曾导致多起严重的服务器沦陷事件。

搞事的第二类人,则更狡猾一些，他们针对的是应用程序处理用户输入的逻辑缺陷，举个例子，一个网站使用Redis来存储商品信息和用户搜索记录，前端用户输入一个商品关键词，手机”，后端程序可能会直接拼接成一个Redis命令，如KEYS *手机*来模糊查询，如果程序没有对用户输入进行严格的过滤，攻击者输入的就不是“手机”，而是一段精心构造的字符串，手机* COMMAND FLUSHALL”，如果后端程序傻乎乎地直接执行了拼接后的命令，就可能变成先执行一个查询，然后紧接着执行了FLUSHALL这个可怕命令——它会清空整个Redis数据库，这就好比你去问图书馆管理员找一本书，但你的问话里藏着一句咒语，让管理员听完后把整个图书馆的书都烧了，这种攻击就是典型的“命令注入”。

是谁制造了这些搞事的机会？追根溯源，真相可能有点让人难以接受：很大程度上是我们开发者自己，浙江大学VLIS实验室发表的《NoSQL数据库安全技术综述》一文中指出，NoSQL的灵活性和易用性让开发变得快速，但很多开发者却放松了对安全性的警惕，将传统数据库时代积累下来的安全最佳实践抛在了脑后，忽视输入验证、使用默认配置、盲目信任客户端传来的数据。

“Redis注入攻击”背后搞事的，一方面是那些无孔不入、利用自动化工具寻找弱点的攻击者，但另一方面，也是由于开发者和运维人员的疏忽，无意中为攻击者打开了方便之门，真相就是，安全是一个链条，任何一个环节的松懈，都会成为攻击者搞事的突破口，当我们把Redis这样强大的工具用于关键业务时，就必须用同样严格的安全标准去对待它，不能再抱有“它很安全”的侥幸心理。