文章目录
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/fc12ce564aa8cb9a4fc8798c925db0d3.png#pic_center)
一、了解会话管理机制
- 分析应用程序用于管理会话与状态的机制。确定应用程序是否使用会话令牌或其他方法处理每一名用户提交的各种请求。请注意,用户通过验证后一些验证技术(如HTTP验证)并不需要使用完整的会话机制重新确认用户的身份。同时,一些应用程序采用一种无会话状态机制,通常使用一个加密或模糊处理的表单,通过客户端传送所有状态信息。
- 如果应用程序使用会话令牌,确定它到底使用哪些数据重新确认用户的身份。HTTP Cookie、查询字符串参数以及隐藏表单字段均可用于传送令牌。可使用不同的数据共同重新确认用户的身份,不同的数据可能被不同的后端组件使用。有时,看似为会话令牌的数据实际并未被应用程序使用,例如,Web服务器生成的默认Cookie。
- 为确定应用程序到底使用哪些数据作为令牌,找到一个确信依赖会话和页面(如某一名用户的“用户资料”页面)或功能,并向它提出几个请求,系统性地删除怀疑被用作令牌的数据项。如果删除某个数据项后,应用程序不再返回依赖会话的页面,即可确定该数据项为会话令牌。可用Burp Repeater做这些操作。
- 确定应用程序使用哪些数据重新确认用户的身份后,确定它是否对每个令牌进行完整的确认,或者是否忽略令牌的某些组成部分。修改令牌的值,一次修改一字节,并确定修改后的值是否仍然被应用程序接受。如果发现令牌的某些部分并未被用于保持会话的状态,就一必再深入分析它们。
二、令牌生成
(一)、测试令牌的含义
- 在不同时间以几个不同的用户登录,记录服务器发布的令牌。如果应用程序允许自我注册,就可以选择自己的用户名,用一系列存在细微差别的相似用户名登录,如A、AA、AAA、AAAA、AAAB、AAAC、AABA等。如果其他与某一名用户有关的数据(如电子邮件地址)在登录阶段提交或保存在用户资料中,对其进行与前面类似的系统化修改,并截获收到的令牌。
- 分析收到的令牌查找所有与用户名和其他用户可控制的数据有关的内容。
- 分析令牌,查找所有的编码或模糊处理方案。查找用户名长度与令牌长度之间的所有相互关系;这种关系表示应用程序明显使用了某种模糊处理或编码方案。如果用户名包含一组相同的字符,在令牌中寻找表示可能使用XOR模糊处理的对应字符序列;在令牌中寻找仅包含十六进制字符的序列,它表示应用程序可能对ASCII字符串进行了十六进制编码处理,或者披露其他令牌。寻找以等号(=)结尾的字符序列或仅包含其他有效Base64字符的序列,如a-a、A-Z、0-9、+和/。
- 如果可以从会话令牌样本中获得任何有意义的数据,确定这些信息是否足以帮助发动攻击,猜测出最近发布给其他应用程序用户的信息。找到一个依赖会话的应用程序页面,使用Burp 自动生