网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

　　译者 | 李睿

　　数据库在Web应用程序中存储和组织数据时起着至关重要的作用，它是存储用户信息、内容和其他应用程序数据的中央存储库。而数据库实现了高效的数据检索、操作和管理，使Web应用程序能够向用户提供动态和个性化的内容。然而，数据库和网络应用程序之间的通信不畅可能会导致敏感数据泄露、用户不信任、法律后果和利润损失。本文将探讨导致此类灾难的后端错误配置，并了解如何确保应用程序的安全。

　　什么是SQL注入?

　　SQL注入(SQLi)是一个漏洞，它允许网络攻击者篡改Web应用程序发送给数据库的查询。当应用程序误解了用户的输入并将其视为SQL代码而不是字符串时，就会发生注入。因此，恶意用户可以更改预期的查询流，破坏应用程序的逻辑，并获得对其资源的未经授权的访问。

　　在大多数情况下，当开发人员需要使用依赖于用户输入的参数化查询时，就会出现SQLi。如果开发人员在将用户输入插入模板之前忘记对其进行适当的清理，就会引入SQL注入漏洞。一个经典的SQL注入示例是使用纯字符串插值或连接来创建动态查询，如下图所示。网络攻击者可以通过用SQL代码替换分页参数中的数字来注入任意SQL语句。

　　动态查询精心制作的字符串插值

　　什么是ORM注入?

　　现在，开发人员很少使用原始SQL语句，而是使用称为ORM的特殊框架。对象关系映射(ORM)是一种用作两种不同范例之间的适配器的技术：关系(将数据存储在表中)和面向对象(将数据存储在对象中)。ORM所做的事情之一是在底层生成SQL代码。开发人员所要做的就是告诉ORM如何去做。

　　显然，自动生成意味着自动转义用户提供的数据。ORM确保每个动态参数都像普通字符串一样被处理，除非开发人员特别禁用清理功能。然而，恶意代码的注入仍然是可能的。ORM注入是一个漏洞，它允许密切协作攻击者强制ORM生成对他们有利的SQL。

　　考虑下面的例子。这里有一个函数，它应该接受带有多个参数的对象过滤器，例如:

　　复制

　　{"email":, ""name": "user"}

　　ORM注入

　　但是，开发人员忘记检查过滤器是否确实是一个对象，以及它是否只包含安全的过滤参数。这样的错误使攻击者能够注入可用于恢复用户密码的恶意过滤器，例如：

　　"password LIKE '%a%'"

　　SQL注入真的很危险吗?

　　通常，SQL注入可以被认为是一个严重的漏洞。在大多数情况下，对网站任何部分的单个SQL注入最终都可以扩展到在数据库上运行任何查询，提取和操作其数据。由于数据库通常保存着系统中最敏感的信息，因此允许网络攻击者访问这些信息是毁灭性的。

　　以下是SQL注入如何被利用的简短列表：

　　远程代码执行(通常通过特殊功能)

　　读写主机上的文件。

　　颠覆Web应用程序的逻辑

　　提取敏感数据

　　操纵数据

　　拒绝服务

　　哪些类型的SQL注入是可能的?

　　在通常情况下，有三种类型的SQL注入：带内注入、带外注入和盲注入。反过来，带内攻击可以是基于联合的或基于错误的，而盲SQLi可以是基于布尔的或基于时间的。

　　SQL注入层次结构

　　如果攻击者足够幸运，他们可以在后端响应中包含被破坏的SQL查询的结果。这被称为带内SQLi。带内SQLi有两种子类型：

　　1.基于联合的SQLi：攻击者能够指定他们可以读取的查询输出的位置(列)。

　　2.基于错误的SQLi：当应用程序公开SQL/编程语言错误时，这种类型的SQLi是可能的。在这种情况下，攻击者可以分析错误消息/堆栈跟踪，并推断攻击是否成功。

　　使用BlindSQLi，网络攻击者无法看到被破坏的SQL查询的结果。然而，它们有某种反馈，可以帮助确定是否存在注入。盲SQLi有两种子类型：

　　1.基于布尔的SQL：攻击者可以使用SQL条件语句以某种方式修改服务器的响应。然后，他们可以将这种新的反应与原来的反应进行比较，并确定注入是否有效。

　　2.基于时间的SQLi：攻击者可以将数据库的SLEEP函数与条件语句结合起来，从而延迟后端响应。然后，他们可以将原始响应时间与新的响应时间进行比较，以确定注入是否成功。