会话管理：

绝大多数Web应用程序中，会话管理机制是一个基本的安全组件。它帮助应用程序从大量不同的请求中确认特定的用户，并处理它收集的关于用户与应用程序交互状态的数据。会话管理在应用程序执行登录功能时显得特别重要，因为它可在用户通过请求提交他们的证书后，持续向应用程序保证任何特定用户身份的真实性。

•会话ID（SID）：由服务器产生并返回给浏览器的请求，并且在浏览器中存储（通常来说是Cookie），它用来标识浏览器与服务器会话的唯一值。

•我们通过SID的名字就可以基本判定应用服务器和编程语言是什么，如PHPSESSID （PHP）、JSESSIONID（J2EE）、CFID& CFTOKEN（ColdFusion）、ASP.NET_SessionId （ASP.NET）等。所以我们推荐把默认的SID的名字换成大众一点的名字，如ID。为了防止暴力破解，SID必须有一定的长度，它的长度至少要128位（16字节）。此外，SID还必须是不可预测的（随机的），来防止预测攻击

•Cookie：指浏览器客户端用来存储SID的内存或者文件。

•会话内存分配：在服务器端存储来自浏览器请求的一些特殊值，如用户名等信息，它和SID是相关联的。

•用户通过浏览器访问一个应用服务器，起始的时候用户发给服务器的请求并没有任何会话ID。

•当服务器收到用户发过来的请求时发现，该请求没有会话ID，于是它会产生一个新的唯一会话ID，并且在服务器端分配内存，返回给浏览器，同时在应答中通过set-cookie在HTTP header中设置该会话ID。

•浏览器收到了含有被设置Cookie的应答，于是它将定义在HTTP header中的会话ID保存在Cookie中。

•此后，每次浏览器向该服务器发送请求时，都会在请求的HTTP header中附上"cookie:"。

•服务器收到来自浏览器的请求，如果该请求含有合法的会话ID，它就会在会话内存中寻找与此会话ID对应的对象/值

会话管理机制中的安全漏洞主要在：

•1. 会话令牌生成过程中；

•2. 在整个会话生命周期过程中处理

 

会话生成

          1. 确定会话令牌  

 许多应用程序使用标准的cookie机制传输会话令牌，这样可直接确定哪些数据包含令牌。然而，在其他情况下，可能需要进行一番探测才能找到令牌。

•应用程序常常使用几个不同的数据共同表示一个令牌，包括cookie、URL参数和隐藏表单字段。其中一些数据可用于在不同的后端组件中维护会话状态。如果没有得到确认，不要想当然地认为某个特殊的参数就是会话令牌，或者只使用一个数据追踪会话。

•有时，一些数据似乎是应用程序的会话令牌，其实并非如此。具体来说，由Web服务器或应用程序平台生成的标准会话cookie可能存在，但实际并不被应用程序使用。

•用户通过验证后，观察浏览器收到哪些新数据项。应用程序通常会在用户通过验证后建立新的会话令牌。

•为确定应用程序到底使用哪些数据项作为令牌，找到一个确信依赖会话的页面（如某一名用户的“用户资料”页面），并向它提出几个请求，系统性地删除疑似被用作令牌的数据。如果删除某个数据后，应用程序不再返回会话依赖页面，即可确定该数据为会话令牌。可以使用burpsuite来模拟执行。

           令牌是不是可以破解（加密 ）

凯撒（Caesar）密码

         是不是可以预测（隐含序列 时间依赖）

大量枚举（时间，用户名）

通过工具（burp） 问题：如果有加密的话

会话传输过程

1. 非https传输
2. 不是全站 https,比如只在登录口用https传输， 那么 http –令牌1--https—令牌2—http，那么令牌1不能和令牌2 一样
3. 登录—令牌1--注销—令牌2---登录 令牌1 不能和令牌2 相等

4. 测试点：

   1.-https传输  （网商，金融）

   2.登陆后会话令牌修改（通过了https会话令牌一定要发生变化）

   3.登录—注销—在登录 起始会话令牌的变

5. 针对会话劫持、会话固定攻击、会话终止攻击等：

   最基本的建议就是：一旦用户登录成功以后，马上invalidate用户的会话。具体的步骤如下：
   用户输入用户名和密码。
   系统对用户进行验证通过。
   已有的会话信息如果仍然需要，则转移到一个临时变量中去。
   invalidate 当前的会话。
   创建一个新的会话。
   把临时变量中保存的会话信息恢复到新创建的会话中去。
   用户使用这个新的会话登录到系统中并进行操作。

 

会话终止攻击

Session失效 正常登录—20分钟无操作—sessionid失效—清空客户端cookie中的sessionid并返回首页—清空服务端的sessionid

退出功能

 

Basic过程

•双依赖会话

•Sessionid authorization

 

 

保护会话令牌:

1．采用强算法生成Session ID

会话ID必须具有随机性和不可预测性。一般来说，会话ID长度超过128位会比较安全;散列化。

2．软硬兼施，会话过期

会话过期是应用程序的一项重要的安全控制，它定义了用户在多长时间段内不用重新登录而仍然维持一个登录状态。一般来说，有两种会话过期--软会话过期（Soft Session Timeout）和硬会话过期（Hard Session Timeout）。

3．保护你的Cookie

Cookie有两个很重要的属性：secure和HttpOnly，设置好这两个属性对于保护你的Cookie至关重要。

首先说secure属性。声明了它，则说明当前这个Cookie只会在HTTPS的链接中进行传递，这样就可以使得攻击者无法很容易地通过分析网络流量来获得会话ID，从而有效地防治了中间人攻击（Man-in-the-Middle）。

HttpOnly不允许一些脚本（如JavaScript等）直接操作document.cookie这个DOM对象，这个属性对于阻止通过XSS窃取会话ID是必需的。

4. 提供logout功能

即用户可以手动地使当前会话过期，这就是我们在几乎所有网站上都看到的logout按钮。 备注：真正的注销应该用什么方法呢？一般都用invalidate()方法。

 

攻击访问控制

•垂直访问控制：

通常网站具有不同级别控制权限的角色，基本的包括普通用户和管理员。更加复杂的可能对于每一个用户都具有不同的角色。

•水平访问控制：

同样权限的用户，但是只能访问属于自己的水平权限。例如邮箱我们只可以收到当前用户的邮件，网银账户只可以使用自己的资金等等。

•上下文访问控制：

提交与上下文相关的内容。例如多阶段操作时，正确的上下文控制可以防止用户不按规定的顺序访问各个阶段。

攻击访问控制--常见漏洞

完全无保护功能：

即任何人都可以通过某一个简单链接访问某一受限功能。

如：www.besttest.cn/admin/

•基于标识符的功能：

程序中可能包含某些需要访问的特殊资源，被请求资源的标示符常常以请求参数的形式在url中或者是post请求主体中提交给服务器

如：www.besttest.cn/document.php?docid=123456

多阶段功能：

类似登录模块中讲解的多阶段登录。

•静态文件：

用户有权限的对静态文件进行下载等操作，可能包含一些忽略权限的漏洞：

如：www.besttest.cn/download/123456.pdf

基于referer消息头的访问控制

应用程序可能会使用HTTP Referer消息头做出访问控制决定。

例如：应用程序可能会根据用户权限，控制用户访问主菜单。但是，如果某用户请求访问某项管理功能，应用程序可能只是检查该请求是否由菜单页面发出，如果确实由该页发出，则认为用户已经有了相应的权限。这种方法并不安全。

•使用多个账户测试：

1） 如果应用程序实施垂直权限隔离，那么首先用一个高权限账户确定它能访问的所有功能，然后再用一个低权限账户遍历访问每一项功能。

基本手段：

a. 使用burp在一个高用户权限下浏览应用程序的所有内容。

b. 复查burp的站点地图，确定要测试的所功能。注销账户并使用另一个用户账户登录；使用上下文菜单选择compare site maps，确定低权限用户可以访问那些高权限请求。

2） 如果应用程序实施水平权限隔离，那么使用两个具有相同权限的不同账户进行同等测试，尝试使用一个账户访问属于另一个账户的数据。通常，这需要替换请求中的某一个标示符，如USERID、DOCID等。

3）进行访问控制测试时，一定要分别测试多阶段功能的每一个步骤，确定每一个阶段都进行了访问控制以及应用程序是否认为访问后一阶段的用户一定通过了前面阶段的安全检查。

测试基于Referer消息头的访问控制

尝试执行一些获得授权的特权操作，并提交一个其中缺少Referer消息头或其被修改的请求，如果这种改变导致应用程序阻止请求，应用程序很可能以不安全的方式使用Referer消息头。这样继续尝试使用一个未通过验证的用户账户执行相同操作，但提交原始的Referer消息头，确认系统是否能够成功执行该操作。