GET 或 POST 哪个更安全？

Question

将 HTTP GET 与 HTTP POST 进行比较时，从安全角度来看有何区别？一种选择天生就比另一种更安全吗？如果是这样，为什么？

我意识到 POST 不会在 URL 上公开信息，但它有任何真正的价值，还是只是通过默默无闻的安全性？当安全性受到关注时，有没有理由我应该更喜欢 POST？

编辑：

通过 HTTPS，POST 数据被编码，但是 URL 可以被第 3 方嗅探吗？此外，我正在处理 JSP；使用 JSP 或类似框架时，可以说最佳做法是避免将敏感数据完全放在 POST 或 GET 中，而是使用服务器端代码来处理敏感信息吗？

原文由 James McMahon 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

就安全性而言，它们本质上是相同的。虽然 POST 确实不通过 URL 公开信息，但在客户端和服务器之间的实际网络通信中，它公开的信息与 GET 一样多。如果您需要传递敏感信息，您的第一道防线就是使用安全 HTTP 传递它。

GET 或查询字符串帖子对于为特定项目添加书签或协助搜索引擎优化和索引项目所需的信息非常有用。

POST 适用于用于提交一次性数据的标准表单。我不会使用 GET 来发布实际表单，除非在搜索表单中您希望允许用户将查询保存在书签或类似的东西中。

原文由 stephenbayer 发布，翻译遵循 CC BY-SA 2.5 许可协议

Answer 2

GET 请求的安全性略低于 POST 请求。两者本身都不能提供真正的“安全”；使用 POST 请求 不会 神奇地使您的网站免受明显数量的恶意攻击。但是，使用 GET 请求 会使 原本安全的应用程序变得不安全。

“不得使用 GET 请求进行更改”的格言仍然非常有效，但这与 恶意 行为关系不大。登录表单对使用错误的请求类型发送最敏感。

搜索蜘蛛和网络加速器

这是您应该使用 POST 请求更改数据的真正原因。搜索蜘蛛会跟踪您网站上的每个链接，但不会提交他们找到的随机表格。

Web 加速器比搜索蜘蛛更糟糕，因为它们在客户端机器上运行，并 _在登录用户的上下文中_“单击”所有链接。因此，使用 GET 请求删除内容的应用程序，即使它需要管理员，也会愉快地服从（非恶意！）网络加速器的命令并 删除它看到的所有内容。

糊涂副攻

无论您使用 GET 还是 POST 请求，都可能 发生混淆代理攻击（代理是浏览器）。

在攻击者控制的网站上，GET 和 POST 无需用户交互即可 轻松提交。

POST 稍微不易受影响的唯一场景是许多不受攻击者控制的网站（例如，第三方论坛）允许嵌入任意图像（允许攻击者注入任意 GET 请求），但阻止所有注入任意 POST 请求的方法，无论是自动的还是手动的。

有人可能会争辩说网络加速器是混淆代理攻击的一个例子，但这只是一个定义问题。如果有的话，恶意攻击者无法控制这一点，所以即使代理人 感到 困惑，也很难算作 _攻击_。

代理日志

代理服务器可能会完整地记录 GET URL，而不会删除查询字符串。通常不记录 POST 请求参数。在这两种情况下都不太可能记录 Cookie。 （例子）

这是支持 POST 的非常薄弱的论据。首先，可以完整记录未加密的流量；恶意代理已经具备了它所需要的一切。其次，请求参数对攻击者的用途有限：他们真正需要的是 cookie，因此如果他们唯一拥有的是代理日志，他们不太可能能够攻击 GET 或 POST URL。

登录请求有一个例外：这些请求往往包含用户密码。将其保存在代理日志中会打开一个在 POST 情况下不存在的攻击向量。然而，无论如何，通过纯 HTTP 登录本质上是不安全的。

代理缓存

缓存代理可能会保留 GET 响应，但不会保留 POST 响应。话虽如此，与将 URL 转换为 POST 处理程序相比，可以更轻松地将 GET 响应设置为不可缓存。

HTTP“推荐人”

如果用户要从响应 GET 请求的页面导航到第三方网站，则该第三方网站会看到所有 GET 请求参数。

属于“向第三方泄露请求参数”的范畴，其严重程度取决于那些参数中存在的内容。 POST 请求自然不受此影响，但是要利用 GET 请求，黑客需要在服务器的响应中插入指向他们自己网站的链接。

浏览器历史

这与“代理日志”参数非常相似：GET 请求与其参数一起存储在浏览器历史记录中。如果攻击者可以物理访问机器，则他们可以轻松获得这些信息。

浏览器刷新操作

一旦用户点击“刷新”，浏览器将重试 GET 请求。在关闭后恢复选项卡时可能会这样做。因此，任何动作（例如，付款）都将在没有警告的情况下重复。

浏览器不会在没有警告的情况下重试 POST 请求。

这是仅使用 POST 请求更改数据的一个很好的理由，但与恶意行为无关，因此与安全性无关。

所以我该怎么做？

• 仅使用 POST 请求更改数据，主要是出于与安全无关的原因。
• 仅对登录表单使用 POST 请求；否则会引入攻击向量。
• 如果您的站点执行敏感操作，您确实需要知道他们在做什么的人，因为这不能在一个答案中涵盖。您需要使用 HTTPS、HSTS、CSP、缓解 SQL 注入、 脚本注入 (XSS) 、 CSRF 以及可能特定于您的平台的大量其他东西（例如各种框架中的批量分配漏洞： ASP.NET MVC 、 Ruby on Rails 等）。没有任何一件事可以区分“安全”（不可利用）和“不安全”。

---

通过 HTTPS，POST 数据被编码，但是 URL 可以被第 3 方嗅探吗？

不，它们不能被闻到。但 URL 将存储在浏览器历史记录中。

可以公平地说，最佳做法是避免将敏感数据完全放在 POST 或 GET 中，而是使用服务器端代码来处理敏感信息吗？

取决于它有多敏感，或者更具体地说，以何种方式。显然客户会看到它。任何可以物理访问客户端计算机的人都可以看到它。客户可以在将其发回给您时进行欺骗。如果这些很重要，那么是的，将敏感数据保存在服务器上，不要让它离开。

原文由 John Gietzen 发布，翻译遵循 CC BY-SA 4.0 许可协议