Session劫持攻击的思路

×00 应用程序认证设计背景
0×01 常规攻击思路及缺陷
0×02 利用应用程序设计缺陷进行Session劫持的攻击原理
0×03 Session劫持的大致思路及意义
0×04 如何防御这种攻击
 

0×00 应用程序认证设计背景

一个应用程序在设计的过程中,为了实现对资源和请求进行管理,用户信息认证是非常重要的一环。由于HTTP请求的无连接性,一般的应用程序都是通过 Cookie或者Session来完成认证工作,通过将加密的用户认证信息存储到Cookie中,或者通过赋予客户端的一个Token,通常也就是所说的 SessionId来在服务器端直接完成认证和取得用户的身份信息,不管哪一种方式,实际上在HTTP协议里都是通过Cookie来实现的,不同的是 Cookie可能可以比较长期地存储在客户端上,而Session往往在会话结束之后服务器监视会话不处于活动状态而予以销毁。

0×01 常规攻击思路及缺陷

我们研究的web安全,往往很多时候其实就是在攻击认证,包括非常流行的客户端攻击XSS,传统的方法是我们可以截取Cookie来伪造成别人的身份来获 得认证。各种应用程序为了实现自己独特的功能应用,在认证机制设计的时候并不一致,譬如有的完全将认证信息(用户密码信息)加密存储到客户端里,只要用户 密码信息不修改,就可以一直利用这个认证信息来登录应用程序。也有的是将认证通过后应用程序赋予客户端一个Token,这个Token存储在Cookie 里,这样当客户端登录的时候就可以通过这个Token获得对应的身份,这样只要这个Cookie不被删除,就可以永远的处于登录状态。而另外的一些应用程 序将Token放置到Session里,当客户端退出应用程序之后或者客户端在一段时间无响应之后,服务器就销毁这个Session,而且因为是 Session里,所以客户端浏览器关闭之后,这个Session也从浏览器内存里销毁了。

我们常用的跨站脚本攻击非常常用的一个攻击手法就是去攻击应用程序的认证,而由于服务器实现认证的时候存在的一些漏洞和机制的一些区别,攻击成果也往往显 得不同。对于应用程序来讲,为了保证绝对的安全,服务器应该将Cookie和客户端绑定,譬如将客户端的加密IP也存储到Cookie里,如果发现Ip发 生变化就可以认为是Cookie发生了泄漏,应该取消这个Cookie,但是这样一来,用户体验就非常不好,所以一般的应用程序都没有对Cookie做太 多的策略,这就为我们的客户端身份窃取提供了可乘之机。所以问题就集中到认证机制的处理上,对于第一种情况,大多数的中小型应用程序的前台都是使用的这种 认证方式,只要获得了Cookie就可以永久获得别人的身份。而第二种情况也比较常见,譬如Google就是使用的这种机制,只要窃取了Cookie,别 人只关闭应用程序也不退出应用程序的时候就可以获得别人的身份(之前别人退出都可以获得别人的身份,后来他们做了改进)。剩下比较麻烦的就是第三种情况最 令人头疼,因为是Session认证,所以别人退出或者关闭浏览器而与服务器的沟通结束之后,Session在一定时间内也被销毁。但是我们发现一些程序 在设计的时候存在问题,可能导致我们利用Session的机制在服务器上永久的产生一个后门(在某些设计不严的程序里,可能修改密码也不能消除掉这种后 门),我这里把它称为一种真正意义上的Session劫持。

0×02 利用应用程序设计缺陷进行Session劫持的攻击原理

一般的Session劫持都是获得身份之后期望对方不要点击退出,而且如果在这段时间里没有及时利用Session,Session也会因为自己的机制而 进行自我销毁,这样获取到的Session就失去了效果,这里比较典型的应用有很多,譬如163邮箱,譬如baidu的认证机制。我们可以经常遇到这样的 情况,我在一个浏览器里开了webmail然后新打开一个浏览器开了webmail,然后我第一个浏览器退出了并不影响第二个的账户,两者互不影响,其实 是因为他们获取到了两个SessionId,这在应用程序里可能是作为用户体验考虑的,但是正是这种机制存在巨大的安全漏洞。
Session信息是以一个SessionId或者表现为临时Cookie的Token的形式发送的,而我们在实现了XSS的时候其实是可以操作 Cookie的了,可以想象,如果我们赋给浏览器一个和Session Cookie名字相同而值不同的Cookie会怎么样?通过我们的测试发现,实际上两个Cookie都是被发送出去的,在HTTP头里表现为出现两个一样 的COOKIE,那么服务器会选择哪个Cookie作为实际取得的COOKIE变量呢?我们测试的时候发现实际上是以第一个出现的COOKIE为准的,而 不管发送过来的是Session Cookie还是Store Cookie,所以我们就可以利用Javascript改变客户端的Session Token了。

0×03 Session劫持的大致思路及意义

这样我们的思路就很清晰,我们要实现的是Session劫持,而不是传统的Session窃取,我们通过覆盖这个Session Token为一个无效值,服务器会认为用户身份为未登录,然后会要求用户再次登陆,在这个时候我们可以窃取到有效的Session Token值。用户再次登陆之后,他获得新的Session Token,而由于应用程序的机制,之前的Session Token并没有失效,这样服务器上就存在两个有效的Session Token了。我们通过研究应用程序的Session超时机制和心跳包机制,就可以长久地使这个Session有效。而接下来假设用户很注意安全,他有退 出应用程序的使用习惯,他销毁了他的Session Token,但是仍然有一个Session Token被我们掌握。这种方法的狠毒在于,即使用户意识到Session Token被窃取,如果某些应用程序的设计有问题,即使用户修改密码,他也不能控制服务器注销掉被我们掌握的会话,他的Session永远被我们掌握了, 他也永远不知道这个Session Token是多少。

0×04 如何防御这种攻击

我们可以看到,这种攻击是由于应用程序在设计的时候考虑不周造成的,我们可以在设计认证的时候就强行要求客户端必须唯一,并且认证信息在多少天之后就过期 的机制,但是很明显这样会和将COOKIE和ip绑定一样,可能带来不好的用户体验,如何在设计的时候意识到这个问题并且权衡应用和安全的平衡点才是 web应用程序设计者要考虑的难题

 

<think>好的,我现在需要帮助用户理解文件包含和会话(Session)相关的CTF题目解法。首先,我得回忆一下文件包含漏洞和Session机制的基本概念,以及它们在CTF中的常见应用场景。 文件包含漏洞通常分为本地文件包含(LFI)和远程文件包含(RFI)。攻击者可能利用这些漏洞读取敏感文件,比如/etc/passwd,或者执行恶意代码。而Session则涉及服务器存储用户会话信息,比如PHP的Session文件通常存储在/tmp目录下,文件名类似于sess_[sessionid]。 接下来,我需要考虑在CTF题目中,如何将这两者结合起来。例如,题目可能设计成需要通过LFI来读取或包含Session文件,进而获取flag。这时候,攻击者可能需要先上传恶意内容到Session,再通过包含Session文件来执行代码。 然后,我应该分步骤解释解题思路。比如,首先找到存在文件包含漏洞的参数,然后确定Session存储的位置和文件名。文件名通常由PHPSESSID决定,所以需要控制该ID或者知道其生成方式。之后,如何将恶意代码注入到Session中,可能通过用户可控制的字段,比如User-Agent或者表单输入。 另外,可能需要考虑服务器配置,比如是否允许远程包含,或者是否对包含路径进行了过滤。常见的绕过方法包括使用路径遍历(../)、编码绕过,或者利用PHP的包装器如php://filter来读取文件内容。 还需要提醒注意事项,比如Session文件的权限问题,时间竞争条件(因为Session文件可能被清理),以及如何构造有效的Payload。例如,在PHP中,如果Session中的某个变量被设置为恶意代码,当包含该Session文件时,代码可能被执行。 最后,应该给出一个具体的例子,说明攻击流程:修改User-Agent为PHP代码,获取PHPSESSID,然后利用LFI包含对应的Session文件,从而触发代码执行,获取flag。 需要确保解释清晰,步骤明确,并覆盖常见考点和陷阱。同时,要检查是否有遗漏的细节,比如是否需要先设置Session变量,或者服务器是否会对输入进行过滤处理。</think>文件包含(File Inclusion)和会话(Session)相关的 CTF 题目通常结合了 **本地文件包含(LFI)**、**会话劫持**或 **Session 文件注入**等技术。以下是这类题目的常见解法思路和关键知识点: --- ### **1. 文件包含漏洞(LFI/RFI)** - **漏洞原理**:通过动态包含文件的功能(如 PHP 的 `include`、`require`)未对用户输入进行过滤,导致攻击者可以包含恶意文件。 - **LFI(本地文件包含)**:读取服务器本地文件(如 `/etc/passwd`、源码文件)。 - **RFI(远程文件包含)**:包含远程服务器上的文件(需服务器配置允许,如 `allow_url_include=On`)。 - **常见利用方式**: - 读取敏感文件:`?file=../../../../etc/passwd` - 结合 PHP 伪协议: - 读取源码:`php://filter/convert.base64-encode/resource=index.php` - 执行代码:`php://input` + POST 传递 PHP 代码。 --- ### **2. Session 文件利用** - **Session 机制**:PHP 等语言通过 Session ID 在服务器存储用户会话数据(如 `/tmp/sess_[PHPSESSID]`)。 - **Session 文件名**:由 `PHPSESSID` 决定(如 `sess_abc123`)。 - **攻击思路**: - **Session 文件注入**:如果攻击者能控制 Session 内容(如通过用户输入、User-Agent 等字段),可以写入恶意代码到 Session 文件,再通过 LFI 包含该文件实现代码执行。 - **Session 固定(Session Fixation)**:强制用户使用已知的 Session ID,从而劫持会话。 --- ### **3. 经典 CTF 题目解法示例** #### **场景**:题目存在文件包含漏洞,且 Session 文件存储路径已知(如 `/tmp/sess_[ID]`)。 **解题步骤**: 1. **获取 Session ID**: - 通过 Cookie 中的 `PHPSESSID` 或响应头获取当前 Session ID。 - 若未设置,可手动指定(如 `Cookie: PHPSESSID=attacker`)。 2. **向 Session 中注入恶意代码**: - 找到服务器存储 Session 数据的字段(如通过表单、HTTP 头部)。 - 例如,修改 User-Agent 为 PHP 代码: ```php User-Agent: <?php system('cat /flag'); ?> ``` - 服务器可能将 User-Agent 存入 Session 文件,生成 `/tmp/sess_attacker`。 3. **通过 LFI 包含 Session 文件**: - 利用文件包含漏洞读取 Session 文件: ``` ?file=../../../../tmp/sess_attacker ``` - 若 Session 文件中存在 PHP 代码,可能会直接执行。 --- ### **4. 绕过技巧** - **路径穿越**:使用 `../` 绕过目录限制。 - **Null 字节截断**:`%00` 截断后缀(PHP < 5.3)。 - **编码绕过**:URL 编码、双重编码(如 `%252e%252e%252f`)。 - **PHP 伪协议**: - `php://filter/read=convert.base64-encode/resource=file` 读取文件。 - `data://text/plain,<?php phpinfo();?>` 直接执行代码。 --- ### **5. 防御措施** - 避免动态包含用户输入的文件。 - 设置 `open_basedir` 限制文件访问范围。 - 对 Session 存储路径进行随机化或权限控制。 - 过滤特殊字符(如 `../`、`php://`)。 --- ### **示例 Flag 获取流程** 1. 发现文件包含参数:`?page=index.php` 2. 尝试包含 `/etc/passwd` 验证漏洞:`?page=../../../../etc/passwd` 3. 通过 `php://filter` 读取源码,发现 Session 存储路径为 `/tmp` 4. 修改 User-Agent 为 `<?php system('ls /'); ?>` 并获取 Session ID 5. 包含 Session 文件:`?page=../../../../tmp/sess_[id]` 6. 代码执行后读取 `/flag` 文件。 通过结合文件包含和 Session 机制,可以高效解决此类 CTF 题目。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值