安全 HTTPS
尽管必须使用安全协议和密码，但使用 HTTPS 非常棒。有许多漏洞扫描程序可以对此进行测试。这里有两个例子：
- Qualys SSL 服务器测试
- Nmap ssl-enum-ciphers
NTLMv2 很好
您没有指定使用的是 NTLMv1 还是 NTLMv2。如果是前者（NTLMv1），这肯定是一个发现并引起关注。现在没有理由使用该协议，尤其是在面向公众的应用程序上。NTLMv2 非常好，有些人可能认为它比替代方案更安全，因为它适用于实际密码甚至不发送到服务器的质询/响应。例如，Microsoft SharePoint 和 Exchange 可以拥有使用 NTLM 身份验证的面向公众的组件。
Windows 身份验证的困难
没有 Kerberos
NTLM 身份验证是应用程序配置为使用时的默认身份验证方法Windows Authentication。这是因为 Kerberos 需要额外的配置步骤，并且客户端需要访问 Kerberos 基础结构（即域控制器）。如果 Web 应用程序只能从 LAN 或通过 VPN 访问，这会很好。然而，面向公众的 Web 应用程序并不能使这成为一个可行的选择。
缺乏会话管理
Windows 身份验证缺乏对会话管理的控制。以使用 的应用程序为例Forms Authentication，会话 cookie 可以在指定时间后过期，也可以在每次请求时延长。使用 Windows 身份验证的应用程序并非如此。未能正确终止会话肯定会是一个发现。
没有品牌登录页面
Windows 身份验证登录框是浏览器提供的通用窗口。许多人更喜欢为用户提供“品牌”登录页面，因为它允许用户更清楚他们将要登录的应用程序。检查 URL 栏以确保位置准确且证书有效（例如绿色）。这利用了有关网络钓鱼预防和良好安全意识的最终用户教育。根据您的环境，这可能是一个发现。
没有蛮力保护
通常有两种方法可以保护网站免受暴力登录尝试：MFA 和验证码。默认情况下，使用 Windows 身份验证的 Web 应用程序不支持 MFA。您可能会找到利用模块来实现此目的的提供程序，但我猜您没有使用这些提供程序之一。关于验证码，没有办法实现。这需要监视 Web 应用程序的暴力登录尝试。
为了解决这个问题，我编写了一个 PowerShell 模块WebsiteFailedLogins。从自述文件：
创建此 PowerShell 模块是为了识别影响 IIS 托管网站的以下方案。
- 蛮力登录尝试 - 来自单个 IP 地址的过多失败登录，并且通常针对单个帐户。
- Password Spraying Attempts - 在多个用户帐户中使用单个密码从单个 IP 地址多次登录失败。
- 分布式登录尝试 - 上述任何一种技术都源自多个 IP 地址。
它利用 Microsoft Logparser 和配置文件来解析目标网站的 IIS 日志。当达到或超过阈值时，将通过标准输出、电子邮件和/或写入 Windows 事件日志生成警报。无需对网络服务器进行任何更改。该模块甚至可以在可以访问 IIS 日志的单独系统上运行。
旧框架
这不一定是一个发现。在运行 IIS 的服务器上运行 Windows 更新或您用来管理安全更新的任何产品。如果缺少更新，那么这显然是一个发现。检查CVE是否有任何寻址 Web 应用程序 CLR 的内容。很有可能，如果没有丢失的安全更新，就不会有开放的 CVE。
检查支持组件
如果您担心较旧的框架，这让我相信应用程序本身已经过时了。查看像 jquery 这样的支持组件，以确保它们没有使用不安全的版本。这可能会揭示一个发现。
替代方案 - 表单身份验证
将 HTTPS 配置为使用安全协议和密码，最好的选择是Forms Authentication. 登录凭证以明文形式传输；安全的 HTTPS 可以缓解这种情况。它还实现了：
- 更好的会话管理
- 品牌登录页面
- MFA 或验证码集成
这种方法需要对 Web 应用程序进行重组。需要注意的两个警告包括：
- Web 应用程序必须使用一种安全的方法在后端验证凭据。无论是 Kerberos 还是 LDAPS，只要确保凭据没有在后端以不安全的方式共享即可。
- 必须测试访问以确保无法通过不安全的方法访问资源。例如，默认情况下，MVC 应用程序在提供 .js 和 .css 文件时会使用静态处理程序来提高性能，从而绕过身份验证要求。在某些情况下，这些资源应该只有经过身份验证的用户才能访问。
替代方案 - SSO
解决这些身份验证问题的最佳方法是实施单点登录 (SSO) 提供程序。它仍然需要为新的身份验证方法重新调整 Web 应用程序。但是，从长远来看，这是最好的方法，因为它集中了企业的身份验证。