在实现基于Flash 的上传器时，我们遇到了一个问题：Flash 没有提供正确的 cookie。我们需要通过 POST 变量传递 PHP 会话 ID。
我们提出并实施了一个功能性解决方案，检查 POST PHPSESSID。
发布会话 ID 是否与在 cookie 中发送会话 ID 一样安全？
可能的原因：因为两者都在 http 标头中，并且客户端同样有可能伪造。反对的可能原因：因为伪造 POST 变量比伪造 Cookie 更容易。
Dean
问问题
796 次
6 回答
5
它和 cookie 一样安全——伪造 POST 和 cookie 一样容易。这些都是通过简单地在 cURL 中设置标志来完成的。
话虽如此，我认为您也有一个很好的解决方案。
于 2009-02-26T01:56:07.077 回答
2
如果您能够从活动内容中获取会话 ID 以便发布它，这可能意味着您的会话 cookie 没有标记为HttpOnly，我们的一位主机声称这是防御跨站点脚本攻击的好主意。
相反，考虑一个基于 JavaScript 甚至基于刷新的上传器监视器，它应该与其他所有东西很好地集成，cookie 可以是 HttpOnly。
另一方面，如果您的站点不接受第三方内容，跨站点脚本攻击可能不会有任何问题；在这种情况下，POST 很好。
于 2009-02-26T01:57:47.853 回答
2
我认为通过 GET 发送它也可以正常工作，因为你在 HTTP 请求中伪造了任何东西（使用 curl 甚至 flash）。重要的是在你的 cookie/post/get 参数中加密了什么，以及它是如何在服务器端加密和检查的。
于 2009-02-26T01:59:50.280 回答
1
真的，如果您担心哪个更容易伪造，那么您担心的是错误的事情。简而言之，对于有经验的攻击者来说，两者都是微不足道的。您可能会通过选择一个而不是另一个来避开“脚本小子”，但这些人并不是您需要担心的人。您应该问自己的问题是“您对伪造身份的人有什么防御措施？” 它会发生。如果您的 id 未加密且容易猜到，那就有问题了。它会被黑客入侵。既然你问哪个更安全，我会说你很担心。
这里还有一点需要考虑，因为你的应用程序是 flash，它很容易被修改（就像 javascript HTML 代码一样），因为编译的代码在攻击者的机器上。他们可以查看二进制文件并弄清楚代码是如何工作的，以及它需要从服务器检索什么。
于 2009-02-26T02:19:05.553 回答
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 和 cookie（以及 GET 数据，即查询字符串）都很容易被欺骗，因为它们都只是同一个 HTTP 数据包中的文本。
于 2009-02-26T02:03:45.390 回答
0
我只想重申 Cookie 和 Post 都同样不安全。
于 2009-02-26T04:19:46.967 回答