SQL 注入 (SQLi) 是现存最危险和最常见的漏洞之一。然而，在过去几年中，由于易用性和可扩展性，NoSQL 数据库作为 Web 应用程序和分布式云平台的后端数据库越来越受欢迎。鉴于在这些 NoSQL（非 SQL/不仅是 SQL）数据库中不执行 SQL 查询，这是否意味着非 SQL 数据库不易受到注入攻击？抱歉不行。那么，如何防范NoSQL呢？让我们从 NoSQL 注入的概述开始。
什么是 NoSQL 注入？
NoSQL 数据库
NoSQL是一个广义术语，用于指代不使用 SQL 查询语言的非关系数据库/数据存储系统。一些示例包括 MongoDB、Cassandra DB、CouchDB 和 Riak。其中，MongoDB 是最受欢迎的数据库。
虽然 SQL 数据库存储在表中，但在非 SQL 数据存储系统中使用了更适合目的/上下文的多种数据模型。例如，对象、文档、图形、键值、列族等等。由于支持动态模式定义，因此可以根据敏捷开发周期轻松添加/修改新字段和数据，这与 SQL 数据库不同。
NoSQL注入
将恶意负载注入非 SQL 数据库（例如 MongoDB）的网络攻击称为 NoSQL 注入。
NoSQL 注入如何工作？
SQL 注入是在查询（尤其是来自用户的查询）未经过清理时引起的，允许攻击者修改数据库引擎以包含在数据库中执行命令的恶意输入。但是，SQLi 不能在非 SQL 数据库上执行，因为它们没有特定的语言。它们具有特定于产品的语法和查询语法，这些语法和查询语法是用应用程序语言本身编写的。
结果 ——NoSQL 数据库不仅可以被攻击者破坏，而且恶意代码/未经验证的输入可以在应用程序本身中执行。因此，DDoS 攻击可以被精心策划，或者服务器被接管或攻击者利用非 SQL 注入漏洞泄露机密用户信息。
在典型的 NoSQL 架构中，数据访问是通过驱动程序完成的。数据库客户端的多种语言库可通过驱动程序访问协议获得。考虑到驱动程序可能不易受攻击，但其中可能存在不安全的 API，如果开发人员不安全地实施这些 API，可能会导致在数据库和应用程序本身上执行任意代码。
让我们考虑一下 MongoDB 的例子。
- MongoDB 使用带有安全 BSON 查询组装工具的 BSON（二进制 JSON）数据格式。鉴于查询表示为 BSON 对象/二进制数据，直接注入是不可能的。
- 但是，应用程序可以在 MongoDB 的服务器上的组、$where 和 MapReduce操作中运行 JavaScript ，包括数据库中的潜在注入向量。
- 启用此功能后，开发人员必须确保用户无法提交恶意 JavaScript。
- 即使攻击者无法注入完全任意的代码，使用有限的函数集注入未经验证的输入也足以策划攻击。
例如：
下面的代码片段使用$where查询运算符检索名称为“Rafael Silver”的记录。
在这里，攻击者可以通过变量$userData插入未经过滤的用户输入
如果注入成功，他可能会注入字符串“a”；sleep (5000)进入变量$userData，这将通过服务器 5 秒——这足以让攻击者执行他需要的东西。
如何防止 NoSQL 注入？
1. 安全编码实践
不安全编码的风险加剧，因为这些数据库对于一些只熟悉 SQL 和关系数据库的开发人员来说仍然是新奇的。必须仔细通读 NoSQL 数据库的安全指南和手册。开发人员必须了解所使用的语言，以确保避免易受攻击的结构。
开发人员必须选择这些快速发展且年轻的数据库的最新可用版本。例如，流行的 MongoDB 的初始版本在多个层面的设计都是不安全的，导致致命的注入攻击，而最新版本在安全方面得到了加强。
2.输入验证
与 SQL 注入一样，在构建数据库查询时，必须避免在应用程序代码中使用未经过滤的用户输入。必须验证所有用户输入以确保不使用恶意值。虽然内置功能在非 SQL 数据库（如 MongoDB）中可用，以避免在数据库查询中使用 JavaScript，但如果 JavaScript 不可避免，则输入验证是必须的。
3. 最小权限策略
通常，在 Web 应用程序安全中，必须遵循最小权限原则。这样，在攻击成功的情况下，攻击者的影响范围就会受到限制。
结论
NoSQL ≠ 无注入攻击。非 SQL 数据库容易受到危险和破坏性的攻击，必须主动预防。即使在开发和部署过程中尽了最大努力，应用程序中仍可能存在漏洞，导致非 SQL 注入的风险增加。采用像AppTrana这样的全面、智能和托管的安全解决方案对于先发制人的攻击和加强应用程序安全性非常有价值。
