强加密算法下，SQL注入案例

密码学具有各种优点，包括信息的机密性。然而，过度依赖密码学来保护应用程序是一个坏主意。今天我们就通过一个案例研究，来认识一下通过加密的有效载荷识别和利用 SQL 注入漏洞。

SQL注入也许很多人都知道或者使用过，如果没有了解或完全没有听过也没有关系，因为接下来我们将介绍SQL Injection。

SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

具体来说，它是利用现有应用程序，将恶意的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入恶意SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

那SQL注入会在什么时候发生呢？

假设我们在浏览器中输入URL www.sample.com，由于它只是对页面的简单请求无需对数据库动进行动态请求，所以它不存在SQL Injection，当我们输入www.sample.com?testid=23时，我们在URL中传递变量testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中?testid＝23表示数据库查询变量），所以我们可以在该URL中嵌入恶意SQL语句。

不过要提前说明一下，我们不会在本文中讨论加密问题，而是只讨论应用程序缺陷，我们会先生成加密的有效载荷，然后将其用于识别和利用SQL注入。

在最近我们接触到的一个电子商务应用程序中，观察了该网站的大多数请求参数值已被加密。当请求参数被加密时，很难对应用程序进行模糊测试，除非我们可以去除加密，不过这需要知道密钥和加密算法。

下图就是我们所找的样本网站的详细信息页面，该页面就是以加密格式发送id（orderid）参数的。

注意：参数值（BDKfx3xNKsc =）是加密的，而不是简单的base64编码。ID参数的加密值以base64编码格式表示。

我们还注意到，如果我们退出应用程序，然后以相同的用户登录并导航到完全相同的页面，则加密参数（nPBri1km2ic =）的值现在不同，如下所示。

正如上图所示，随机密钥在每个成功的登录或会话ID（cookie的一部分）中用于加密，以某种方式用作密钥的一部分。这看起来很安全，不过还是让我们尝试着SQL注入。

首先，我们尝试在多个位置注入单引号（'）以测试输入验证，但请求参数被拒绝，因为这些参数需要加密格式（即有效的密文）。

不过我们在这里可以使用购物车的一个分享功能，此功能允许用户与其他人共享购物车项目。当用户保存购物车进行共享时，会产生一个带有随机查询令牌的链接。通过访问此链接（URL），用户可以访问彼此的购物车。在购物车被要求保存之前，用户被要求在购物车上标记一个名字。

由于这是接受明文输入的罕见输入字段之一，所以我们将其编码为SQLi，XSS。在更深入的检测中，我们发现生成的URL中的令牌共享购物车实际上是我们为购物车选择的购物车名称的密码。

不过请注意，共享购物车功能可不会轻易受到任何攻击的影响，但可以用于为给定输入（明文）生成加密的有效内容（密文）。现在，可以共享购物车功能的链接就可以生成一个加密的攻击有效载荷来检查应用程序对SQL注入，绕过授权等漏洞行为进行验证了。为了测试SQL注入，生成了单引号（'）的加密值。

加密的有效载荷用于模糊仅接受密文值作为输入的各种应用参数。我们花了一些时间来打到正确的位置，但是最终，orderitem页面的ID参数返回一个SQL错误消息，确认该漏洞。

该错误消息证明应用程序生成动态查询，并可能容易受到SQL注入攻击。现在是从数据库中提取信息的时候了，基于UNION的SQL查询用于从数据库中提取数据，联合运算符用于组合两个或多个select语句的结果。

第一个任务是确定作为SQL查询的一部分返回的列数，使用试错，我们在查询中返回了一些列（30）。现在是时候从数据库中提取信息了，我们创建了一个加密的有效载荷来提取数据库版本信息，如下所示。

然后，把上述有效载荷的输出生成的密文作为页面上易受攻击的ID参数输入。

然后我们使用这个漏洞来构建数据库系统，最终得到一个shell。

总结

由上面的分析可知，用加密参数来实现应用程序中的安全性其实并不像想象中的那么安全，比如用强加密算法加密的数据，恶意攻击者可以使用加密的有效载荷的方式来进行攻击。 目前，加密仍被认为是保护数据免遭篡改或欺骗的有力机制，不过由于加密执行不力和缺乏明确的使用隐私保护，所以仍有可能会造成相当危险的安全漏洞。