一、了解会话管理机制

分析应用程序用于管理会话与状态的机制。确定应用程序是否使用会话令牌或其他方法处理每一名用户提交的各种请求。请注意，用户通过验证后一些验证技术（如HTTP验证）并不需要使用完整的会话机制重新确认用户的身份。同时，一些应用程序采用一种无会话状态机制，通常使用一个加密或模糊处理的表单，通过客户端传送所有状态信息。
如果应用程序使用会话令牌，确定它到底使用哪些数据重新确认用户的身份。HTTP Cookie、查询字符串参数以及隐藏表单字段均可用于传送令牌。可使用不同的数据共同重新确认用户的身份，不同的数据可能被不同的后端组件使用。有时，看似为会话令牌的数据实际并未被应用程序使用，例如，Web服务器生成的默认Cookie。
为确定应用程序到底使用哪些数据作为令牌，找到一个确信依赖会话和页面（如某一名用户的“用户资料”页面）或功能，并向它提出几个请求，系统性地删除怀疑被用作令牌的数据项。如果删除某个数据项后，应用程序不再返回依赖会话的页面，即可确定该数据项为会话令牌。可用Burp Repeater做这些操作。
确定应用程序使用哪些数据重新确认用户的身份后，确定它是否对每个令牌进行完整的确认，或者是否忽略令牌的某些组成部分。修改令牌的值，一次修改一字节，并确定修改后的值是否仍然被应用程序接受。如果发现令牌的某些部分并未被用于保持会话的状态，就一必再深入分析它们。

二、令牌生成

（一）、测试令牌的含义

在不同时间以几个不同的用户登录，记录服务器发布的令牌。如果应用程序允许自我注册，就可以选择自己的用户名，用一系列存在细微差别的相似用户名登录，如A、AA、AAA、AAAA、AAAB、AAAC、AABA等。如果其他与某一名用户有关的数据（如电子邮件地址）在登录阶段提交或保存在用户资料中，对其进行与前面类似的系统化修改，并截获收到的令牌。
分析收到的令牌查找所有与用户名和其他用户可控制的数据有关的内容。
分析令牌，查找所有的编码或模糊处理方案。查找用户名长度与令牌长度之间的所有相互关系；这种关系表示应用程序明显使用了某种模糊处理或编码方案。如果用户名包含一组相同的字符，在令牌中寻找表示可能使用XOR模糊处理的对应字符序列；在令牌中寻找仅包含十六进制字符的序列，它表示应用程序可能对ASCII字符串进行了十六进制编码处理，或者披露其他令牌。寻找以等号（=）结尾的字符序列或仅包含其他有效Base64字符的序列，如a-a、A-Z、0-9、+和/。
如果可以从会话令牌样本中获得任何有意义的数据，确定这些信息是否足以帮助发动攻击，猜测出最近发布给其他应用程序用户的信息。找到一个依赖会话的应用程序页面，使用Burp 自动生成和测试可能的令牌。

（二）、测试令牌的可预测性

使用一个可使服务器返回一个新令牌的请求（例如一个成功登录请求），生成并截获大量紧密相连的会话令牌。
设法确定令牌样本中的所有模式。在所有情况下，都应使用Burp Sequencer对应用程序令牌的随机特性进行详细的统计测试。

理解应用程序重新确认用户身份的令牌和子序列。忽略并未用于确定用户身份的所有数据，即使样本中的这些数据发生了变化。
如果不清楚令牌或者令牌的所有组成成分使用何种类型的数据，尝试使用各种解码方法（例如Base64），看能否得到更有意义的数据。有时可能有必要连续使用几种解码方法。
设法确定解码后的令牌或组成成分数据中存在的所有模式。计算连续值之间的差距。即使这些值看似杂乱无章，但是它们之间仍然可能存在固定的差距，允许渗透测试员显著缩小蛮力攻击的范围。
等待几分钟后，截取类似的一组令牌样本，重复进行上述分析。设法确定令牌的内容是否具有时间依赖性。

如果已经确定了所有模式使用一个不同的IP地址与用户名截获另一组令牌样本，确定是否可以探查到相同的模式，或者是否可以对第一组进行推导，猜测出第二组令牌。
如果能够确定可利用的序列可时间依赖关系，考虑这些信息是否足以帮助发动攻击，猜测出最近发布给其他应用程序用户的令牌。
如果会话ID似乎是定制编写的，可以使用Burp Inturder中的“位翻转”有效载荷继续轮流修改会话令牌中的每个位。同时，在响应中查找表明修改令牌是否会导致会话无效，或会话是否属于其他用户的字符串。

三、令牌处理

（一）、检查不安全的令牌传输

以正常方式访问应用程序，从“起始”URL中的未通过验证的内容开始，到登录过程，再到应用程序的全部功能，留意发布新会话令牌的每一种情况，确定哪些部分使用HTTP通信，哪些部分使用HTTPS通信。可以使用拦截代理器（Burp Proxy）的日志功能记录这些信息。
如果应用程序使用HTTP Cookie传送会话令牌，应确认其是否设置了安全标记，防止通过HTTP连接传送令牌。
在正常使用应用程序的情况下，确定会话令牌是否通过HTTP连接传送。如果是这样，它们就很容易被拦截。
如果应用程序在未通过验证的区域使用HTTP，然后在登录或通过验证的区域转换到HTTPS，那么确认应用程序是否为HTTPS通信发布一个新的令牌，或者应用程序在转换到HTTPS后是否仍然使用HTTP阶段的令牌。如果是这样，它们就很容易被拦截。
如果应用程序的HTTPS区域包含指向HTTP URL的链接，确认在访问过程中是否有会话令牌被提交；如果是这样，查看令牌继续有效还是立即被服务器终止。

（二）、检查在日志中泄露的令牌

如果在应用程序解析过程中能确定任何日志、监控或诊断功能，应仔细检查这些功能，确定它们是否泄露任何会话令牌。确定在正常情况下哪些从有权访问这些功能；如果只有管理员能够使用这些功能，那么确认低权限用户是否可以利用任何其他漏洞访问它们。
确定所有在URL中传送会话令牌的情况。可能应用程序通常以更加安全的方式传送令牌，而开发者在特定情况下使用URL来解决特殊难题。如果是这样，当用户访问站外链接时，这些令牌疳在Referer消息头中传送。确定所有允许在其他用户可查看的页面中插入任意站外链接的功能。
如果能够收集到发布给其他用户的有效会话令牌，就对每个令牌进行测试，确定它是否属于管理用户（例如，尝试使用令牌访问某个特权功能）。

（三）、测试令牌-会话映射

用同一个用户账户从不同的浏览器进程或从不同的计算机两次登录应用程序。确定这两个会话是否都处于活动状态。是就表示应用程序支持并行会话，可让攻破其他用户证书的攻击者能够利用这些证书，而不会有被检测出来的风险。
使用同一个用户账户从不同的浏览器进程或从不同的计算机登录并退出应用程序几次。确定应用程序在每次登录时是发布一个新会话令牌，还是发布相同的令牌。如果每次发布相同的令牌，那么应用程序根本没有正确使用令牌，而是使用唯一持久性字符串重新确认用户身份。在这种情况下，应用程序就没有办法防止并行登录或正确实施会话超时。
如果令牌明显包含某种结构和意义，设法将标识用户身份的成分与无法辨别的成分区分开来。尝试修改与用户有关的所有令牌成分，使其指向其他已知的应用程序用户，并确定修改后的令牌是否被应用程序接受，以及能够让攻击者伪装成该用户。

（四）、测试会话终止

当测试会话超时与退出漏洞时，主要测试服务器如何处理会话与令牌，而还是太郁闷发生的任何事件。在客户端浏览器内对令牌执行的操作并不能终止会话。
检查服务器是否执行会话终止。

登录应用程序获得一个有效令牌。
不使用这个令牌，等待一段时间后，用这个令牌提交一个访问受保护页面（如“我的资料”页面）的请求。
如果该页面正常显示，那么令牌仍然处于活动状态。
使用反复试验的方法确定会话终止超时时间为多久，或者一个令牌在前一次使用它提交请求几天后是否仍被使用。

检查退出功能是否存在。如果应用程序使用退出功能，测试它是否能够在服务器上有效确认用户的会话。退出后，尝试重新使用原有的令牌，使用它请求一个受保护的页面，确定其是否仍然有效。如果令牌仍然有效，那么即使用户已经“退出”，他们依然易于受到会话劫持攻击。可以使用Burp Repeater从代理历史记录中不断发送一个特殊的请求，观察退出后应用程序是否做出不同的响应。

（五）、测试会话固定

如果应用程序向未通过验证的用户发布令牌，获取令牌并登录。如果应用程序在登录后并不发布一个新令牌，就表示它易于受到会话固定攻击。
即使应用程序并不缶未通过验证的用户发布会话令牌，也可通过登录获得一个令牌，然后返回登录页面。如果应用程序“愿意”返回这个页面，即使已经通过验证，也可使用相同的令牌以另一名用户的身份提交另一次登录。如果应用程序在第二次登录后并不发布还似旧时游上苑新令牌，就表示它易于受到会话固定攻击。
确定应用程序会话令牌的格式。用一个捏造的、格式有效的值修改令牌，然后尝试使用它登录。如果应用程序允许使用一个捏造的令牌建立通过验证的会话，就表示它易于受到会话固定攻击。
如果应用程序并不支持登录功能，但处理敏感数据（如个人信息和支付细节），并在提交后显示这些信息（如在“确认订单”页面上），那么可以使用前面的三种测试方法尝试访问显示敏感数据的页面。如果在匿名使用应用程序期间生成的令牌可用于获取用户的敏感信息，那么应用程序就易于遭受会话固定攻击。

（六）、检查CSRF

如果应用程序完全依靠HTTP Cookie传送会话令牌，它很可能易受到跨站点请求伪造（CSRF）攻击。
分析应用程序的关键功能，确定用于执行敏感操作的特定请求。如果这些请求中的参数完全可由攻击者事先决定（也就是说，其中并不包含任何会话令牌、无法预测的数据或其他机密），那么几乎可以肯定应用程序易于受到攻击。
创建一个HTML页面，它不需要进行任何用户交互，即可提出想要的请求。对于GET请求，可以使用一个标签，并通过src参数设置易受攻击的URL。对于POST请求，可以建立一个表单，其中包含实施攻击所需全部相关参数的隐藏字段，并将其目标设为易受攻击的URL。可以使用JavaScript在页面加载时自动提交该表单。登录应用程序后，使用同一个浏览器加载前面创建的HTML页面。确认应用程序是否执行想要的操作。
如果应用程序为阻止CSRF攻击，在请求中使用其他令牌，则应以与测试会话令牌相同的方式测试这些令牌的可靠性。还应测试应用程序是否易于受到UI伪装攻击，以突破反CSRF防御。

（七）、检查Cookie范围

如果应用程序使用HTTP Cookie传送会话令牌（或任何其他敏感数据），那么检查相关的Set-Cookie消息头，寻找用于控制Cookie菜园的所有“域”或“路径”属性。
如果一个应用程序明确放宽它的Cookie范围限制，将其设定为一个父域或父目录，那么攻击者可以通过以上父域或父目录中的其他Web应用程序向该应用程序发动攻击。
如果一个应用程序以它自己的域名为它的Cookie域范围（或并未指定“域”属性），那么它仍然可能受到在子域上运行的应用程序的威胁。这是设定Cookie范围造成的后果，只有不在安全敏感的应用程序的子域上运行其他应用程序，才能避免这种后果。
确定对按路径（如/sire/main和/site/demo）隔离的任何依赖情况，跨站点脚本攻击能够破坏这种隔离。
确定所有可能收到应用程序发布的Cookie的域名和路径。确定是否可通过这些域名或路径访问其他Web应用程序，以及是否可利用它们获得发布给目标应用程序用户的Cookie。

渗透测试方法论5---测试会话管理机制相关推荐

浅谈电商网站开发中用户会话管理机制的设计和实现原理
笔者由于工作需要,最近对国内外两款知名的电商网站的用户会话管理(User Session Management) 的实现机制做了一些调研,这里把我学习到的一些知识分享给各位同行,希望起到抛砖引玉的作用 ...
黑客攻防技术宝典Web实战篇第2版—第7章攻击会话管理
7.1 状态要求 1.HTTP是无状态的,基于请求-响应模型,每条消息代表一个独立的事物. 2.大多数Web站点实际为Web应用程序,他们允许用户注册登录,购买销售,记住用户喜好,它们可以根据用户的单 ...
20145212 罗天晨 WEB登陆发贴及会话管理功能的实现
会话管理简介 Cookie: cookie常用于识别用户. cookie 是服务器留在用户计算机中的小文件,每当相同的计算机通过浏览器请求页面时,它同时会发送 cookie. 通过PHP能够创建并取回 ...
解析Servlet/JSP会话跟踪机制
在Web服务器端编程中,会话状态管理是一个经常必须考虑的重要问题.本文分析JSP/Servlet的会话管理机制及其所面临的问题,然后提出了一种改进的会话管理方法. 一.Servlet的会话管理机制根 ...
Http会话保持机制：Cookie、Session和Token
前言:在 Web 应用中,用户的认证和鉴权是非常重要的一环.HTTP 是一个无状态的协议,一次请求结束后,下次在发送服务器就不知道这个请求是谁发来的了(同一个 IP 不代表同一个用户),这样就无法确定 ...
渗透测试方法论4---测试验证机制
文章目录一.了解验证机制二.数据攻击 (一).测试密码强度 (二).测试用户名枚举 (三).测试密码猜测的适应性三.特殊功能 (一).测试账户恢复功能(自己改密码) (二).测试"记住 ...
Web安全第 01 讲：渗透测试方法论
一.Web工作机制 1.1.浏览网站经历的过程本地缓存 --> host --> IP/ARP --> DNS --> IP --> 网关--> 路由--> ...
【CyberSecurityLearning 51】渗透测试方法论+渗透测试流程
目录渗透测试方法论渗透测试(penetration testing,pentest) 渗透测试种类 * 黑盒测试 * 白盒测试 * 脆弱性评估与渗透测试安全测试方法论 * 开放式web 应用程序 ...
网络安全学习（渗透测试方法论，web架构安全分析，信息收集）
目录一.渗透测试方法论渗透测试种类 *黑盒测试 *白盒测试 *脆弱性评估与渗透测试二.安全测试方法论 *开放式 Web 应用程序安全项目(Open Web Aplication Security ...

渗透测试方法论5---测试会话管理机制

文章目录

一、了解会话管理机制

二、令牌生成

（一）、测试令牌的含义

（二）、测试令牌的可预测性

三、令牌处理

（一）、检查不安全的令牌传输

（二）、检查在日志中泄露的令牌

（三）、测试令牌-会话映射

（四）、测试会话终止

（五）、测试会话固定

（六）、检查CSRF

（七）、检查Cookie范围

渗透测试方法论5---测试会话管理机制相关推荐

最新文章

热门文章