在日常的渗透测试工作中经常发现会话固定漏洞,但是由于实际危害较小,多数情况下并没有把该漏洞写进报告中
一、漏洞原理
漏洞的本质用一句话来说是把一个无效的或者说低权限的令牌提升为高权限的令牌,而这个令牌标识是攻击者可以控制的。利用漏洞攻击的整体流程。如下图。
攻击流程分为五个阶段:
1、攻击者请求 web 服务器生成会话令牌。(这一步不是必须的,因为有的服务器接受任意的会话令牌。)
2、web 服务器将令牌回复给攻击者。(这一步不是必须的,因为有的服务器接受任意的会话令牌。)
3、攻击者将与其当前令牌所关联的认证页面发送给用户。
4、用户使用攻击者发送的链接登陆 web 服务器,此时攻击者令牌提权,获得了用户的权限。
5、攻击者使用已知令牌登陆系统。
二、为什么要从客户端接收会话令牌
漏洞一般是与业务功能、客户需求等相伴相生的。结合自己不多的经验,我总结推想出两种可能的漏洞场景:
1、为了适应不使用 cookies 的客户端
有一些客户端基于种种原因,不愿使用 cookies,或者压根就不支持。为了照顾这一部分用户,web 程序的开发者则不得不做出妥协,使用其他的方式传送会话令牌。
2、引入了 SSO 的认证场景
SSO(Single Sign On)也就是单点认证,一处登陆多处访问。在同一域下的登陆与资源访问可以很方便的使用 cookies 实现的会话令牌进行控制,如下图。
但是如果跨域了,cookies 也就不那么方便了。就得用能跨域的东西做会话令牌了(比如说把令牌放到参数中),如下图:
认真看图就能发现,登陆过程的 url 和免登 url 都可能携带会话令牌。web 开发者各有千秋,业务需求也各有不同,其他位置也都有可能出现会话令牌。(图中是比较完备的 SSO 实现,真实的系统不一定能实现的这么完整,应该说实现的不完整的 SSO 更易受到会话固定攻击。)
三、环境搭建
使用存有会话固定漏洞的YXcms搭建
链接:http://www.aspku.com/php/27344.html
四、漏洞复现
4.1 YXcms漏洞原因
yxcms允许我们自定义session,而且这个过程通过get方式来完成。我觉得这样的问题属于CSRF,不经意之间就能获取大效果。其问题代码如下:
<?php<br>
//公共类<br>
class commonController extends baseController{public function __construct()<br>
{<br>
parent::__construct();<br>
if(!empty($_GET['phpsessid'])) session_id($_GET['phpsessid']);//通过GET方法传递sessionid,firefox<br>
session_starts();<br>
……
当$_GET[‘phpsessid’]非空时,就令session_id为我们传入的值。
于是我们构造一个链接让管理员点击,管理员点击后会重新设置他的session,而且这个session就是我们构造的。因为session重置了所以管理员也需要重新登录,而重新登录后其session_id就是我们构造的。我们只要利用这个session_id就能登录管理后台了。
4.2 漏洞复现过程
比如我构造一个链接:http://192.168.36.140/yxcms/index.php?r=admin/index/index&phpsessid=f4cking456,将这个链接发给受害者(火狐浏览器),诱使受害者管理员点击该链接,点击后后会跳转到登录页面,但此时他的phpsession已经是我们构造的f4cking456了:
此时如果受害者登录这个网址,那么这个session就有后台权限了。
假如受害者登录该网址
那么我们利用这个链接:http://192.168.36.140/yxcms/index.php?r=admin/index/index&phpsessid=f4cking456,将自己的session设置成f4cking456,或者随意怎么修改,只要把phpsessid修改成f4cking123就能拥有后台权限了
这时攻击者(谷歌浏览器)访问该链接,直接进入后台界面
更多web安全工具与存在漏洞的网站搭建源码,收集整理在知识星球。