注意：我们在本文中讨论的问题并不是加密（即如何破解密码），而是应用程序自身的缺陷，并且能够由开发人员进行监督，使我们生成加密的有效负载（即任何给定明文的密文），然后将其用于识别和利用SQL注入。

实际的案例在现实中其实是比较难发现的，因此我们在我们的hack实验室中重新创建了一个类似的漏洞，用于此演示，下面将会进行详细的介绍：

在最近的一个电子商务应用程序中，我们观察到大多数请求参数值已被加密。当请求参数被加密时，很难fuzz应用程序，除非可以中断加密（这需要知道密钥和加密算法），而这段时间内从黑盒子中获得这些是不太可能的。具体情况可以查看我们上一篇关于黑客隐私的文章，从而能够更了解这个问题。

这是订单详细信息页面的示例，其中以加密格式发送id（orderid）参数。

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

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

这提供了一个很好的指示，即随机密钥在每个成功的登录或会话ID（cookie的一部分）中用于加密，以某种方式用作密钥的一部分。这些看起来会很安全吗？我们原本想试着找一些加密的缺陷，但似乎运气并不好。

首先，我们尝试在几个位置注入单引号（'）来测试输入验证。但请求参数被拒绝了，因为这些参数需要加密格式（即有效的密文），因此我们似乎走到了墙角。

然后我们偶然发现了一个小车分享功能，此功能允许用户与其他人共享购物车项目。当用户保存购物车进行共享时，会产生一个带有随机查询令牌的链接。通过访问此链接（URL），用户可以访问彼此的购物车，而在购物车可以保存之前，用户会被要求在购物车中输入一个名字。

由于这是接受明文输入的罕见输入字段之一，所以我们对其进行了SQLi，XSS以及其他所有的Fuzz！但却再次陷入了困境。

这时我们意识到，我们实际上偶然间发现了一些非常有趣的事情。在更深入的了解后，事实证明，生成的URL中的令牌共享购物车实际上是我们为购物车选择的购物车名称的密码。

注意：Share cart功能不容易受到任何攻击的影响，但可以用于为给定输入（明文）生成加密的有效内容（密文）。现在，可以生成一个加密的攻击有效载荷来检查应用程序对SQL注入，访问权限绕过等漏洞的行为。为了测试SQL注入，我们生成了单引号（'）的加密值，如下所示：

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

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

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

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

最后我们使用这个漏洞构建了数据库系统，并最终得到一个shell！

结论

加密参数来实现应用程序中的安全性是一个比较隐蔽的安全性例子。加密不会使软件更安全，但使用强加密算法加密的数据保密，直到时间密钥受到保护或恶意角色识别生成加密有效载荷的方式，已经被认为是保护数据免遭篡改或欺骗的事实机制。然而我们在这篇文章中看到，由于执行不力和缺乏明确管理方法可能会导致出现相当破坏性的安全漏洞。