在实施flash-based uploader时，我们遇到了一个问题：Flash doesn't provide the correct cookies。 我们需要通过POST变量传递我们的PHP会话ID。
我们已经提出并实施了一个功能解决方案，检查POST PHPSESSID。
将会话ID发布为在cookie中发送是否安全？
可能的原因：因为两者都在http标头中，并且客户端同样可以伪造。 可能的原因：因为伪造POST变量比使用Cookie更容易。
答案 0 :(得分：5)
这是安全的 - 伪造POST与cookie一样容易。这些都是通过简单地在cURL中设置标志来完成的。
话虽如此，我认为你也有一个很好的解决方案。
答案 1 :(得分：2)
如果您能够从活动内容中获取会话ID以进行发布，这可能意味着您的会话Cookie未标记为HttpOnly，我们的哪个主机声明为a good idea for defending against cross-site scripting attacks
相反，请考虑使用基于JavaScript或甚至基于刷新的上传器监视器，该监视器应该与cookie可以很好地集成其他所有内容。
另一方面，如果您的网站不接受第三方内容，跨网站脚本攻击可能没有任何问题;在这种情况下，POST很好。
答案 2 :(得分：2)
我认为通过GET发送它也可以正常工作，因为你在HTTP请求中伪造任何东西（使用curl甚至flash）。 重要的是你在cookie / post / get参数中加密了什么，以及如何在服务器端加密和检查。
答案 3 :(得分：1)
真的，如果你担心哪一个更容易伪造，你就会担心错误的事情。简而言之，对于经验丰富的攻击者来说，要么是微不足道的。你可以通过选择一个而不是另一个来阻止“脚本小子”，但那些人不是你需要担心的人。你应该问自己的问题是“你对一个伪造身份的人有什么防御？”它会发生。如果您的ID未加密且易于猜测，那就是一个问题。它会被黑客入侵。既然你在问哪个更安全，我会说你担心。
这是另一件需要考虑的事情，因为你的应用程序是flash，它很容易修改（就像javascript HTML代码一样），因为编译后的代码在攻击者机器上。他们可以浏览二进制文件并弄清楚代码是如何工作的，以及它需要从服务器检索什么。
答案 4 :(得分：0)
POST数据不是HTTP标头，但是它作为TCP流的一部分发送，这使得它像HTTP标头一样易于读取/伪造。如果您拦截了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数据包中的文本。
答案 5 :(得分：0)
我只想重申，Cookie和Post同样不安全。