如何使用加密的Payload来识别并利用SQL注入漏洞

写在前面的话

密码学具有诸多优点，信息的保密性同样离不开密码学，但是从历史经验来看，在保护应用和数据安全方面我们绝对不能过分依赖于密码学。在这篇文章中，安全教育培训专家SunilYadav将会讨论一个案例，并介绍如何通过一个加密的Payload来发现并利用SQL注入漏洞。

请注意：我们在此不打算讨论密码学方面的问题（例如如何破解加密算法），我们讨论的是应用程序的安全缺陷，这方面问题是很多开发者最容易忽略的问题，而本文所描述的这个漏洞将允许我们通过一个加密的Payload来识别并利用程序中的SQL注入漏洞。

实际上，这个漏洞是我们在一次真实的渗透测试过程中所发现的。为了给大家进行演示，我们在实验环境中对该漏洞进行了复现，接下来我们会讨论整个测试过程的具体细节。

漏洞发现

近期，我们对一个电子商务应用进行了渗透测试。我们发现，其中绝大多数的请求参数值都经过了加密处理。当请求参数值被加密之后，我们是很难对应用进行渗透测试／模糊测试的，除非我们能够破解它所使用的加密算法。如果在时间有限的黑盒测试过程中遇到这样的问题，那绝对是一个噩耗。

下面这张图片显示的就是这个测试项目中的订单详情页面，其中的订单ID（orderid）参数就是以加密形式发送的：

地址栏中的参数值“BDKfx3xNKsc=”是经过加密的，虽然加密后的ID参数值为base64编码格式，但这里不仅仅只采用了base64编码。除此之外我们还发现，如果我们登出了应用，并使用相同的用户账号重新登录，然后再次访问相同的页面。此时，这个经过加密的参数值就变成了“nPBri1km2ic=”，具体如下图所示：

由此可以看出，加密过程要么使用了一个随机密钥，要么就是加密密钥中有一部分数据是由会话ID构成的。从表面上看，这个应用是非常安全的，没错吧？但是我们都知道，这世界上没有绝对安全的程序，所以我们仍然要想办法找出其中有可能存在的一些加密缺陷。

首先，我们尝试在多个地方注入单引号（’）来测试系统是否能够对用户的输入进行有效验证。但是，由于这些输入必须以加密格式提供给系统，所以我们的请求参数被系统拒绝了。

接下来，我们注意到了该应用的购物车分享功能。这个功能允许用户将自己购物车里的商品分享给好友，当用户保存好购物车里的商品并点击分享之后，系统会生成一个带有随机令牌的链接。通过访问这个链接（URL），用户就可以直接查看好友的购物车了。而且在保存购物车商品之前，用户还需要给购物车命名。

由于这是一个使用频率非常低的文本输入域，所以我们的模糊测试打算从这里入手，并尝试找出SQL注入漏洞或XSS漏洞，但这一次仍然一无所获。不过，我们意识到了一件事情，那就是我们所发现的这个分享地址和购物车命名框也许会成为我们的突破口。在进一步分析之后，我们发现购入车分享地址中所使用的令牌就是购物车名称加密后所得到的密文。

虽然这个购物车分享功能并不会受到任何网络攻击的影响，但是我们却能够利用这个功能并根据输入的信息（明文，即购物车名称）来生成加密Payload（密文）。现在，我们就可以利用这个功能来生成一个攻击Payload，并利用它来检查应用程序中可能存在的漏洞，例如SQL注入漏洞以及身份认证绕过等等。为了检测SQL注入漏洞，我们需要生成单引号（’）所对应的加密值，具体如下图所示：

这样一来，对于那些只接受加密值作为输入数据的文本域，我们就可以使用这种加密Payload来进行模糊测试了。虽然寻找注入点的过程花费了我们不少的时间，但最终我们还是找到了一个SQL注入漏洞。具体如下图所示，我们在测试订单物品（orderitem）页面的IP参数时，系统返回了一个SQL错误信息：

从错误信息中可以看出，这个电子商务应用生成了动态查询语句，这里就有可能存在一个SQL注入漏洞，而我们可以利用这个漏洞从数据库中提取出有价值的信息。在这里，我们准备使用SQL UNION查询语句来从数据库中提取数据，而UNION操作符可以合并两条或多条select子句。

接下来，我们需要确定数据库表中的列数。在进行了一系列测试之后，我们从返回信息中得知了列数（30）。现在，我们就可以从数据库中提取有效信息了。我们创建了一个加密Payload，具体如下所示：

通过上面这条SQL语句所生成的Payload（ID参数），我们得到了系统所使用的数据库版本信息。

最后，我们还利用这个漏洞攻下了数据库系统，并拿到了后台服务器的Shell。

总结

这个电子商务应用程序使用了加密参数来实现安全保护，这也是通过信息隐匿来实现安全性的一个例子，但是这种做法并不能保证软件的安全。只有在密钥得到有效保护的情况下，采用健壮加密算法进行加密的数据才能够真正地保证安全。实际上，密码学以及信息加密手段已经成为了我们防止隐私消息被窃听或篡改的一种常用方法，但是由于系统在实现加密过程中的错误以及开发人员对加密手段的使用不当，往往会导致更加严重的安全漏洞出现。

* 参考来源：notsosecure， FB小编Alpha_h4ck编译，转载自FreeBuf.COM

这篇文章的思路很有趣，虽然这个思路条件很苛刻，作者也是幸运的，正好遇到了个可以自定义参数的站，倘若无法自定义参数，也无法知道参数加密方式，那么同样无解，不过还是学习到了，细心很重要，思路决定出路！