一文了解会话固定漏洞

Posted 2021-08-30 思源湖的鱼

前言

学习下会话固定漏洞

1、漏洞原理

漏洞的本质用一句话来说是把一个无效的或者说低权限的令牌提升为高权限的令牌，而这个令牌标识是攻击者可以控制的。

（1）攻击流程

利用漏洞攻击的整体流程如下图：

• 攻击者请求web服务器生成会话令牌（这一步不是必须的，因为有的服务器接受任意的会话令牌）
• web服务器将令牌回复给攻击者（这一步不是必须的，因为有的服务器接受任意的会话令牌）
• 攻击者将与其当前令牌所关联的认证页面发送给用户
• 用户使用攻击者发送的链接登陆web服务器，此时攻击者令牌提权，获得了用户的权限
• 攻击者使用已知令牌登陆系统，成功冒充劫持用户的会话

（2）攻击场景

1、为了适应不使用cookies的客户端

有一些客户端基于种种原因，不愿使用cookies，或者压根就不支持。为了照顾这一部分用户，web程序的开发者则不得不做出妥协，使用其他的方式传送会话令牌。

2、引入了SSO的认证场景

SSO（Single Sign On）也就是单点认证，一处登陆多处访问。在同一域下的登陆与资源访问可以很方便的使用cookies实现的会话令牌进行控制

原理可参考：单点登录SSO的实现原理

但是如果跨域了，cookies也就不那么方便了，就得用能跨域的东西做会话令牌了（比如说把令牌放到参数中），如下图：

登陆过程的url和免登url都可能携带会话令牌，当然web开发者各有千秋，业务需求也各有不同，其他位置也都有可能出现会话令牌

图中是比较完备的SSO实现，真实的系统不一定能实现的这么完整，应该说实现的不完整的SSO更易受到会话固定攻击

2、漏洞测试

为了看到直观的漏洞攻击效果，这里使用世界上最好的语言之一——php进行测试。为了适应客户端的奇葩需求，PHP实现了一种可以通过url参数传递session id的机制，不过不是默认配置（应该不是）。需要在php配置文件中配置一下：

;加入这几条配置
;设置是否适用cookies存储sessionid，如果为0则不适用cookies，对演示效果没有影响，如果为1，则优先使用cookies中的session id
session.use_cookies = 0
;是否只是用cookies存储sessionid，如果为1，则不能使用url传session id
session.use_only_cookies = 0
;是否在url中传输sessionid，为0时不能使用url传令牌
session.use_trans_sid = 1

（1）测试代码

写了两个简单的界面复现这个漏洞

index.php

<?php
$id=md5(time().'salt');//无法预测的salt
header('location:login.php?PHPSESSID='.$id);

login.php

<?php
session_start();
$user='admin';
$pass='password';
if(isset($user)&&isset($pass)){    
if($_GET['user']==$user && $_GET['pass']==$pass ){        $_SESSION['user']='admin';    
}
}if ($_SESSION['user']=='admin'){    
echo 'hello admin!';
}else{    
echo 'please login.';
}
echo '<br>';
echo session_id();//方便查看当前的session id是啥

（2）测试过程

首先使用攻击者浏览器访问index.php获得带令牌的登陆url

然后到另外一个浏览器（用户浏览器）使用该链接登陆账户

此时在攻击者浏览器刷新下页面

3、漏洞实例

inurl:PHPSESSID 直接搜一个站看看
挑了一个有注册登陆功能的站初步测试下，基本实锤了

这个站可以接收任意的session id

首先使用常规操作注册一个账号，作为待测试的用户账号

构造url：http://www.xxx.com/?PHPSESSID=你的sessionid

超长的字符串容易引起警觉，所以我直接改个短的，把1作为sessionid

在受害者浏览器打开并登陆

随后在攻击者浏览器把session id改为1

刷新页面，发现已经登陆成功

4、防御

• 在用户登录成功后重新创建一个session id
• 登录前的匿名会话强制失效
• session id与浏览器绑定：session id与所访问浏览器有变化，立即重置
• session id与所访问的IP绑定：session id与所访问IP有变化，立即重置
• 禁用客户端访问Cookie，此方法也避免了配合XSS攻击来获取Cookie中的会话信息以达成会话固定攻击。在Http响应头中启用HttpOnly属性，或者在tomcat容器中配置

结语

学习了下会话固定漏洞

• 不只形如http://test/?XXXSESSIONID=1234的链接可能存在这种问题，通过POST传递参数也同样存在这种问题
• 对会话固定漏洞的挖掘不能局限于对形如session id的变量的监控，应该着眼于一切有会话令牌性质的变量（换句话说就是sessionid不只是cookies里那一点）

一篇很好的文章：Session Fixation Vulnerability in Web-based Applications