抠丁客 抠丁客
项目
编辑 (2025/12/24)

ABP 渗透测试报告

ABP Commercial MVC v9.1.0 应用程序模板已使用 OWASP ZAP v2.14.0 工具进行了安全漏洞测试。演示 Web 应用程序在 https://localhost:44349 地址上启动。以下是渗透测试工具报告的警报。这些警报按风险等级排序为高、中、低。信息性警报未在本文档中提及。

其中许多警报是误报，意味着漏洞扫描器检测到了这些问题，但它们实际上无法被利用。对于每个误报警报，都明确解释了为什么此警报是误报。

在接下来的章节中，您将找到受影响的 URL、攻击参数（请求体）、警报描述、误报解释以及问题的修复方法。一些确实存在的警报（正报）已经修复或需要您采取额外行动。修复相关的问题链接已在每个正报中提及。

警报

存在高（红色旗标）、中（橙色旗标）、低（黄色旗标）和信息性（蓝色旗标）警报。

penetration-test-9.1.0

信息性警报未在本文档中提及。这些警报不会对您的应用程序构成任何风险，并且它们是可选的。

Spring4Shell [风险：高] - 误报

描述：

应用程序似乎易受 CVE-2022-22965（也称为 Spring4Shell）的攻击 - 通过数据绑定进行远程代码执行。

解释：

ABP 框架构建于 ASP.NET Core 之上，不使用 Spring 框架。此应用程序不依赖基于 Java 的技术，因此对 Spring4Shell 等漏洞免疫。此检测是误报，因为项目中不存在 Spring 依赖。

缺少反 CSRF 令牌 [风险：中] — 误报

描述：

在 HTML 提交表单中未找到反 CSRF 令牌。 跨站请求伪造是一种攻击，涉及迫使受害者在不知情或无意的情况下向目标目的地发送 HTTP 请求，以受害者的身份执行操作。其根本原因是应用程序功能使用了可预测且可重复的 URL/表单操作。攻击的本质是 CSRF 利用了网站对用户的信任。相比之下，跨站脚本攻击利用了用户对网站的信任。与 XSS 类似，CSRF 攻击不一定是跨站的，但也可以是。跨站请求伪造也称为 CSRF、XSRF、单点攻击、会话挟持、混淆代理和海浪攻击。

解释：

这是一个误报警报，因为 ABP 通过 Cookie 提供反 CSRF 令牌，如下截图所示：

缺少反 CSRF 令牌

应用程序错误信息泄露 [风险：中] - 误报

描述：

此页面包含可能泄露敏感信息的错误/警告消息，例如产生未处理异常的文件的路径。此信息可用于对 Web 应用程序发起进一步攻击。如果错误消息在文档页面中找到，则此警报可能是误报。

解释：

仅报告了一个泄露错误消息的 URL。这是一个误报警报。审计日志模块 显示请求和响应详情以及异常信息，这些不是敏感信息，并且只有具有相关权限的用户才能看到。

内容安全策略头未设置 [风险：中] — 正报（已修复）

描述：

内容安全策略是增加的一层安全保护，有助于检测和缓解某些类型的攻击，包括跨站脚本攻击和数据注入攻击。这些攻击可用于从数据窃取到网站篡改或恶意软件分发的各种行为。CSP 提供了一组标准 HTTP 头，允许网站所有者声明浏览器应允许在某个页面上加载的已批准内容来源 - 涵盖的类型包括 JavaScript、CSS、HTML 框架、字体、图像以及可嵌入对象，如 Java applets、ActiveX、音频和视频文件。

解决方案：

确保您的 Web 服务器、应用服务器、负载均衡器等配置为设置 Content-Security-Policy 头，以获得最佳的浏览器支持："Content-Security-Policy" 用于 Chrome 25+、Firefox 23+ 和 Safari 7+，"X-Content-Security-Policy" 用于 Firefox 4.0+ 和 Internet Explorer 10+，"X-WebKit-CSP" 用于 Chrome 14+ 和 Safari 6+。

此漏洞已在 ABP v7.0 中修复。您可以从 github.com/abpframework/abp/issues/14173 查看相关问题。您可以配置 AbpSecurityHeadersOptions 并将 UseContentSecurityPolicyHeader 属性设置为 true，以将 Content-Security-Policy 头添加到您的应用程序：

Configure<AbpSecurityHeadersOptions>(options =>
{
   options.UseContentSecurityPolicyHeader = true; //默认为 false
});

更多信息请参阅文档。

格式字符串错误 [风险：中] - 误报

描述：

当应用程序将输入字符串的提交数据作为命令求值时，会发生格式字符串错误。

解决方案：

使用适当的坏字符字符串删除方法重写后台程序。这将需要重新编译后台可执行文件。

解释：

第一个受影响的 URL 是误报警报，因为它已经修复，并且这些端点的响应中不再有任何坏字符字符串。(它会显示错误消息，例如："所选文化无效！请确保输入有效的文化名称。")。

第二个 URL 也是误报警报，因为响应中没有坏字符字符串。

注意：但是，如果您在本地化条目中有任何敏感的本地化键值对，则此端点返回所有本地化值以便在应用程序中使用，这可能会存在问题。因此，在定义新的本地化条目时请记住这一点。在使用本地化条目作为参数时，在代码中传递关键值。

XSLT 注入 [风险：中] - 误报

描述：

使用 XSL 转换进行注入可能是可行的，并且可能允许攻击者读取系统信息、读写文件或执行任意代码。

解释：

这是一个误报警报。v9.0 使用 .NET 9，在 .NET5 或更高版本上无法进行 XSLT 转换。

应用程序错误信息泄露 [风险：低] — 误报

描述：

报告的页面包含可能泄露敏感信息的错误/警告消息，例如产生未处理异常的文件的路径。此信息可用于对 Web 应用程序发起进一步攻击。如果错误消息在文档页面中找到，则此警报可能是误报。

解释：

此漏洞被报告为正报警报，因为应用程序在 Development 模式下运行。ABP 会在 Development 环境中为开发者抛出异常。我们将环境设置为 Production 并重新运行测试，然后服务器发送了 500-内部错误 而没有泄露错误信息。因此此警报是误报。更多信息可以在以下问题中找到：github.com/abpframework/abp/issues/14177。

Cookie 缺少 HttpOnly 标志 [风险：低] — 正报（无需修复）

描述：

Cookie 在设置时没有安全标志，这意味着该 Cookie 可以通过未加密的连接访问。

解释：

以下警报与下一个警报相关。因此，要理解此警报，您可以查看下一个警报：Cookie 缺少 Secure 标志 [风险：低]

Cookie 缺少 Secure 标志 [风险：低] — 正报（无需修复）

描述：Cookie 在设置时没有安全标志，这意味着该 Cookie 可以通过未加密的连接访问。以下 Cookie 没有 httponly 标志。

  • XSRF-TOKEN (反 CSRF 令牌 Cookie)
  • .AspNetCore.Culture (ASP.NET Core 文化 Cookie)

解释：

在 HTTP 响应中设置 XSRF-TOKEN 和 .AspNetCore.Culture Cookie 的所有页面都被报告为"缺少 HttpOnly 标志"漏洞。这是一个正报警报。

给 IDS4 用户的说明：idsrv.session Cookie 在 IDS4 中使用，在 ABP 6.x 之后，ABP 切换到了 OpenIddict (github.com/abpframework/abp/issues/7221)。因此，当前的启动模板中不使用此 Cookie，如果您在 v6.0+ 之后创建了应用程序，则可以忽略此说明。但是，如果您仍在使用 Identity Server 4，则存在一个与 idsrv.session Cookie 相关的问题，即它不能设置为 HttpOnly；您可以在其自己的仓库查看相关讨论：github.com/IdentityServer/IdentityServer4/issues/3873

.AspNetCore.Culture 和 XSRF-TOKEN Cookie 在 ABP Angular、MVC 和 Blazor WASM UI 中通过 JavaScript 获取。因此它们不能设置为 HttpOnly。您可以查看以下通过 JavaScript 获取这些 Cookie 的模块：

将 XSRF-TOKEN Cookie 设置为 HttpOnly：

如果您想设置它，可以配置 AbpAntiForgeryOptions 类的 TokenCookie 属性。

将 .AspNetCore.Culture Cookie 设置为 HttpOnly：

如果您想设置它，可以在 AbpRequestCultureCookieHelper 类中完成。将选项设置为 HttpOnly = true。

此警报的相关问题可以在 github.com/abpframework/abp/issues/14214 找到。

Cookie 的 SameSite 属性为 None [风险：低] — 正报（无需修复）

描述：

Cookie 的 SameSite 属性设置为 none，这意味着该 Cookie 可以由于跨站请求而被发送。SameSite 属性是应对跨站请求伪造、跨站脚本包含和定时攻击的有效对策。

解决方案：

确保所有 Cookie 的 SameSite 属性都设置为 lax 或最好是 strict。您可以查看 Amazon.com 的 SameSite 属性策略。我们在以下问题 github.com/abpframework/abp/issues/14215 中讨论了将 SameSite 属性设置为 strict，并决定将此更改留给最终开发者。

Amazon.com SameSite 属性策略

Cookie 缺少 SameSite 属性 [风险：低] — 正报（无需修复）

描述：

Cookie 的 SameSite 属性设置为 none，这意味着该 Cookie 可以由于跨站请求而被发送。SameSite 属性是应对跨站请求伪造、跨站脚本包含和定时攻击的有效对策。

解决方案：

确保所有 Cookie 的 SameSite 属性都设置为 lax 或最好是 strict。我们在以下问题 github.com/abpframework/abp/issues/14215 中讨论了将 SameSite 属性设置为 strict，并决定将此更改留给最终开发者。

信息泄露 - 调试错误消息 [风险：低] — 误报

描述：

响应似乎包含 ASP.NET 等平台以及 IIS 和 Apache 等 Web 服务器返回的常见错误消息。您可以配置常见调试消息的列表。

解决方案：

在推送到生产环境之前禁用调试消息。

解释：

上述端点的响应返回本地化文本，这些并非真正的错误消息。由于后端没有真正的错误，此漏洞是误报警报。

信息泄露 - 调试错误消息

Strict-Transport-Security 头未设置 [风险：低] - 误报

描述：

HTTP 严格传输安全是一种 Web 安全策略机制，通过该机制，Web 服务器声明遵守规范的客户端（例如 Web 浏览器）应仅使用安全的 HTTPS 连接（即基于 TLS/SSL 的 HTTP）与其交互。HSTS 是一个 IETF 标准跟踪协议。

解决方案：

在生产环境启用 HSTS。

解释：

此漏洞被报告为正报警报，因为应用程序在 Development 模式下运行。我们在 Production 模式下启用 HSTS，如下图所示，因此这是误报警报。

HSTS

时间戳泄露 - Unix [风险：低] - 误报

描述：

应用程序/Web 服务器泄露了一个时间戳 - Unix

解决方案：

手动确认时间戳数据不敏感，并且这些数据无法被聚合以泄露可利用的模式。

解释：

此漏洞被报告为正报警报，因为 ABP 使用 zxcvbn 库作为密码复杂度指示器。该库是最常用的密码强度估计器之一，它不会泄露任何与 Web 服务器时间戳相关的敏感数据，因此是误报警报。

X-Content-Type-Options 头缺失 [风险：低] - 正报（已修复）

描述：

反 MIME 嗅探头 X-Content-Type-Options 未设置为 'nosniff'。这允许旧版本的 Internet Explorer 和 Chrome 对响应正文执行 MIME 嗅探，可能导致响应正文被解释并显示为与声明的内容类型不同的内容类型。当前（2014 年初）和旧版本的 Firefox 将使用声明的内容类型（如果已设置），而不是执行 MIME 嗅探。

解决方案：

确保应用程序/Web 服务器适当设置 Content-Type 头，并为所有网页将 X-Content-Type-Options 头设置为 'nosniff'。

如果可能，确保最终用户使用符合标准且现代的 Web 浏览器，这些浏览器根本不执行 MIME 嗅探，或者可以由 Web 应用程序/Web 服务器指示不执行 MIME 嗅探。

解释：

X-Content-Type-Options 头允许您通过声明 MIME 类型是故意配置的来避免 MIME 类型嗅探。此头不是严格必需的，但出于安全原因强烈建议设置。虽然现代浏览器具有改进的安全功能，但您仍然可以设置此头以确保 Web 应用程序的安全。

您可以将 ABP 的安全头中间件 添加到请求管道中，以将 X-Content-Type-Options 设置为 no-sniff。此外，此中间件还会向您的应用程序添加其他预定义的安全头，包括 X-XSS-Protection、X-Frame-Options 和 Content-Security-Policy（如果已启用）。阅读安全头文档获取更多信息。

在本文档中