Web 应用程序渗透测试指南第二部分

在文章的最后一部分中，我们已经讨论了需求收集、信息收集和 URL 发现的过程，现在我们将讨论其他步骤。

自动扫描仪配置：扫描仪配置是流程中最关键的部分之一。如果出现任何问题，那么我们可能会妨碍客户的应用程序，现在我们将讨论如何。如果我们要在客户的实时生产环境中运行扫描，那么请注意，我们可能会通过正在运行的扫描仪拒绝网站上的服务，并且他们的数据库将充满扫描仪生成的垃圾条目。运行扫描前要记住的事情：

• 我们是否使用登录凭据进行扫描？– 如果是，应用程序必须具有一些形式和功能，允许用户向数据库提交数据。然后，如果扫描器使用 100 个有效载荷扫描相同的功能，并且所有数据都将提交到数据库。正如我们在要求客户进行数据库备份的需求收集步骤中已经讨论过的。因此，在 Pentest 完成后，应用程序所有者将恢复数据库。
  
• 我们是否正在扫描所有 URL？– 如果是，请确保不要扫描任何会直接影响应用程序或用户的关键 URL，例如，在服务器上运行 cron 作业并在每次点击时生成邮件的 URL 必须从此类 URL 中排除扫描仪，因为它也会触发 100 封邮件和 cron 作业。
  

现在我们将看到如何配置扫描仪我们总是喜欢使用多个扫描仪，因为在我们使用 Burp Suite 和 Acunetix 的情况下，所有扫描仪都无法找到所有内容。我们已经捕获了 Burp Suite 中的所有 URL，并完成了 URL 发现部分，我们将转到 Burp 站点地图并右键单击范围并选择主动扫描此主机。

现在 Burp Suite 将扫描范围内的所有 URL，如下所示。

如果我们正在扫描登录区域，则此过程存在问题，因此有可能我们不会获得更好的结果，因为登录会话已过期，并且扫描器每当发送带有有效负载的请求时，应用程序都会将其重定向到登录页面，因此我们必须使用活动会话进行扫描，通常在应用程序浏览过程中选择要运行扫描的 URL 并右键单击并进行活动扫描，扫描仪将开始使用单个请求和活动会话进行扫描。

从上面可以看出，一旦我们完成了对所有 URL 的扫描，这就是我们所发现的。接下来，我们将配置 Acunetix 打开扫描仪并单击 New Scan，它将打开一个扫描向导。

在网站 URL 部分添加目标 URL，然后单击下一步。下一步选择自定义。

在扫描选项中检查扫描模式并选择扩展模式。

接下来，选择 Crawling Options 并检查这两个选项：启动 HTTP 嗅探器以进行手动爬网和获取默认索引文件。

然后单击“确定”，扫描器将首先开始抓取应用程序，然后它会打开另一个窗口进行手动浏览，然后再次使用登录浏览应用程序并触发每个功能，以便扫描器捕获所有请求。完成浏览后关闭窗口，扫描仪将开始扫描应用程序。

在我们的案例中，下面是发现的漏洞。

手动测试：在手动测试中，我们将关注两件事：

1. 尝试通过滥用应用程序功能来寻找逻辑漏洞
2. 评估自动扫描器结果并手动验证所有漏洞并消除误报结果。

在逻辑问题发现中，我们将关注那些通常不会被任何自动扫描器发现的问题，我们不会测试如 SQL 注入、XSS 或任何其他通常可以通过运行扫描器发现的此类问题所以我们不会浪费时间去寻找这些问题。为了首先找到逻辑问题，我们必须了解应用程序功能，当用户触发该功能时会发生什么，以及如果我们更改参数值会发生什么。因此，我们将展示目标应用程序某些功能的一些测试场景。登录应用程序后，我们遇到的第一个功能是帐户摘要，它显示帐户活动的详细信息。账户活动显示来自账户的交易详情；

因此，当我们选择 Savings 帐户时，它会触发以下请求：

从上面的 POST 请求中可以看出，accountId 参数值为 1，因此我们从下拉菜单中选择了所有类型的帐户，并注意到 id 值随后发生了变化。我们已经确定为五种类型的帐户分配了从 1 到 5 的值。不，如果我们将值更改为 6、7、8 等，它会显示一些数据吗？这将是我们在这种情况下的测试用例。因此，我们可以使用 Burp 的 Intruder 选项对 accountId 参数值进行模糊测试，并可以检查响应。

我们将在反馈表单中看到的另一个场景是一个非登录区域。这种表单的作用需要用户反馈，并且必须存储在数据库或邮件中的某个位置。

如上所示，表单要求输入姓名、电子邮件、主题和评论。所以，我们首先要检查：

反自动化不足——当我们提交请求时，是否有可能多次重复相同的请求。如果是，那么这将是一个漏洞，因为如果应用程序将反馈存储在数据库中，那么数据库将充满垃圾数据，并且可能会耗尽内存，从而导致拒绝服务，或者如果应用程序将反馈存储为发送电子邮件给应用程序所有者，然后它会发送创建电子邮件泛滥问题，因为在多个表单提交时，应用程序所有者将收到多封电子邮件。从上面可以看出，当我们提交反馈表单时，它会触发 POST 请求。

现在我们在 Intruder 中发送了这个请求并重复了 10 次，从下面可以看到我们提交的所有请求：

恶意链接注入：这里将通过添加超链接的恶意链接来检查评论字段。如果表单被提交，则可以使用 HTML 超链接标记向应用程序所有者发送网络钓鱼链接。

如上所示，我们提交了<a href=”https://www.phishing.com”>点击这里</a>，点击发送消息，提交成功。

通过使用相同的方法，我们必须测试所有应用程序功能，这将是一个耗时的过程，但是当我们在最终报告中结合扫描器和手动漏洞时，结果会好得多。

一旦我们完成了逻辑漏洞查找，我们将检查扫描器发现的问题并删除误报，例如，我们打开了 Burp 结果，它检测到 SQL 注入，因此我们检查了哪个 URL。

从上面可以看出，它显示的currencyId 参数容易受到SQL 注入的影响，因此我们针对此请求触发了Sqlmap，如下所示，它可以检测后端数据库。

我们将看到跨站点脚本漏洞的另一个实例，如下所示，burp 在 accountID 参数中注入了一个 XSS 负载。

我们重复相同的请求并打开来自浏览器的响应，然后 XSS 负载在浏览器中执行。

通过执行它们，两个扫描器发现的所有漏洞都是误报。

报告：完整的渗透测试活动的最后一部分，它是我们将与应用程序所有者共享的所有发现的详细文档。在报告中，将报告以下内容。

漏洞名称 – 发现的名称，如 SQL 注入、XSS 等。

严重性 – 漏洞严重性级别高/中/低。

描述 – 详细描述我们发现的发现方式和内容。

影响 – 如果我们利用漏洞的影响。

受影响的 URL – 已找到我们发布的所有 URL 和参数。

建议 – 如何解决问题。

上面提到的细节可以在下面的表格格式中呈现。

以下是我们发现的所有漏洞的列表。

转载请注明：布尔云安的博客 » Web 应用程序渗透测试指南第二部分