用户登录时，我需要在php会话中存储什么？

Currently when user logged in, i created 2 sessions.

目前，当用户登录时，我创建了2个会话。

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name

So that, those page which requires logged in, i just do this:

那么，那些需要登录的页面，我只是这样做：

if(isset($_SESSION['logged_id'])){
// Do whatever I want
}

Is there any security loopholes? I mean, is it easy to hack my session? How does people hack session? and how do I prevent it??

有没有安全漏洞？我的意思是，攻击我的会话容易吗？人们如何破解会话？以及如何防止它？

EDIT:

编辑：

Just found this:

刚发现这个：

http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script

http://www.xrvel.com/post/353/programming/make-a-secure-session-login-script

http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/

http://net.tutsplus.com/tutorials/php/secure-your-forms-with-form-keys/

Just found the links, are those methods good enough?? Please give your opinions. I still have not get the best answer yet.

刚刚找到链接，这些方法是否足够好？请提出你的意见。我还没有得到最好的答案。

9 个解决方案

#1

Terminology

• User: A visitor.
• 用户：访客。
• Client: A particular web-capable software installed on a particular machine.
• 客户端：安装在特定计算机上的特定Web功能的软件。

---

Understanding Sessions

In order to understand how to make your session secure, you must first understand how sessions work.

为了了解如何确保会话安全，您必须首先了解会话的工作方式。

Let's see this piece of code:

让我们看看这段代码：

session_start();

As soon as you call that, PHP will look for a cookie called PHPSESSID (by default). If it is not found, it will create one:

一旦你调用它，PHP就会寻找一个名为PHPSESSID的cookie（默认情况下）。如果找不到，它将创建一个：

PHPSESSID=h8p6eoh3djplmnum2f696e4vq3

If it is found, it takes the value of PHPSESSID and then loads the corresponding session. That value is called a session_id.

如果找到，则获取PHPSESSID的值，然后加载相应的会话。该值称为session_id。

That is the only thing the client will know. Whatever you add into the session variable stays on the server, and is never transfered to the client. That variable doesn't change if you change the content of $_SESSION. It always stays the same until you destroy it or it times out. Therefore, it is useless to try to obfuscate the contents of $_SESSION by hashing it or by other means as the client never receives or sends that information.

这是客户唯一知道的事情。无论您添加到会话变量中的任何内容都保留在服务器上，并且永远不会转移到客户端。如果更改$ _SESSION的内容，则该变量不会更改。它会一直保持不变，直到你摧毁它或它超时。因此，尝试通过散列它或其他方式来混淆$ _SESSION的内容是没有用的，因为客户端从不接收或发送该信息。

Then, in the case of a new session, you will set the variables:

然后，在新会话的情况下，您将设置变量：

$_SESSION['user'] = 'someuser';

The client will never see that information.

客户永远不会看到这些信息。

---

The Problem

A security issue may arise when a malicious user steals the session_id of an other user. Without some kind of check, he will then be free to impersonate that user. We need to find a way to uniquely identify the client (not the user).

当恶意用户窃取其他用户的session_id时，可能会出现安全问题。如果没有某种检查，他就可以*地冒充该用户。我们需要找到一种方法来唯一地识别客户端（而不是用户）。

One strategy (the most effective) involves checking if the IP of the client who started the session is the same as the IP of the person using the session.

一种策略（最有效）涉及检查启动会话的客户端的IP是否与使用会话的人员的IP相同。

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}

// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    die('Session MAY have been hijacked');
}

The problem with that strategy is that if a client uses a load-balancer, or (on long duration session) the user has a dynamic IP, it will trigger a false alert.

该策略的问题在于，如果客户端使用负载均衡器，或者（在长持续时间会话中）用户具有动态IP，则会触发错误警报。

Another strategy involves checking the user-agent of the client:

另一个策略涉及检查客户端的用户代理：

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}

// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
    die('Session MAY have been hijacked');
}

The downside of that strategy is that if the client upgrades it's browser or installs an addon (some adds to the user-agent), the user-agent string will change and it will trigger a false alert.

该策略的缺点是，如果客户端升级其浏览器或安装插件（一些添加到用户代理），则用户代理字符串将更改，并将触发虚假警报。

Another strategy is to rotate the session_id on each 5 requests. That way, the session_id theoretically doesn't stay long enough to be hijacked.

另一种策略是在每5个请求上轮换session_id。这样，session_id理论上不会长时间被劫持。

if(logging_in()) {
    $_SESSION['user'] = 'someuser';
    $_SESSION['count'] = 5;
}

// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
    session_regenerate_id();
    $_SESSION['count'] = 5;
}

You may combine each of these strategies as you wish, but you will also combine the downsides.

您可以根据需要组合这些策略中的每一个，但您也会将缺点结合起来。

Unfortunately, no solution is fool-proof. If your session_id is compromised, you are pretty much done for. The above strategies are just stop-gap measures.

不幸的是，没有任何解决方案是万无一失的。如果你的session_id被破坏了，你就完成了。上述策略只是权宜之计。

#2

This is ridiculous.

这是荒唐的。

Session hijacking occurs when (usually through a cross site scripting attack) someone intercepts your sessionId (which is a cookie automatically sent to the web server by a browser).

会话劫持发生在（通常通过跨站点脚本攻击）某人拦截您的sessionId（这是一个由浏览器自动发送到Web服务器的cookie）时。

Someone has posted this for example:

有人发布了这个例子：

So when the user log in:

所以当用户登录时：

// not the most secure hash! $_SESSION['checksum'] = md5($_SESSION['username'].$salt);

//不是最安全的哈希！ $ _SESSION ['checksum'] = md5（$ _ SESSION ['username']。$ salt）;

And before entering a sensitive area:

在进入敏感区域之前：

if (md5($_SESSION['username'].$salt) != $_SESSION['checksum']) {
handleSessionError(); }

if（md5（$ _ SESSION ['username']。$ salt）！= $ _SESSION ['checksum']）{handleSessionError（）; }

Lets go through what is wrong with this

让我们来解决这个问题

1. Salts - Not wrong, but pointless. No one is cracking your damn md5, who cares if it is salted
2. 盐 - 没错，但没有意义。没有人会破坏你该死的md5，谁在乎它是否被盐腌
3. comparing the md5 of a SESSION variable with the md5 of the same variable stored in the SESSION - you're comparing session to session. If the thing is hijacked this will do nothing.
4. 将SESSION变量的md5与存储在SESSION中的同一变量的md5进行比较 - 您将会话与会话进行比较。如果东西被劫持，这将无能为力。

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name
$_SESSION['hash']      = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']);

// user's name hashed to avoid manipulation

//用户名称哈希以避免操纵

Avoid manipulation by whom? magical session faeries? Your session variables will not be modified unless your server is compromised. The hash is only really there to nicely condense your string into a 48 character string (user agents can get a bit long).

避免被谁操纵？神奇的会议仙境？除非您的服务器受到损害，否则不会修改您的会话变量。哈希只是真正将你的字符串很好地压缩成一个48个字符的字符串（用户代理可以有点长）。

At least however we're now checking some client data instead of checking SESSION to SESSION data, they've checked the HTTP_USER_AGENT (which is a string identifying the browser), this will probably be more than enough to protect you but you have to realise if the person has already taken your sessionId in someway, chances are you've also sent a request to the bad guys server and given the bad guy your user agent, so a smart hacker would spoof your user agent and defeat this protection.

至少我们现在检查一些客户端数据而不是检查SESSION到SESSION数据，他们检查了HTTP_USER_AGENT（这是一个标识浏览器的字符串），这可能足以保护你但你必须意识到如果这个人已经在某个时候已经开始使用你的sessionId，你很可能也会向坏人服务器发送一个请求并给你的用户代理坏人，所以聪明的黑客会欺骗你的用户代理并破坏这种保护。

Which is were you get to the sad truth.

你是谁得到了悲伤的事实。

As soon as your session ID is compromised, you're gone. You can check the remote address of the request and make sure that stays the same in all requests ( as I did ) and that'll work perfectly for 99% of your client base. Then one day you'll get a call from a user who uses a network with load balanced proxy servers, requests will be coming out from here through a group of different IPs (sometimes even on the wrong network) and he'll be losing his session left right and centre.

一旦您的会话ID被泄露，您就会离开。您可以检查请求的远程地址，并确保在所有请求中保持相同（就像我所做的那样），这对于99％的客户群来说都是完美的。然后有一天你会接到一个使用带有负载平衡代理服务器的网络的用户的电话，请求将通过一组不同的IP（有时甚至在错误的网络上）从这里出来，他将失去他的会话左右中心。

#3

You can find a guide on session security in PHP here.

您可以在此处找到PHP中的会话安全性指南。

#4

You can store the IP address, browser signature, etc. to identify the user. At each request, check it against the current values to see if anything suspicious happened.

您可以存储IP地址，浏览器签名等以识别用户。在每个请求中，根据当前值检查它以查看是否发生了任何可疑事件。

Be aware that some people are behind providers that use absolutely dynamic IP addresses, so those people might get often logged out.

请注意，有些人支持使用绝对动态IP地址的提供商，因此这些人可能会经常登出。

#5

I guess the second one needs to be 'logged_in'?

我想第二个需要'logged_in'？

Some resources regarding session security:

有关会话安全的一些资源：

phpsec

phpsec

shiflett

shiflett

#6

You can steal sessions via javascript (XSS->crossside scripting attack).. You should always use a salted MD5 Hash to secure your session.

你可以通过javascript（XSS-> crossside脚本攻击）窃取会话..你应该总是使用盐腌的MD5哈希来保护你的会话。

To avoid session hijacking, you should put the user agent

为避免会话劫持，您应该放置用户代理

$_SERVER['HTTP_USER_AGENT']

$ _ SERVER [ 'HTTP_USER_AGENT']

into the hash as well.

也进入哈希。

In your example:

在你的例子中：

$_SESSION['logged_in'] = 1;
$_SESSION['username']  = $username; // user's name
$_SESSION['hash']      = md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT']); // user's name hashed to avoid manipulation

Before using the session, make sure it uses the correct hash:

在使用会话之前，请确保它使用正确的哈希：

if (!$_SESSION['hash']==md5($YOUR_SALT.$username.$_SERVER['HTTP_USER_AGENT'])){
  die ('session hash not corrected')
}

#7

To prevent session fixation, which is basically guessing the SID or stealing it using various methods. NO matter how sophistacated your session logic is, it will definitely be vulnerable to sessid stealing to some degree. That's why you have to regenerate the ID everytime you do something important. For example if you're gonna be making a post or changing a setting in the admin, first run session-regenerate-id. Then the hacker has to go through the process of hacking you again. This basically gives the hacker a one time shot with an ID with all the time he wasted.

防止会话固定，这基本上是猜测SID或使用各种方法窃取它。无论你的会话逻辑是多么复杂，它肯定会在某种程度上容易受到偷窃行为的攻击。这就是为什么每次做重要事情时都必须重新生成ID。例如，如果您要在管理员中发帖或更改设置，请先运行session-regenerate-id。然后黑客必须再次经历黑客入侵的过程。这基本上可以让黑客一次性使用ID，并且浪费了所有时间。

http://us.php.net/manual/en/function.session-regenerate-id.php

http://us.php.net/manual/en/function.session-regenerate-id.php

Or you can change the id every so turns

或者你也可以改变id

if($_SESSION['counter']==3) {session_regenerate_id();$_SESSION['counter']==0}

if（$ _ SESSION ['counter'] == 3）{session_regenerate_id（）; $ _ SESSION ['counter'] == 0}

Also, $_SERVER['HTTP_USER_AGENT'] isn't very reliable. Try to avoid it not only for that reason, but because it's convenient for hackers bc they know agents are widely used for this. Instead try using $_SESSION['id_token'] = sha1(some crazy info like file memory, filename, time).

另外，$ _SERVER ['HTTP_USER_AGENT']不是很可靠。试着避免它，不仅仅是因为这个原因，而且因为它对黑客来说很方便，因为他们知道代理商广泛使用它。而是尝试使用$ _SESSION ['id_token'] = sha1（一些疯狂的信息，如文件内存，文件名，时间）。

#8

This is the usual log-in code, some improvements can be made to make it harder to break. First, you can do a checksum with the username and the time of the log in or alternatively, a predefined string (or a salt), and store it in the session, and compare it.

这是通常的登录代码，可以进行一些改进以使其更难破解。首先，您可以使用用户名和登录时间进行校验和，或者使用预定义的字符串（或盐），并将其存储在会话中，并进行比较。

So when the user log in:

所以当用户登录时：

// not the most secure hash!
$_SESSION['checksum'] = md5($_SESSION['username'].$salt); 

And before entering a sensitive area:

在进入敏感区域之前：

if (md5($_SESSION['username'].$salt) != $_SESSION['checksum'])
{
  handleSessionError();
}

By default, sessions are often store as files on the server side, and a cookie is put on the user's browser to remember which file to refer to. When it comes to session hacking, somehow the hacker retrieve enough information to duplicate the log-in or managed to change the session data, by using information from the cookie.

默认情况下，会话通常作为文件存储在服务器端，并在用户的浏览器上放置cookie以记住要引用的文件。当谈到会话黑客时，黑客通过使用来自cookie的信息以某种方式检索足够的信息以复制登录或管理以更改会话数据。

You could code your own session handling using databases for added security. Some stricter CMS, like Joomla, also logs the IP. However, this cause problems for people using certain ISP

您可以使用数据库编写自己的会话处理代码以增加安全性。一些更严格的CMS，如Joomla，也记录了IP。但是，这会导致使用某些ISP的人员出现问题

#9

When I was encountering this issue while building SugarCRM, I tracked and validated the IP address of the user (in addition to some other things). I only compared the first three sections of the IP address. This allowed for most of the locally variable IP addresses. I also made it possible to turn off the IP address validation for installations where a major variation in IP address was common. I think only comparing the beginning of the IP address helps you with the security without adding such a severe limitation to your application.

当我在构建SugarCRM时遇到此问题时，我跟踪并验证了用户的IP地址（除了其他一些内容）。我只比较了IP地址的前三个部分。这允许大多数本地可变IP地址。我还可以关闭IP地址的主要变化很常见的安装的IP地址验证。我认为只比较IP地址的开头可以帮助您获得安全性，而不会对您的应用程序造成如此严重的限制。

Example: "###.###.###.---" Only the portion of the IP address marked with '#' would be verified.

示例：“###。###。### .---”仅验证标有“＃”的IP地址部分。

192.168.1.101
192.168.1.102
192.168.1.XXX

192.168.1.101 192.168.1.102 192.168.1.XXX

Are all considered equal.

都被认为是平等的。

Jacob

雅各