登录后台之Session Fixation Attack

本文from:DarkEvil

不要吐槽我，我也是第一次遇到这的漏洞 之前根本没有遇到过，浪费了好多时间算是给自己涨点知识吧。唉！
渗透中,有些站点都只有一个登录窗口其它什么都没有，比如说常见的XX、你懂的

楼主就是在渗透过程中，遇到了只有登录窗口的，10W字典扔上去扫都没有用，登录窗口也没有注入（有些BC站看什么程序有存在宽字节注入）,端口也就开了3389，通过简单的爆破也是失败

通过扫描：

有时候我或许跟大多数人一样，把SQL Inject一些高危的漏洞看成重点，其它的都略过，但是查看了一下的请求包：

返回来的源码是登录成功后的,我本以为是可以越权访问，可当我从源码响应的链接去尝试，提示就是让我登录，然后我抓包看了一下：

返回了一个302

如果是Session Fixation Attack 但我并没有发送给受害者，而是直接访问了后台页面。

涉及到session的管理，就不是单单地维持各个请求之间的状态，还需要维持会话期间针对每个特定用户使用到的数据。我们常常把这种数据叫做session数据，因为这些数据是跟某个特定用户与服务器之间的会话相关联的。如果你使用php内置的session的管理机制，那么session数据一般是保存在/tmp这个服务器端的文件夹中，并且其中的session数据会被自动地保存到超级数组$_SESSION中。一个最简单的使用session的例子，就是将相关的session数据从一个页面传递(注意：实际传递的是session id)到另一个页面。下面用示例代码1, start.php, 对这个例子加以演示：

比较常规的针对session的攻击：

· 用户访问http://www.example.org，并且登录。

· example.org的服务器设置指示客户端设置相关cookie – PHPSESSID=12345

· 攻击者这时访问http://www.example.org/,并且在请求中携带了对应的cookie –PHPSESSID=12345

· 这样情况下，因为example.orge的服务器通过PHPSESSID来辨认对应的用户的，所以服务器错把攻击者当成了合法的用户。

通过burp来提交：

返回的乱码，系统原因怎么设置gbk utf8都没有用 设置中文字体显示也一样，所以换了个工具

但为了搞清楚是怎么回事直接进后台的，研究了好久，最后同事用awvs扫完就知道怎么回事了， 因为之前我是没有完全扫描，扫描直接扫死了，所以没有继续扫描，他扫死了继续扫，然后等恢复了又继续扫描，最后扫描完的结果真的让我蛋疼

这是扫描结果给出的源码，大概目标程序是自己写的所以才会存在此漏洞：

<?php

// check if the session is authanticated

if (!isset($_SESION["isAdmin"])) { //检测是否有设置，没有则跳转login.php

header("Location: ../login.php"); //只是跳转了，并没有退出，所以程序继续往下执行了

}

?>

<title>Admin Dashboard</title>

<h3>List of Users</h3>

在浏览器上是看不到内容因为跳转了，burp来：

然后修改加个 exit();

转载请注明。

本文始发于微信公众号（关注安全技术）：登录后台之Session Fixation Attack