ID |
---|
WSTG-IDNT-04 |
此测试的范围是验证是否可以通过与应用程序的身份验证机制交互来收集一组有效的用户名。此测试对于暴力测试很有用,在该测试中,测试人员会验证给定有效的用户名是否可以找到相应的密码。
通常,Web 应用程序会显示系统上何时存在用户名,这可能是由于配置错误或设计决策造成的。例如,有时,当我们提交错误的凭据时,我们会收到一条消息,指出系统上存在用户名或提供的密码错误。攻击者可利用获取的信息获取系统上的用户列表。此信息可用于攻击 Web 应用程序,例如,通过暴力破解或默认用户名和密码攻击。
测试人员应与应用程序的身份验证机制进行交互,以了解发送特定请求是否会导致应用程序以不同的方式进行应答。之所以存在此问题,是因为当用户提供有效的用户名时,从 Web 应用程序或 Web 服务器发布的信息与使用无效用户名时发布的信息不同。
在某些情况下,会收到一条消息,显示提供的凭据是否错误,因为使用了无效的用户名或无效的密码。有时,测试人员可以通过发送用户名和空密码来枚举现有用户。
在黑盒测试中,测试人员对特定应用程序、用户名、应用程序逻辑、登录页面上的错误消息或密码恢复工具一无所知。如果应用程序易受攻击,测试人员将收到一条响应消息,该消息直接或间接地揭示了一些对枚举用户有用的信息。
当您提交有效的用户 ID 和有效的密码时,记录服务器应答。
使用 Web 代理时,请注意从此成功身份验证中检索到的信息(HTTP 200 响应,响应的长度)。
现在,测试人员应尝试插入有效的用户 ID 和错误的密码,并记录应用程序生成的错误消息。
浏览器应显示类似于以下内容的消息:
Figure 4.3.4-1: 身份验证失败与任何显示用户存在的消息不同,如下所示:
Login for User foo: invalid password
使用 Web 代理时,请注意从此失败的身份验证尝试中检索到的信息(HTTP 200 响应,响应的长度)。
现在,测试人员应该尝试插入无效的用户 ID 和错误的密码,并记录服务器应答(测试人员应该确信用户名在应用程序中无效)。记录错误消息和服务器应答。
如果测试人员输入不存在的用户 ID,他们可能会收到类似于以下内容的消息:
Figure 4.3.4-3: 此用户未处于活动状态或如下消息:
Login failed for User foo: invalid Account
通常,应用程序应使用相同的错误消息和长度来响应不同的错误请求。如果响应不同,测试人员应调查并找出在两个响应之间产生差异的关键。例如:
- 客户端请求:用户有效/密码错误
- 服务器响应:密码不正确
- 客户端请求:错误的用户/错误的密码
- 服务器响应:无法识别用户
上述响应让客户端了解,对于第一个请求,他们有一个有效的用户名。因此,他们可以与应用程序进行交互,请求一组可能的用户 ID 并观察答案。
查看第二个服务器响应,测试人员以同样的方式理解他们没有有效的用户名。因此,他们可以以相同的方式进行交互,并创建一个有效的用户 ID 列表,查看服务器答案。
测试人员可以通过多种方式枚举用户,例如:
某些 Web 应用程序会发布我们可以分析的特定错误代码或消息。
例如:
http://www.foo.com/err.jsp?User=baduser&Error=0
http://www.foo.com/err.jsp?User=gooduser&Error=2
如上所示,当测试人员向 Web 应用程序提供用户 ID 和密码时,他们会看到一条消息,指示 URL 中发生了错误。在第一种情况下,他们提供了错误的用户 ID 和错误的密码。在第二种情况下,一个好的用户 ID 和一个错误的密码,以便他们可以识别有效的用户 ID。
有时,如果 Web 服务器收到对现有目录的请求,它会做出不同的响应。例如,在某些门户中,每个用户都与一个目录相关联。如果测试人员尝试访问现有目录,他们可能会收到 Web 服务器错误。
从 Web 服务器收到的一些常见错误包括:
例:
http://www.foo.com/account1
- 我们从网络服务器接收:403 禁止访问http://www.foo.com/account2
- 我们从 Web 服务器接收:404 文件未找到在第一种情况下,用户存在,但测试人员无法查看网页,在第二种情况下,用户“account2”不存在。通过收集这些信息,测试人员可以枚举用户。
测试人员可以在网页标题上收到有用的信息,在那里他们可以获得特定的错误代码或消息,以揭示问题是否与用户名或密码有关。
例如,如果用户无法对应用程序进行身份验证,但收到的网页标题类似于:
Invalid user
Invalid authentication
当我们使用恢复工具(即忘记密码功能)时,易受攻击的应用程序可能会返回一条消息,显示用户名是否存在。
例如,类似于以下内容的消息:
Invalid username: email address is not valid or the specified user was not found.
Valid username: Your password has been successfully sent to the email address you registered with.
当我们在不存在的目录中请求用户时,我们并不总是收到 404 错误代码。相反,我们可能会收到带有图像的“200 OK”,在这种情况下,我们可以假设当我们收到特定图像时,用户不存在。此逻辑可应用于其他 Web 服务器响应;诀窍是对 Web 服务器和 Web 应用程序消息进行良好的分析。
除了查看回复的内容外,还应考虑回复所需的时间。特别是当请求导致与外部服务交互(例如发送忘记密码的电子邮件)时,这可能会给响应增加数百毫秒,这可用于确定请求的用户是否有效。
在某些情况下,用户标识是使用管理员或公司的特定策略创建的。例如,我们可以查看具有按顺序创建的用户 ID:
CN000100
CN000101
...
有时,用户名是使用 REALM 别名创建的,然后是序列号:
在上面的示例中,我们可以创建简单的 shell 脚本来编写用户 ID,并使用 wget 等工具提交请求,以自动执行 Web 查询以识别有效的用户 ID。要创建脚本,我们还可以使用 Perl 和 curl。
其他可能性包括: - 与信用卡号关联的用户 ID,或具有模式的一般数字。- 与真实姓名相关的用户 ID,例如,如果 Freddie Mercury 的用户 ID 为“fmercury”,那么您可能会猜测 Roger Taylor 的用户 ID 为“rtaylor”。
同样,我们可以从从LDAP查询或Google信息收集(例如,从特定域)接收的信息中猜测用户名。Google 可以通过特定查询或简单的 shell 脚本或工具帮助查找域用户。
通过枚举用户帐户,可能会在预定义次数的探测失败后锁定帐户(基于应用程序策略)。此外,有时,您的 IP 地址可能会被应用程序防火墙或入侵防御系统上的动态规则禁止。
确保未注册的用户在注册过程中无法选择保留的用户名(例如,管理员、管理员、版主)。此外,验证用户是否无法在配置文件编辑页面上将其当前用户名编辑为这些保留用户名之一。
如果 Web 应用程序具有允许用户访问 Web 应用程序的注册和配置文件编辑功能的功能,则要测试的交互包括以下内容:
验证应用程序是否以相同的方式应答产生失败身份验证的每个客户端请求。对于此问题,黑盒测试和灰盒测试具有相同的概念,基于对从 Web 应用程序接收的消息或错误代码的分析。
对于每次失败的身份验证尝试,应用程序都应以相同的方式进行应答。
例如:提交的凭据无效
确保应用程序返回一致的通用错误消息,以响应在登录过程中输入的无效帐户名、密码或其他用户凭据。
确保在将系统发布到生产环境(或将其公开给不受信任的网络)之前删除默认系统帐户和测试帐户。