会话劫持的应对方法

Question

很明显，我们大多数PHP程序员都不希望我们发布的作品以我们不想要的方式被黑客攻击或利用。因此，当我询问如何应对会话劫持时，我会格外小心。我知道有session_regenerate_id()函数可以在一定程度上对抗会话劫持，但我更好奇的是我遇到的另一个方法：

当一个用户登录到网站时，你把他们的代码(或者另一个更秘密的，预定义的加密字符串)(对于普通用户来说是未知的)作为一个字符串，你用随机的预定义符号对它加盐，md5()字符串，并将其设置为$_ session ' user _code‘= $that_string；任何时候，只要这个用户转到一个页面，你就会重复这个过程，并将其与$_SESSION' user _code’进行匹配，如果它们不匹配，则销毁会话。

因此，在代码中，它看起来像这样(例如)：

 //user credentials are correct, user data is fetched from db   

$_SESSION['username'] = $row[3]; //username
$_SESSION['password'] = $row[2]; //password
$_SESSION['user_id'] = $row[4]; //user_id
$salt1 = 'uNs819';
$salt2 = 'J2i';
$user_code = $salt1 . $row[4] . $salt2;
$user_code = md5($user_code);
$_SESSION['user_code'] = $user_code;

然后在每个可用页面的开头检查这是否正确：

//fetch user credentials from db again
//$row4 is the user_id
if($_SESSION['user_code'] != md5($salt1 . $row[4] . $salt2){
    session_destroy();
}

我不认为使用user_id作为加密的一部分是最佳的，但这只是一个例子。我最好使用创建用户时的时间戳的md5字符串。但如果我说得不清楚，我的主要问题是，这种方法对会话劫持是否可靠，为什么/为什么不？

Answer 1

您不需要一个包含多个盐的花哨方案。

此外，如果我可以窃取用户的会话cookie，您的方案将根本不起作用。

1. 在登录后更改会话id以避免会话固定
2. Use HTTPS everywhere
3. Use httpOnly session cookie so JavaScript cannot read
4. 验证并拒绝XSS输入并在输出时转义用户生成的数据
5. 使用长而随机的会话HTTPS用户进行重要操作

Answer 2

始终根据跨站点伪造令牌检查任何表单，例如，在登录时创建令牌：

Session:set('token', md5(uniqid());

然后在每个表单上放置一个带有所述令牌的隐藏表单输入

<input type="hidden" name="crsf" value="<?php echo System::escape(Session::get('token'));">

然后，您可以检查它们以确保：

if(Request::post('crsf') == Session::get('token'):
   //do what you gotta do

无论提交成功与否，都要确保在每次提交表单时重新生成一个新令牌

我很抱歉在这个问题上使用了一些方法，但是您已经了解了如何处理表单以及不能处理表单的要点。

Answer 3

“我遇到的另一种方法”-请引用你的来源。

您在这里描述的内容完全不会影响会话劫持。无论您使用多少会话值、多少盐和多少轮加密，结果都将始终匹配。如果会话遭到破坏，则不能依赖它来验证会话。session_regenerate_id()函数确实增加了一些值，但只是减少了现有漏洞被利用的时间。花时间防止会话泄露-使用https，HSTS，http-only+安全cookie标志，严格的CSP，到期时的会话破坏。

如果您确实觉得有必要进一步增强安全性，则可以在正常交换中使用令牌，例如使用本地存储或设备指纹识别的质询响应。