TL;博士：

是否有正当理由要求软件供应商停止在 Web 应用程序中使用 HTTPPUT和方法并仅使用和？该应用程序使用框架将允许的请求路径和方法列入白名单。DELETEGETPOST

换句话说，从安全的角度来看，在不更改其中的代码和安全检查的情况下允许通过任何一种方法DELETE或方法删除记录有什么不同吗？POST

完整的问题

我们的客户根据他们的公司标准配置了他们的 Tomcat 实例：

<security-constraint> 
    <web-resource-collection> 
        <web-resource-name>restricted methods</web-resource-name> 
        <url-pattern>/*</url-pattern> 
        <http-method>CONNECT</http-method> 
        <http-method>PUT</http-method> 
        <http-method>DELETE</http-method> 
        <http-method>OPTIONS</http-method> 
        <http-method>TRACE</http-method> 
    </web-resource-collection> 
    <user-data-constraint> 
        <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    </user-data-constraint> 
    <auth-constraint /> 
</security-constraint>

在Http Header Security Filter配置中，这使我们的应用程序中断。

我们的应用程序在 Spring Security 中提供了相同的HTTP Header 安全特性。此外，我们的应用程序是 RESTful 的，因此我们广泛使用文件上传PUT的DELETE方法。在未来的版本中，我们还计划使用 websockets（但从搜索结果来看，它们不使用用于代理的 CONNECT）。

我们的客户说他们必须在生产环境中提出一个策略例外，以便从 Tomcat 配置中删除有问题的行并使应用程序正常工作。

当供应商应用程序不符合安全要求时，将触发安全例外策略：1) 无法在计划内完成问题修复和 2) 未发现明显漏洞。例外政策需要高级管理层的批准。

但是，安全政策例外要求我们的客户在 6 个月内与供应商联系以“解决安全问题”。在 6 个月内，供应商必须提供成本和期限以满足安全政策。

这意味着他们将返回给我询问报价，以使应用程序与启用的 HTTP 方法过滤和 HTTP 标头安全过滤器一起工作。

我不想帮他们一个忙，将所有 Ajax 调用从 RESTful 模式更改为仅 GET/POST，如果可能的话，即使是为了钱也不要。相反，我想证明它们的安全实现不仅不兼容，而且就应用程序中的安全实现而言是多余的。

如果我们开创先例，通过 PUT 和 DELETE 请求帮助该客户，我们将不得不面对来自庞大客户群（所有银行和金融机构）的“与我的框架/政策/环境兼容”之类的请求。将来，这可能会不利于我们的成本管理。

问题是，就像在 TLDR 中一样，无论应用程序的安全功能如何，单独使用PUT和DELETE方法是否会带来安全风险？

如果证明唯一的 HTTP 动词不会造成安全风险，我将能够提出永久的例外政策，并与IT 人员进行有力的论证。

编辑

我在一家软件工厂工作，该工厂将相同的产品实例部署到大量客户和我们的云中。我们正在充分使用我们拥有的所有工具，包括 REST 模式。我们计划使用 HATEOAS、WebSockets、可恢复文件下载以及 Web 技术可以为我们提供的一切来提供更好的体验。是的，听起来像是一条营销路线。无论如何，安全性仍然是我们产品的一个问题。

4个回答

我怀疑这是一个人热心应用他们不理解的“最佳实践”的案例。

HTTP 动词篡改攻击

存在这种最佳实践的原因是 HTTP 动词篡改攻击。从这篇文章：

许多 Web 服务器身份验证机制使用基于动词的身份验证和访问控制。例如，管理员可以将 Web 服务器配置为允许使用 HTTP GET 请求不受限制地访问网页，但仅限管理员使用 POST。但是，许多基于动词的安全机制的实现以不安全的方式强制执行安全规则，允许通过使用替代 HTTP 方法（例如 HEAD）甚至任意字符串来访问受限资源。

所以有人决定，因为有些应用程序写得不好，所以应该禁止所有应用程序接受除 GET 或 POST 之外的 HTTP 动词，因为……你知道……咕哝咕哝安全！

我的意见（可能不完整/不正确，请发表评论）：

纯 HTML/CSS/js 内容应该限制为 GET 和 POST，因为这些是HTML 规范中唯一允许的动词。
应该允许 API（AJAX、REST）使用HTTP 规范中的任何动词，即：
- 请注意，即使您的应用程序层正确实施了基于动词的访问控制，您的网络服务器前端也可能没有，因此您应该为您的客户进行一些安全测试，并确保您的应用程序对所有应用程序实施正确的身份验证和访问控制你支持的动词。我建议遵循OWASP 测试指南。

听起来您的应用程序很好，而您的客户的安全策略过于狂热。

顺便说一句，HEAD 是一个有趣的例子。如果您的应用程序响应 HEAD 请求，一些安全扫描程序似乎会抱怨，因为某些应用程序将返回有效的标头而不调用正确的身份验证检查。但是，大多数设计合理的应用程序将处理完整的 GET，然后只返回标头，包括正确的content-length:. 因此，对于使用现代框架的应用程序，可能无法绕过 GET 控制器上的身份验证逻辑。做一些快速测试吧！ （感谢@usr-local-ΕΨΗΕΛΩΝ 在评论中指出这一点。有关 Spring MVC 如何处理此问题的详细信息，请参阅此 Stack Overflow 帖子。）

可以说，DELETE 和 PUT 比 GET/POST 更安全，因为它们不能用于 CSRF 攻击。同样可以说，DELETE 和 PUT 无论如何都应该受到 CSRF 的保护，因为将应用程序的安全性建立在假设每个浏览器实现都遵循标准是不好的。但是应用程序没有这种保护的情况并不少见，所以也许这就是禁令背后的想法，尽管我在这里有点。

或者他们可能只是禁用了所有不需要的方法（这是一个很好的做法），随着时间的推移，这些方法从默认变成了不可违反的规则。

我建议尽快让您的公司法律团队参与进来，以便有人专注于未来讨论的业务方面。

作为安全例外政策的一部分，我们客户的员工有义务在 6 个月内让供应商参与“修复安全问题”。

这意味着他们将返回给我，要求使应用程序与启用的 HTTP 方法过滤和 HTTP 标头安全过滤器一起工作。

我不想帮他们一个忙，将所有 Ajax 调用从 RESTful 模式更改为仅 GET/POST，甚至为了钱也不行。

您的客户显然在运行自己的官僚机构，执行不灵活的政策。你相信你有三种可能的路径：

说服他们改变他们的政策。
做出不受欢迎的改变。
冒着失去他们作为客户的风险。

尽管在你看来这是一个合乎逻辑的技术决定，但改变政策需要相当多的政治争论。在讨论的另一方与您打交道的人可能在他的公司中具有成功提出此类请求所需的地位，也可能没有。他可能不想浪费时间与自己的官僚作风来争取变革。如果他更换供应商并使用已经符合他们政策的其他人的产品，他的生活可能会容易得多。更糟糕的是，如果他只是更换供应商，他的老板的生活几乎肯定会更轻松。

如果你认为你可以成功地让他们改变他们的政策，而不为其他结果做一些认真的计划，那是不负责任的。

好客户很难得。你应该为你的公司仔细权衡失去一个的风险。

远程 API 可以这样设计，所以除了 GET 或 POST 之外的任何其他 http 方法都不会使用，例如：

DELETE /item/123

也许：

GET /delete/item/123

无论如何，您将不得不阅读 API 规范并弄清楚如何添加或删除项目，因此一个比另一个更好是 50/50 的论点。我更喜欢只有 GET 和 POST。

其它你可能感兴趣的问题

上一篇我应该只让我的电视连接到访客 WiFi 吗？下一篇在云服务上保持加密文件同步，无需每次上传整个加密卷