【渗透测试】渗透测试最强秘籍（Part 4：认证测试）

阅读： 3,286

分享纲要：

1.测试通过加密通道传输的凭证
2.测试默认凭证
3.测试弱锁定机制
4.绕过验证模式进行测试
5.测试记住密码功能
6.测试浏览器缓存弱点
7.测试弱密码策略
8.测试弱安全性问题/答案
9.测试弱密码更改或重置功能

往期回顾：

【渗透测试】渗透测试最强秘籍（Part 1：信息收集）

【渗透测试】渗透测试最强秘籍（Part 2：配置和部署）

【渗透测试】渗透测试最强秘籍（Part 3：身份管理）

1.测试通过加密通道传输的凭证

黑盒测试

在以下示例中，我们将使用Burp Suite捕获数据包标头并检查它们。

示例1：通过HTTP使用GET / POST方法发送数据

假设登录页面显示了一个带有“用户名”，“密码”字段和“提交”按钮的表单，以对应用程序进行身份验证并授予访问权限。

所以数据在没有加密的情况下传输，恶意用户可以通过简单地使用Wireshark等工具嗅探网络来拦截用户名和密码

示例2：通过HTTPS使用GET / POST方法发送数据

假设我们的Web应用程序使用HTTPS协议来加密我们发送的数据（或至少用于传输敏感数据，如证书）。在这种情况下，当登录到Web应用程序时，我们的POST请求的标题与以下内容类似：

示例3：在通过HTTP可访问的页面上通过HTTPS使用GET / POST方法发送数据

想象一下，我们有一个可通过HTTP访问的网页，并且只有通过HTTPS传输认证表单发送的数据

我们可以看到，我们的请求使用HTTPS发送到www.example.com/login。但是，如果我们看一下Referer-header，它就是www.example.com/并且可以通过简单的HTTP访问。尽管我们通过HTTPS发送数据，但这种部署可能会允许SSLStrip攻击（一种中间人攻击）

您可以看到数据在URL中以明文形式传输，而不在请求的正文中传输。但是我们必须考虑SSL / TLS是一个5级协议，比HTTP更低，所以整个HTTP数据包仍然被加密，使得使用嗅探器的恶意用户无法读取URL。尽管如此，如前所述，使用GET方法将敏感数据发送到Web应用程序并不是一个好习惯，因为URL中包含的信息可以存储在许多位置，例如代理和Web服务器日志。

2.测试默认凭证

如何测试

测试常见应用程序的默认凭据

尝试默认用户名，例如：admin，administrator，root，system，guest，operator，superuser

应用程序管理用户通常以应用程序或组织命名。这意味着如果您正在测试名为“ABC”的应用程序，请尝试使用abc / abc或任何其他类似的组合（如用户名和密码）。

使用上面的用户名和空密码。

查看页面源代码和JavaScript，查找注释中写入的帐户名称和密码。

检查包含用户名和密码的配置文件。

检查密码提示。

测试新帐户的默认密码？

工具

Burp Intruder
Hydra
Nikto
Medusa

参考

CIRT http://www.cirt.net/passwords

3.测试弱锁定机制

帐户锁定机制用于缓解暴力密码猜测攻击。通常在3到5次不成功的登录尝试后帐户被锁定，并且只能在预定的时间段后，通过自助服务解锁机制或管理员干预才能解锁。帐户锁定机制需要在保护帐户免受未经授权的访问和防止用户被拒绝授权访问之间取得平衡。

测试目标

评估帐户锁定机制减轻暴力密码猜测的能力
评估解锁机制对未授权帐户解锁的抵制。

如何测试

使用Burp Intruder＆Burp Repeater

审视源代码

确保网站有帐户锁定政策 -一定数量的失败登录后账户会被锁定

确保应用程序响应限制用户超时并验证有限超时是否正确

确保应用程序在用户接近锁定线程时提醒用户
CAPTCHA可能会妨碍暴力攻击，但它们无法取代锁定机制。

尝试旁路锁定超时
列出解锁网站账户的所有方法，确保它们安全

4.绕过验证模式进行测试

如何测试

参数修改

当应用程序根据固定值参数验证成功登录时。用户可以修改这些参数以访问保护区而无需提供有效凭证。

会话操作

SQL注入

直接页面请求（强制浏览）

如果Web应用程序仅在登录页面上实现访问控制，则可以绕过认证架构。

会话ID预测

许多Web应用程序使用会话标识符（会话ID）来管理身份验证。因此，如果会话ID生成是可预测的，恶意用户可能能够找到有效的会话ID并获得未经授权的用户访问权限。

工具

Burp Suite
ZAP
WebGoat

5.测试记住密码功能

如何测试

查找存储在cookie中的密码。检查应用程序存储的Cookie。验证凭据不是以明文形式存储的。

检查哈希机制：如果它是一个常用的，众所周知的算法，请检查它的强度，它自带的哈希函数，尝试多个用户名来检查哈希函数是否容易被猜测。

验证凭据仅在登录阶段发送，并且不会与每个请求一起发送到应用程序。

考虑其他敏感的表单字段（例如，必须在密码恢复或帐户解锁表单中输入的秘密问题的答案）。

检查：autocomplete =“off”

6.测试浏览器缓存弱点

浏览器可以存储用于缓存和历史记录的信息。缓存用于提高性能，因此以前显示的信息不需要再次下载。历史记录机制用于用户方便，因此用户可以准确看到他们在检索资源时看到的内容。如果向用户显示敏感信息（例如他们的地址，信用卡详细信息，社会安全号码或用户名），则可以将此信息存储用于缓存或历史记录，因此可以通过检查浏览器的缓存或通过简单按下浏览器的“返回”按钮。

如何测试：

如果按下“返回”按钮，测试人员可以访问以前的页面但不能访问新页面，那么这不是一个认证问题，而是一个浏览器历史问题。如果这些页面包含敏感数据，则意味着应用程序不禁止浏览器存储它。

认证不一定需要参与进测试。例如，当用户输入他们的电子邮件地址以注册时事通讯时，如果处理不当，该信息可以被检索。

“后退”按钮可以停止显示敏感数据。这可以通过以下方式完成：

通过HTTPS传递页面。
设置缓存控制：必须重新验证

浏览器缓存。在这里，测试人员检查应用程序是否将任何敏感数据泄漏到浏览器缓存中。为此，他们可以使用代理（例如Burp Suite）并搜索属于会话的服务器响应，检查每个包含敏感信息的页面，服务器指示浏览器不要缓存任何数据。这样的指令可以在HTTP响应头文件中发出：

Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache

这些指令通常是健全的，但为了更好地防止文件系统上持久链接的文件，头标可能需要额外的标志：

Cache-Control: must-revalidate,pre-check=0, post-check=0, max-age=0, s-maxage=0

信息存储的确切位置取决于使用的浏览器。

火狐浏览器：

Unix/Linux: ~/.mozilla/firefox//Cache/
Windows: C:\Documents and Settings\\Local Settings\Application Data\Mozilla\Firefox\Profiles\\Cache

Internet Explorer:

C:\Documents and Settings\\Local Settings\Temporary Internet Files

示例：

使用名称root密码登录并截取分析数据包

如您所见，我们在响应数据包中没有任何Cache-control标头。

从留言板页面，让我们点击注销按钮。然后点击浏览器或历史记录上的“后退按钮”（Ctrl + H）选择留言板，我们将捕获此结果。

7.测试弱密码策略

测试目标

通过评估密码的长度，复杂性，重用和老化要求，使用可用的密码字典确定应用程序对抗暴力密码猜测的阻力。

如何测试：

1.密码中允许使用哪些字符和禁止使用哪些字符？用户是否需要使用不同字符集中的字符，如小写字母，数字和特殊符号？
2.用户多久更换一次密码？用户更改密码的速度有多快？之前的变化？用户可以通过连续5次更改密码来绕过密码历史记录要求，以便在最后更改密码后，他们再次配置其初始密码。
3.用户何时必须更改密码？ 90天后？由于过度登录尝试而导致帐户锁定之后？
4.用户多久可以重复使用密码？应用程序是否保留用户以前使用过的8个密码的历史记录？
5.下一个密码与最后一个密码的区别有多大？
6.用户是否阻止使用他的用户名或其他帐户信息（例如第一个或第三个
姓氏）在密码中？

示例：

检查源代码并获取系统的当前密码策略，确保它们遵循以下所示内容：
（密码必须符合以下4个复杂性规则中的至少3个）
– 至少1个大写字符（A-Z）
– 至少1个小写字符（a-z）
– 至少1位数字（0-9）
– 至少1个特殊字符
– 至少10个字符
– 最多128个字符
– 连续不超过2个相同的字符（例如，111不允许）