一个容易被忽略的赏金来源，带你玩转NoSQL注入

原创

升斗安全XiuXiu
升斗安全XiuXiu

升斗安全

2026年7月28日 08:36
广东

在小说阅读器读本章

去阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

我们今天来扒一扒NoSQL注入那点事儿。很多刚入坑赏金猎人的兄弟总觉得注入就是SQL的专利，其实不然，NoSQL这潭水，也深得很。

NoSQL注入的两副面孔

说白了，NoSQL注入就两种玩法：

第一种，语法注入。这跟咱们熟悉的SQL注入思路差不多，就是想办法把你自己的“私货”塞进原本的查询语句里，破坏它的结构。但别高兴太早，因为NoSQL数据库用的查询语言五花八门，语法结构也千奇百怪，攻击手法自然也就跟着变了，没法完全照搬老一套。

第二种，操作符注入。这种更直接，利用的是NoSQL查询本身的操作符来搞事情。好比别人给你一把钥匙，本来是开一扇门的，结果你发现这把钥匙能开整栋楼所有的锁。

下面咱们就说说，怎么把这些漏洞给揪出来。后面我会拿用得最多的MongoDB来举例，带大家感受一下真实的攻防场景。

怎么抓“语法注入”

测试方法其实不复杂：系统性地往每个输入点里扔一些奇奇怪怪的字符串和特殊符号，看看应用程序会不会“变脸”，比如报错、返回不同的结果，那就说明用户输入的东西可能没被清理干净，直接拼进了查询里。

如果你摸清了后端用的是什么数据库，那就用那种数据库的“方言”去搞。如果不知道，那就撒大网，用各种通用的模糊测试字符串去试探。

举个MongoDB的实战例子

想象一个购物网站，你可以按类别浏览商品。当你点击“汽水”时，浏览器地址栏会变成这样：

https://insecure-website.com/product/lookup?category=fizzy

后台呢，会生成一个MongoDB的查询，去“product”集合里找东西，大概长这样：

this.category == 'fizzy'

那我们怎么测呢？直接把category参数的值换成一个模糊测试字符串，比如MongoDB专用的：

• '\"{
• ;Foo} Foo \xYZ``

构造好的完整攻击请求长这样（别被吓到，就是URL编码了一下）：

https://insecure-website.com/product/lookup?category='%22%60%7b%0d%0a%3b%24Foo%7d%0d%0a%24Foo%20%5cxYZ%00

如果页面返回的内容跟正常访问时不一样，那恭喜你，很可能有戏。这说明用户输入可能被原封不动地解析了。

提醒一句：

NoSQL注入藏身的地方可能千奇百怪，你得根据实际情况调整手里的“探针”字符串。要是随便丢个东西进去，很可能只触发了前端验证，后端压根没执行你的查询，那就白忙活了。

像刚才的例子，是通过URL传参，所以得URL编码。要是换成JSON格式的参数，你的测试字符串就得变成这样：`'\"{\r;Foo}\
Foo \xYZ\u0000``

总之，灵活应变是咱赏金猎人的基本功。

看完觉得有收获的老铁，别光顾着收藏，点个赞、点个推荐，让更多挖洞的兄弟看到。觉得以后用得上，转发到你的小圈子，一起交流心得。还没关注的，赶紧点个关注不迷路，后续我会持续分享一线的挖洞技巧和硬核案例！