攻击会话管理

会话和Cookie

HTTP协议没有状态。它基于一种简单的请求-响应模型，其中美队消息代表一个独立的事务。协议本身并无将某位用户提出的各种请求联系起来的机制，并将它们与Web服务器收到的其他所有请求区分开来。

绝大多数的Web“站点”实际为Web应用程序。它们允许用户注册于与登录；帮助用户购买及销售产品。它们能够在用户下次访问时记住他的喜好。它们可根据用户的单机和输入，通过动态建立的内容提供丰富。多媒体形式的使用体验。为执行这些功能，就需要使用会话。

会话（Session）机制是在服务器保存状态的方案。执行会话最简单、最常见的方法就是向每名用户发布一个唯一的会话令牌或标识符。用户在随后向应用程序提出的每一个请求中都提交这个令牌，帮助应用程序在当前请求与前面提出的请求之间建立关联。

在大多数情况下，应用程序使用HTTP Cookie最为在服务器与客户端间传送这些会话令牌的传输机制。

会话管理的基本方式

会话管理的基本方式主要有隐藏域、Cookies和URL重写。

隐藏域

隐藏域是基于客户端实现的一种方式。比如，在填写信息的时候，完成第一页，进入第二页填写的时候，将第一页的信息保存在隐藏域中，在第二页完成之后，全部一起提交给服务器。这种方式具有不少的安全问题，例如，在关掉网页之后，就会遗失信息；查看网页源代码时，容易暴露信息。

Cookie是存储key-value键值对的一个文件。它是由服务器对客户端的第一个响应中的Set-Cookie消息头指定设置的。例如：

Set-Cookie： id=123

浏览器在请求响应头中检测到Set-Cookie头之后，会自动生成一个Cookie，将id=123保存在本地。

随后客户端每次请求的时候都是用Cookie请求头，将id=123这个值带给服务器，服务器再根据123找到对应的信息来维持状态。

Cookie:id=123

URL重写

URL重写就是将需要发送给服务器的信息附加在请求链接的背后，以参数的形式发送给服务器识别。

会话的替代方案

HTTP验证

使用各种基于HTTP验证技术（基本、摘要、NTLM验证等）的应用程序有时避免使用会话。在HTTP验证中，哭护短组件使用HTTP消息头，通过浏览器直接与验证机制加护，而不是通过包含在任何单独页面中的针对特定应用程序的代码与验证机制交互。一旦用户在浏览器对话框中输入它的证书，浏览器将会在随后向同一服务器提出的每个请求中重复提交这些证书。（或重复执行任何必要的握手）这种做法等同于应用程序使用基于HTML表单的验证，并在每个应用程序页面插入一个登陆表单要求用户通过他们执行的每一项操作重复验证自己的身份。因此，如果使用基于HTTP的验证，应用程序可以不必要使用会话，而通过多个请求重复确定用户身份。然而，基于因特网的应用程序很少使用HTTP验证。而且，由于会话机制发展完善，能够提供其他用途非常广泛的功能，实际上，几乎所有的Web应用程序都采用这种机制。

无会话状态机制

一些应用程序并不发布会话令牌管理用户与应用程序的交互状态，而是传送所有必要数据（一般保存在Cookie或隐藏表单字段中），由客户端管理状态。实际上，这种机制类似于ASP.NET viewState的方式使用无会话状态。为保证这种机制的安全，必须对通过客户端传送的数据加以适当的保护。这通常要求建立一个包含所有状态信息的二级制巨对象，并使用一种公认的算法对这些数据进行加密或签名。还必须在数据中包含足够的上下文，以防止攻击者将在应用程序某个位置收集到的状态提交到另一个位置，造成某种意外行为。应用程序还必须在对象的数据中包含一个终止时间，执行与会话超时相同的功能。

会话令牌生成过程中的薄弱环节

令牌有一定含义
令牌可预测
1. 隐含序列
2. 时间依赖
3. 生成的数字随机性不强

会话令牌处理中的薄弱环节

在网络中泄露令牌
在日志中泄露令牌
令牌-会话映射易受攻击
会话终止易受攻击
客户端暴露在令牌劫持风险之中
宽泛的Cookie范围

保障会话管理的安全

生成强大的令牌

使用数量及其庞大的一组可能值；
包含强大的伪随机源，确保令牌以无法预测的方式平均分布在可能值的范围内

在整个生命周期保障令牌的安全

建立一个无法预测值的安全令牌后，就必须在这个令牌生成到废止的整个生命周期内保障它的安全，确保不会将其泄露给除令牌用户以外的其他任何人。

令牌只能通过HTTPS传送。任何以明文传送的令牌都应被视为“污染”，也就是说，不能确保用户身份不被泄露。如果使用HTTP Cookie传送令牌，应将这些cookie加上secure标识（属性），防止用户浏览器通过HTTP传送它们。如果可能，应对每个应用程序页面使用HTTPS，包括静态内容（帮助页面、图像等）。如果没有可能，仍然采用HTTP服务，那么应用程序应将任何访问敏感内容（包括登录页面）的请求重定向到HTTPS服务。帮助页面之类的静态资源一般不属于敏感内容，不需要使用通过验证的会话即可访问；因此，可以通过使用cookie范围指令强化cookie的使用安全。，防止在访问这些资源的请求中提交令牌。
绝不能再URL中传送会话令牌，这样做易于受到会话固定攻击，并可能使会话出现在各种日志机制中。
应总是执行退出功能。通过它删除服务器上的所有会话资源并终止会话令牌。
会话处于非活动状态一段时间后，应执行会话终止。会话终止的效果应和用户完全退出的作用完全相同。
应防止并行登录。
如果应用程序包含任何可以查看会话令牌的管理或诊断功能，应对这种功能加以严密保护，以防止未授权的访问。
应极可能限定应用程序会话cookie的域和路径范围。
应严格审查应用程序的代码库，以确定并删除任何跨站点脚本漏洞。
不应接受用户提交。但服务器并不认可的任意令牌。应立即在浏览器中取消该令牌，并将用户返回到应用程序的起始页面。
在执行装展示类的重要操作之前，要求进行两步确认或重新验证可有效防御跨站点请求伪造和其他会话攻击。
不完全依赖HTTP cookie传送会话令牌可防御跨站点请求伪造攻击。
成功验证后，总是建立一个新的会话，以避免会话固定攻击的影响。

日志、监控与警报

应用程序段额会话管理功能应与它的日志、监控与警报机制紧密结合，以提供适当的反常行为记录，并帮助管理员在必要时采取防御措施。

应用程序应监控包含无效令牌的请求。
很难完全阻止针对会话令牌的蛮力攻击，因为我们无法通过禁用特殊用户账户或会话来终止这种攻击。一种可能的防御方法是在收到大量包含无效令牌的请求时，将其来源IP地址屏蔽一段时间。
及时无法立即有效防止针对会话的蛮力攻击，但保留详细的日志并向管理员发出警报任然可帮助他们对攻击进行调查，并尽其所能采取适当的行动。
只要有可能，应向用户警告与会话有关的反常事件。