POST 和 Cookie 一样安全吗？
在实现基于 Flash 的上传器时，我们遇到了一个问题：Flash 未提供正确的 cookie。 我们需要通过 POST 变量传递 PHP 会话 ID。
我们提出并实现了一个功能性解决方案，检查 POST PHPSESSID。
发布会话 ID 与在 cookie 中发送会话 ID 一样安全吗？
可能的原因：因为两者都在 http 标头中，并且客户端同样有可能伪造。 反对的可能原因：因为伪造 POST 变量比伪造 Cookie 更容易。
While implementing a flash-based uploader, we were faced with an issue: Flash doesn't provide the correct cookies.
We need our PHP Session ID to be passed via a POST variable.
We have come up with and implemented a functional solution, checking for a POST PHPSESSID.
Is POSTing the Session ID as secure as sending it in a cookie?
Possible reason for: Because both are in the http header, and equally possible for a client to forge.
Possible reason against: Because it's easier to forge a POST variable than a Cookie.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
它同样安全——伪造 POST 与伪造 cookie 一样简单。 这些都是通过简单地在 cURL 中设置标志来完成的。
话虽这么说，我认为你也有一个很好的解决方案。
It is as secure — forging the POST is equally as easy as the cookie. These are both done by simply setting flags in cURL.
That being said, I think you've got a good solution as well.
如果您能够从活动内容中获取会话 ID 以便发布它，这可能意味着您的会话 cookie 未标记为 HttpOnly，我们的一位主机声称否则 防御跨站点脚本攻击的好主意。
考虑使用基于 JavaScript 甚至基于刷新的上传器监视器，它应该与 cookie 可以是 HttpOnly 的其他所有内容集成得足够好。
另一方面，如果您的站点不接受第三方内容，则跨站点脚本攻击可能不存在任何问题； 在这种情况下，POST 就可以了。
If you are able to obtain the session ID from active content in order to POST it, this presumably means that your session cookie is not marked HttpOnly, which one of our hosts claims is otherwise a good idea for defending against cross-site scripting attacks.
Consider instead a JavaScript-based or even refresh-based uploader monitor, which should integrate well enough with everything else that the cookie can be HttpOnly.
On the other hand, if your site does not accept third-party content, cross-site scripting attacks may not be of any concern; in that case, the POST is fine.
我认为通过 GET 发送它也可以正常工作，因为你可以在 HTTP 请求中伪造任何内容（使用curl甚至flash）。
重要的是 cookie/post/get 参数中加密的内容以及如何在服务器端加密和检查。
I think sending it via GET would also work fine, since you fake anything in a HTTP request (using curl or even flash).
The important thing is what is encrypted in you cookie/post/get parameter and how is it encrypted and checked on the server side.
确实，如果您担心哪一个更容易伪造，那么您担心的是错误的事情。 简而言之，对于经验丰富的攻击者来说，这两种方法都是微不足道的。 您可能会通过选择其中之一来排除“脚本小子”，但这些人并不是您需要担心的人。 您应该问自己的问题是“对于有人伪造身份证，您有什么防御措施？” 它会发生。 如果您的 ID 未加密并且很容易被猜到，那就是一个问题。 它会被黑客攻击。 既然你问哪个更安全，我就说你担心。
还有另一件事需要考虑，因为您的应用程序是 flash，所以它很容易被修改（就像 javascript HTML 代码一样），因为编译的代码位于攻击者的机器上。 他们可以查看二进制文件并弄清楚代码是如何工作的，以及需要从服务器检索什么。
Really if you are worried about which one is easier to forge, you're worrying about the wrong thing. Simply put, either will be trivial to an experienced attacker. You might keep out the "script kiddies" by choosing one over the other, but those people arern't the ones you need to be worried about. The question you should ask yourself is "what defenses do you have against someone forging an id?" It will happen. If your id is unencrypted, and easy to guess, that's a problem. It will get hacked. Since you are asking which is more secure, I would say that you are concerned.
Here's another thing to consider, since your application is flash, it's susceptable to modification (just like javascript HTML code), because the compiled code is on the attackers machine. They can look through the binary and figure out how the code works, and what it needs to retrieve from the server.
POST 数据不是 HTTP 标头，但它作为 TCP 流的一部分发送，这使得它与 HTTP 标头一样容易读取/伪造。 如果你截获了一个 HTTP 请求，它看起来会像这样：
正如其他人所说，POST 和 cookie（以及 GET 数据，即查询字符串）都很容易被欺骗，因为它们都只是同一个 HTTP 数据包中的文本。
POST data is not an HTTP header, but it is sent as part of the TCP stream which makes it just as easy to read/forge as an HTTP header. If you intercepted an HTTP request it would look something like this:
So as others have said, POST and cookies (and GET data, i.e. query strings) are all easy to spoof, since they're all just text in the same HTTP packet.
我只是想重申一下，Cookie 和 Post 同样不安全。
I just want to reiterate that both Cookie and Post are equally insecure.