假设服务器根据特定条件采取行动，让我们分析一种情况下，当服务器根据该条件的结果进行计算，并然后将响应传递给用户。在这两种情况下，无论计算是否进行，服务器都会返回响应给用户。值得注意的是，当服务器进行计算时，它会消耗一定数量的资源，这会导致服务器响应时间的延长。通常，这些响应时间的差异非常小，用户最终不会注意到。但是，揭露这些细微的响应时间差异可能会导致意外的数据泄漏。
现在让我们考虑一个基于应用程序登录过程的实际示例。假设输入的用户名正确，但密码错误：在这种情况下，服务器可能会决定进行诸如验证密码的计算。如果服务器进行这些计算，可能需要额外的资源，这导致相较于不进行计算的情况响应时间更长。尽管响应时间的差异通常很小，但它们确实存在，并且攻击者可能会测量到。
相同的过程，但是当用户名也错误时：
在这种微小的响应时间差异情况下，攻击者可能会尝试利用该信息推断出用户名的正确性。例如，攻击者可以通过分析服务器响应不同用户名请求所用的时间，执行时间攻击。通过比较响应时间，攻击者可以推断出哪个请求花费了更多时间，从而表明该用户名是正确的。揭露用户名将使攻击者可以实施密码猜解攻击。在某些情况下，尤其是当用户名是某个人的电子邮件地址，而测试的应用程序是一个争议性内容的门户网站时，还可能意味着敏感信息的披露。
使用 Burp Suite – Request Timer 进行测试
在寻找此类漏洞时，有一个名为 Request Timer 的 Burp 插件非常有用。这个插件可以帮助我们检查服务器对特定请求的响应时间。
第一步是截取负责用户登录的请求并将其发送到 Intruder 模块：
接下来，我们将密码更改为长字符串，以在生成密码哈希时增加服务器的负载。标明用户登录的地方。在被测应用程序中，还需要添加 “X-Forwarded-For” 头，并为其分配随机 IP 地址，以绕过来自同一 IP 地址的多次登录尝试的阻止。因此，我们必须将攻击类型更改为 “Pitchfork”。
添加要检查的用户名列表：
在 Request Timer 插件中定义它监听 Intruder 模块：
启动测试后，标签页中会显示生成的请求及其响应时间。如可以看到，对于正确的用户名，响应时间明显更长。我们以这种方式证明了应用程序通过分析服务器响应时间容易受到用户登录名枚举的攻击。
怎么办，如何解决？
这种问题的一种解决方案是在服务器响应中添加负责随机延迟的功能：
然而，这种解决方案的问题在于我们仍然无法控制诸如尝试连接数据库时导致的网络延迟或当数据库急剧增长时出现的差异等情况。
更好的解决方案似乎是异步在后台执行验证用户提供的数据的操作，并立即通知用户登录尝试。在这种情况下，计算和相关的延迟对于攻击者将是不可见的。
