Session观点：在打算机中，尤其是在网络运用中，称为“会话掌握”。
Session 工具存储特定用户会话所需的属性及配置信息。
这样，当用户在运用程序的 Web 页之间跳转时，存储在 Session 工具中的变量将不会丢失，而是在全体用户会话中一贯存不才去。
当用户要求来自运用程序的 Web 页时，如果该用户还没有会话，则 Web 做事器将自动创建一个 Session 工具。
当会话过期或被放弃后，做事器将终止该会话。

Session机制：session内容一样平常以文件的形式存储于做事器中，而本地浏览器会存储一个与做事器中session文件对应的Cookie值，Cookie存储的是键值为“PHPSESSID”的Seeion_id值，用户在访问web运用时，每次跳转发生http要求时，会自动把这个存储session_id的Cookie值发送过去，因此web运用的所有页面都可以获取到这个SESSION_ID值，也就可以通过session_id获取做事器中存储的session值，当用户关闭浏览器后，cookie存储的session_id自动打消，一样平常做事器存储的session文件也会在30分钟后自动打消。

比如在wamp环境下，index.php如下：

php控制字串长度PHPSession应用总结 Webpack

首先理解一下session_start()

当会话自动开始或者通过 session_start() 手动开始的时候， PHP 内部会依据客户端传来的PHPSESSID来获取现有的对应的会话数据（即session文件）， PHP 会自动反序列化session文件的内容，并将之添补到 $_SESSION 超级全局变量中。
如果不存在对应的会话数据，则创建名为sess_PHPSES SID(客户端传来的)的文件。
如果客户端未发送PHPSESSID，则创建一个由32个字母组成的PHPSESSID，并返回set-cookie。

可以看到要求中对应的PHPSESSID：ifrvi9r7ui81r0fjq569b06862

在做事器端，即/wamp/tmp下我们就可以创造一个天生的记录Session的文件，由于也没有记录什么会话信息，因此该文件是一个空文件。

补充一下关于php-Session干系配置的解释

在php.ini中对Session存在许多配置，这里我们通过phpinfo来解释几个主要的点。

解释如下：

常见的php-session存放位置

/var/lib/php5/sess_PHPSESSID/var/lib/php7/sess_PHPSESSID/var/lib/php/sess_PHPSESSID/tmp/sess_PHPSESSID/tmp/sessions/sess_PHPSESSED

0x02 Session可能导致的攻击面

Session序列化攻击Session文件包含Session假造用户登录Session逻辑漏洞0x03 Session序列化攻击

Serialize_handler

要理解Session序列化攻击，先来理解一下Session机制中对序列化是如何处理的。

在php中存在三种序列化处理引擎

session.serialize_handler对应存储格式php键名 + 竖线 + 经由serialize()函数序列化处理的值php_binary键名的长度对应的ASCII字符 + 键名 + 经由serialize()函数序列化处理的值php_serialize（ php >= 5.5.4 ）经由serialize()函数序列化处理的数组

本地测试如下：

Session文件内容分别对应结果为

攻击利用事理

payload千万条，事理第一条。

（这里补充说一点，PHP中的Session的实现是没有的问题，危害紧张是由于程序员的Session利用不当而引起的。
如下）

利用不同引擎来处理session文件

如果在PHP在反序列化存储的$_SESSION数据时利用的引擎和序列化利用的引擎不一样，会导致数据无法精确第反序列化。
通过精心布局的数据包，就可以绕过程序的验证或者是实行一些系统的方法。
例如:

在这么一种情形下：

如果我们利用php_serialize引擎时进行数据存储时的序列化，可以得到内容

这时我们的解析采取了另一种引擎：php

思考一下这时会发生什么情形？（php引擎中以竖线来分隔键和值）

如果像上面我们的payload换一下，传入内容以及得到的存储内容如下：

这时候a:1:{s:3:\"大众key\"大众;s:16:\"大众被当作了key，

而后续的O:4:\"大众User\"大众:0:{}\"大众;}被当作了value从而被反序列化。
这里可能有人会问了，为什么会被反序列化？

看看官方文档

这里可能还会有人问？那串value不符合\公众正常\"大众的被反序列化的字符串规则。
这个也不用担心，这里提到一个unserialize的特性，之前也做题也碰着过。
在实行unserialize的时候，如果字符串前面知足了可被反序列化的规则即后续的不规则字符会被忽略。

如果不太好理解不如直接来看一个在线测试用例：

总结一下，在php以php_serialize引擎天生session，然而又以php引擎来解析时，我们通过传入类似$_SESSION[‘name’] = |序列化内容 这种形式的payload即有可能触发反序列化漏洞。
当然这里只是提到了能够找到反序列化利用的点，至于能不能真正触发反序列化漏洞还须要结合当前环境以及一些魔术函数中是否存在可利用点。
这就涉及到php反序列化漏洞的利用知识点了，这里也就不详细讲了。
关于Session反序列化攻击的繁芜利用办法，可以参考2018LCTF中的bestphp’s revenge一题。

没有$_SESSION变量赋值

从上面的情形中我们可以创造我们对session的赋值可控。
那如果代码中不存在对$_SESSION变量赋值的情形下如何利用呢？来看下面一个点。

php还存在一个upload_process机制，即自动在$_SESSION中创建一个键值对，值中刚好存在用户可控的部分。

写入的办法紧张是利用PHP中Session Upload Progress来进行设置，详细为，在上传文件时，如果POST一个名为PHP_SESSION_UPLOAD_PROGRESS的变量，就可以将filename的值赋值到session中。

既然filename字段能够写入session中那么就知足了session可控条件，后续的利用条件同上面所述的情景同等，两种不同引擎先后浸染导致了恶意的序列化字符串被解析。

0x04 Session文件包含

这个也是一个比较旧的知识点了，实在不仅是Session文件包含，仔细想想，理论上只要能够在文件中写入php代码，再被include包含进来不都可以实现getshell嘛？只不过在这里我们的可控点是Session文件，如果能向个中写入php代码，也是可以实现文件包含漏洞利用的。

作为文件包含的利用这里就不展示了，网上关于这个的根本资料早就烂大街了。

值得一提的是，每每现在的CTF出题不会仅限于文件包含这一个点来出题，而是利用诸如session+lfi的形式来入题获取源码等。
而且可能加入open_basedir来限定路径，此时就须要熟习理解session的机制，通过函数来改变save路径来利用。
这个思路是在XCTF Final中涌现的bestphp一题中的考点。
感兴趣的同学可以去找到环境复现一波。

0x05 Session假造用户登录

前几天恰好3CTF出了一个这个考点，这里以那个题目来解释一下利用办法。
（由于没有供应复现环境，此处也只能限于“纸上谈兵”，希望大家能够理解一下利用事理即可。
）

利用条件：session可控；知道session存储格式。

这里的考题是多个攻击面的组合。
题面index.php下提示要以admin登录。

sql盲注可以跑sqlmap拿到实行shellsql root用户存在file权限，但是往站点直接写shell无法成功（预测该当是站点根目录有限定，但是可以预测/tmp可写扫后台创造test.php，访问创造回显了session的数据构造Array([username]=>test)，知道了session的格式。
key为username，至于采取了哪种序列化引擎？三种都测一下就完事。
这里知足了两个利用条件。
通过sqlmap-shell往/tmp写入文件假造adminpayload：select 'username|s:5:\公众admin\公众;' into outfile '/tmp/sess_PHPSESSID'末了修正成对应设计的PHPSESSID即可假造admin登录拿到flag。
0x06 Session逻辑漏洞

很遗憾这个点也没有可以复现的环境。
（官方买断...）这个是上两周unctf中涌现的一道web题考点。
这个逻辑漏洞处在重置密码处。
过程大致如下。

密码重置分为三个步骤。

填写须要重置的用户名用户名绑定的邮箱中收到验证码填写验证码，进入重置密码页面，填写完新密码完成重置。

这里存在的逻辑漏洞在于第一个页面的填写用户名处，预测后台有设置session。
类似：

$_SESSION[‘name’] = $_POST['name'];

利用办法：重置admin密码。

打开一个正常页面完全流程走到末了一步，填写完验证码通过后，填写新密码，此时并不提交。
新开其余一个页面完成第一步，重置用户填写admin，此时Session不再是我们之前自己的用户，而变成了admin。
这时完成之前页面的提交。
成功重置admin密码。

这里逻辑漏洞产生的缘故原由在于对填写验证码后没有对干系用户绑定做记录，在末了一步重置密码时没有对Session的可靠性进行检讨就直接实行了功能。
而我们都知道Session存储在做事器端，因此我们再开一个页面即可完成对单一session文件内容的修正（担保在同一个PHPSEEID下）。

0x07 总结

这里仅仅是记录了自己关于PHP的session机制干系的学习，举的都是自己最近在CTF题中打仗到的点，但关于session的利用点怎么可能只有这几个？碰着了再补充学习吧。
限于篇幅没有展开讲拓展利用，但是说白了，拓展利用便是多个繁芜知识点的综合。
我认为只有把事理性的问题搞清楚了才有可能去理解繁芜的组合攻击。
其余如果文中有什么理解表达缺点的地方还望师傅们示正。

声明：笔者初衷用于分享与遍及网络知识，若读者因此作出任何危害网络安全行为后果自大，与合天智汇及原作者无关！