Php 在会话中存储什么？

我知道关于会话固定和劫持的所有问题。我的问题非常基本：我想用PHP创建一个身份验证系统。为此，在登录之后，我将只在会话中存储用户id

但是：我看到一些人做了一些奇怪的事情，比如为每个用户和会话生成一个GUID，并将其存储在会话中，而不仅仅是用户id。为什么?

---

客户机无法获取会话的内容，或者可以吗？

您是对的。客户端只看到随机生成的会话id令牌。这个令牌有可能被误用（劫持等），但上面有一个GUID不会增加任何东西。相反，类似（JavaScript看不到会话cookie）（cookie只能通过HTTPS传输）的选项可以防止某些攻击场景。

有时，为了增加安全性，开发人员可能会为用户的会话分配一个长字符串，以使劫持更加困难。通过在会话创建时使用此新字符串设置cookie，应用程序可以在后续请求中检查正确的字符串，以更好地确保它是实际登录的人

这只是增加了一个想要劫持的人不得不猜测的事情。但是，这可能是一种错误的安全感，因为如果涉及嗅探，它对保护会话几乎没有什么作用，因为新的cookie会与php会话cookie一起发送。另外，会话id很难猜测（我相信你知道，只是不要把它放在url中，而是放在cookie中）

---

会话信息存储在硬盘上，因此客户端无法在没有应用程序干预的情况下获取会话信息。

我从未见过用于会话的GUID，但我见过一些额外的方法，它们确实增加了一些安全性

• 存储用户的IP—如果您需要根据位置强制更改会话（有时geoIP工具会这样做）
• 存储用户的HTTP\U user\U代理头字符串。如果劫机者恰好使用不同的浏览器，则可以提供一点防止劫机的安全性

实际上，维基百科上有一篇很棒的文章

---

话虽如此，我认为任何将GUID存储为会话的一部分以用于会话安全性的人都可能看不到更好的解决方案（例如会话重新生成）。我可以看到存储GUID的其他用途（可能是游戏随机生成器的一部分），但不用于会话安全。

简单的回答是，$\u会话是安全的，您不必担心其内容泄露给用户或攻击者

用户通常无法访问会话的内容。您应该能够存储用户的主键，这样您就没事了。在某些情况下，会话可能会泄漏，在正常的linux系统上，会话文件夹位于/tmp中，但是可以在php.ini中将其更改为web根目录（/var/www/tmp），然后可以访问。唯一的另一种方法是，如果用户能够通过劫持对eval（）的调用或通过正常打印的变量访问$\u会话超级全局

---

如果您在共享主机上运行并且使用旧版本的PHP和/或您的服务器配置错误，则此系统上的其他用户可能会读取或修改存储在/tmp/中的会话文件。我不知道有哪个应用程序会考虑这种攻击。如果这是一个问题，您可以将信息存储在数据库的

会话

表中。

我不明白这应该如何提高安全性：如果黑客得到了其他人的HTTP头，他只会复制整个Cookie头-他就这样做了。黑客如何在没有嗅探的情况下获得会话id？这就是为什么我说“如果涉及嗅探，那么它对保护会话几乎没有什么作用，因为新的cookie会与php会话cookie一起发送。”我编辑添加了“虚假安全感”把这一点带回家。@eWolf在愚蠢的情况下，会话是通过get而不是POST发送的，你可以获得会话id而无需嗅探：当用户复制URL并粘贴到某个地方时，他已经给出了自己的会话id。无论如何，这与此无关。要添加到eWolf，他们还可以尝试强行添加。只需添加，有些人不幸的ISP经常更改他们的ip地址（有时每隔几分钟！），因此在会话中包装ip可能会引起太多的麻烦。@webbiedave-是的，除非有很好的理由，否则我不会使用它。除非你愿意接受随之而来的问题，否则有很多理由不使用它。HTTP_USER_代理对任何攻击都提供零保护，因为它是一个用户控制的变量。@Rook-显然它是一个用户控制的变量，你会错误地依赖它。但是，您可以将其用作指示在上次看到会话id和这次之间发生了更改，并强制重新生成会话。会话id也是一个用户控制的变量，但我看不到您提到过这一点。会话安全性是多层次的假设，如果不加密整个传输，就不可能有真正的安全性。我认为，建议人们实施不值得忽视的安全系统是有害的。也许你没有意识到愚弄这样一个系统是多么容易。还要记住，如果攻击者使用xss或嗅探该行，他们将能够在http头中看到用户代理。