我的 Web 服务器在提交 POST 请求后返回 200 OK，但根据安全团队的说法，这似乎不是一个好主意。
它应该返回 302“对象已移动”，以避免缓存敏感信息。
“如果表单通过 POST 请求发布敏感数据，服务器应返回 302“对象已移动”响应，以将用户重定向到不同的页面。这样可以避免缓存敏感信息”
对我来说，返回 HTTP 状态代码实际上取决于 Web 应用程序和它使用的框架以及它是如何设计的。
不确定每个 POST 请求是否应导致 302。如果我登录网站而不是重定向，则返回 200 OK。
只要它是通过 SSL 上的 POST 请求来完成的，我就看不到它有问题。各位大神能帮我解答一下吗？
这个问题似乎与选择的 HTTP 响应方法有关，它对缓存的影响。有关该问题的答案，请参阅下面的“POST 缓存”。
OP 在评论中的澄清表明，安全团队担心浏览器会记住输入到字段表单中的值，以便“返回”或“自动完成”使用可以访问它们。这与服务器选择发出的 HTTP 响应完全无关；即使使用了重定向，也只会增加返回信息所需的“返回”点击次数。
HTML 表单自动完成属性和HTML 输入自动完成属性用于请求浏览器不要记住输入的值。但是，这些是要求，而不是禁止。浏览器可以做任何他们想做的事情，并且众所周知，他们会忽略或误解这些标签，并免除他们认为有趣的任何事情。例如，Chrome 就有这样的东西，“off”不起作用但“false”起作用。
所以 - 你可以做一些事情来帮助它，但不能控制它。302 而不是 200 不是其中之一。
POST 缓存
除非响应中的其他 HTTP 标头特别请求它，否则不会缓存具有 200 响应的 POST。请参阅是否可以在 HTTP 中缓存 POST 方法？来自 StackOverflow；引用他们对RFC 2616的引用：
9.5 发布
...
对此方法的响应是不可缓存的，除非响应包含适当的 Cache-Control 或 Expires 标头字段。但是，303（请参阅其他）响应可用于指示用户代理检索可缓存资源。
您的安全团队有一个很好的想法，但没有询问 HTTP 的架构师是否首先拥有同样的好想法。
实际上，这就是为什么当您尝试重新加载作为 POST 表单提交响应的页面时浏览器会提示您的原因- 它告诉您请求将被重新传输到服务器，因为浏览器没有缓存原始响应。
我听说过这个问题，是的，这是您可以在许多使用实时 HTTP 标头扩展的 Web 应用程序中观察到的问题。他们实际上返回 302 而不是 200 作为状态码。但是，还有其他控件应该组合使用，HTTP 缓存控制标头。
关于 SSL；当您提到在传输过程中观察凭证没有额外风险时，您是对的。该解决方案解决的问题处于早期阶段 - 浏览器本身。曾经有一段时间，您可以注销 Web 应用程序并点击返回按钮重新登录。如果 Web 应用程序破坏了会话，这甚至可以工作，因为浏览器缓存包含身份验证凭据并重新进行身份验证。因此，这解决的问题是使用浏览器的任何人都无法使用以前使用和缓存的凭据进行身份验证。
重定向到不同站点不会使浏览器忘记输入表单的数据。如果你回到历史，那么它们仍然可以重新提交。无论如何，试图从敏感数据中“清除”浏览器可能是有问题的，因为攻击者需要深入浏览器内部才能访问这些数据，在这种情况下，他可能已经在输入数据时就已经捕获了这些数据进入页面或发送到服务器，这可能需要更少的努力。
据我了解，安全团队报告的调查结果是有效的。让我们来看看他们可能报告的场景，因为我也在手动应用程序评估中看到了这一点。
场景1：以应用程序的登录页面为例，或者更好的是信用卡申请表。在填写完所有表单字段并单击“提交”按钮后，客户端会在 POST 请求中将敏感数据发送到服务器。如果服务器响应是“200 OK”，浏览器会将 POST 数据保存在浏览器内存中，以允许重放攻击。如之前的回复中所述，可以点击“后退”按钮，然后点击“转发”，然后点击“刷新”，浏览器将再次重新发送敏感的 POST 数据。您通常会从浏览器收到一条弹出消息，告知您它将重新发送之前发送的数据。
场景 2：相同的数据通过 POST 请求发送到服务器。这一次，服务器返回一些 300 类型的状态代码，可能是一个 302 重定向，它将客户端发送到下一页。然而，收到 300 类型响应的客户端浏览器不会在浏览器内存中维护或缓存 POST 的数据。您不能重复后退、前进、刷新实验，并希望看到以前发布的数据重播。这完全取决于服务器响应。
如果您可以访问本地代理（例如 Burp），则可以自行测试。将浏览器设置为指向您的代理。访问易受攻击的网页。填写字段，点击提交，然后查看在您的代理工具中发送的请求。您应该会在 POST 请求的数据部分看到包含敏感数据的各种表单字段。假设服务器响应是“200 OK”，则进入下一步。在浏览器上，点击后退按钮，然后前进，然后刷新。您应该从浏览器中收到弹出消息，提醒您它即将重新发送以前发送的数据。点击确定。现在查看代理工具中的最后一个请求。它将重新发送 POST 请求和之前的相同敏感数据。现在，在返回 302 重定向到 POST 数据的网站上尝试同样的实验。
那么，您可能会问的风险或威胁是什么？首先是重放攻击。您最关心的应该是恶意软件。您的第二大威胁向量将是共享设备。令人担忧的是，恶意软件或有权访问设备的人可能会“重放”请求，然后能够看到在 POST 请求中发送的敏感数据。恶意软件只会直接从浏览器内存中读取数据。一个人将不得不使用工具再次查看 POST 请求。
***一些注意事项：
*使用 Autocomplete=off 只会阻止数据存储在表单字段存储容器中。它独立于这个问题，并且与这个问题无关。但是，我建议确保任何接受敏感信息的表单字段都应将自动完成设置为“关闭”。恶意软件经常查找并读取保存的表单字段数据，因为它通常包含大量信息。
**使用缓存控制标头也与此问题无关，因为它适用于缓存到磁盘的页面（临时 Internet 目录）。同样，您应该使用缓存控制指令并防止敏感数据以明文形式存储在系统上。
*** 对 json 请求中 POST 的数据的“200 OK”响应不是问题。这是我能想到的唯一一种情况，当服务器以“200 OK”响应时，您无法执行重放攻击。
希望这可以帮助。由于攻击向量的限制，我确信它没有被列为高等级漏洞。它只是安全洋葱中无数层中的一层！