POST 和 Cookie 一样安全吗？

Question

在实现基于闪存的上传器时，我们遇到了一个问题： Flash 没有提供正确的 cookies 。 我们需要通过 POST 变量传递我们的 PHP Session ID。

我们提出并实施了一个功能性解决方案，检查 POST PHPSESSID。

发布 Session ID 是否与在 cookie 中发送一样安全？

可能的原因：因为两者都在 http header 中，并且同样可能由客户伪造。 反对的可能原因：因为伪造 POST 变量比伪造 Cookie 更容易。

Answer 1

它和 cookie 一样安全——伪造 POST 和 cookie 一样容易。 这些都是通过简单地在 cURL 中设置标志来完成的。

话虽如此，我认为您也有一个很好的解决方案。

Answer 2

如果您能够从活动内容中获取 session ID 以便发布它，这可能意味着您的 session cookie 未标记HttpOnly ，我们的一位主机声称这是防御跨站点脚本攻击的好主意。

相反，考虑一个基于 JavaScript 甚至基于刷新的上传器监视器，它应该与其他所有东西很好地集成，cookie 可以是 HttpOnly。

另一方面，如果您的站点不接受第三方内容，跨站点脚本攻击可能不会有任何问题； 在这种情况下，POST 很好。

Answer 3

我认为通过 GET 发送它也可以正常工作，因为你在 HTTP 请求中伪造任何东西（使用 curl 甚至闪存）。 重要的是在你的 cookie/post/get 参数中加密了什么，以及它是如何在服务器端加密和检查的。

Answer 4

真的，如果您担心哪个更容易伪造，那么您担心的是错误的事情。 简而言之，对于有经验的攻击者来说，两者都是微不足道的。 您可能会通过选择一个而不是另一个来避开“脚本小子”，但这些人并不是您需要担心的人。 您应该问自己的问题是“您对伪造身份的人有什么防御措施？” 它会发生。 如果您的 id 未加密且容易猜到，那就有问题了。 它会被黑客入侵。 既然你问哪个更安全，我会说你很担心。

还有一点需要考虑，因为你的应用程序是 flash，它很容易被修改（就像 javascript HTML 代码一样），因为编译的代码在攻击者机器上。 他们可以查看二进制文件并弄清楚代码是如何工作的，以及它需要从服务器检索什么。

Answer 5

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. 如果你截获了一个 HTTP 请求，它看起来像这样：

POST /path/to/script HTTP/1.1
Host: yourdomain.com
User-Agent: Mozilla/99.9 (blahblahblah)
Cookie: __utma=whateverthisisacookievalue;phpsessid=somePHPsessionID

data=thisisthepostdata&otherdata=moredummydata&etc=blah

正如其他人所说，POST 和 cookies（以及 GET 数据，即查询字符串）都很容易被欺骗，因为它们都只是同一个 HTTP 数据包中的文本。

Answer 6

我只想重申 Cookie 和 Post 都同样不安全。