标签：
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Properties
HTTP是一种无状态的协议，每一对请求和响应与其他的web交互是相互独立的，如果要跟踪用户的访问状态，就需要引入会话机制，对用户的访问序列进行管理。
会话管理，将认证和访问控制（也叫授权）连接起来，在认证之前可能有未认证的会话，在访问控制之后，要有会话销毁机制。
一旦认证的会话建立，会话ID就相当于最强的认证手段， 等同于用户名和密码。
泄露、捕获、预测、和暴力破解将导致会话ID被劫持，这样攻击者可以假冒用户操作web。
为了保持用户认证状态和跟踪用户操作状态，web应用程序在提供用户会话ID，在会话创建时候，会话ID被用户和应用程序共享，并在会话存续期间内被每个HTTP请求发送，会话ID是name=value的名值对。为了实现安全会话ID的目的，会话ID的生成必须满足如下属性。
会话ID名称不能提供极端的描述性，也不能提供非必要的详细信息，关于此ID的目的和含义。
例如一些开发框架提供的会话ID的名称，暴漏了技术和编程语言，例如PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET)，
建议修改这些名称为更通用的名称，例如ID
会话ID长度必须足够长，以阻止暴力破解攻击，攻击者可遍历所有会话ID，以验证合法ID的存在性。
建议会话ID长度至少128bit，16字节长度。
会话ID必须不可预测，即足够的随机，防止猜测攻击。攻击者能够通过统计技术，预测和猜测合法会话ID。为实现这个目的，伪随机生成器必须被使用。
会话ID值必须提供64bit以上的信息熵，如果一个好的伪随机生成数被使用， 此值被估计为会话ID长度的一半。
会话ID值必须是无意义的，以防止信息泄露攻击。攻击者可以解码会话ID，提取用户、会话和web应用内部工作的信息。
推荐使用加密hash函数，创建密码式的会话ID，例如sha。
HTTP协议中有多重实现会话状态维持的机制，cookies，URL重写，GET请求中参数，POST请求中隐含表单域。
cookie最流行。
建议使用业界成熟的框架，J2EE, ASP .NET, PHP，因为它们经过安全软件的测试，和社区的修复，被证明是安全的，
但是框架过去也是存在弱点的，所以建议使用最新的版本，并修复知名的漏洞。
为了防止会话ID交换过程中，在网络流量中被窃取或者泄露，有必要使用HTTPS进行会话交互，不仅仅在认证过程，用户私密信息传递过程。
cookie的secure属性，应该被使用，确保cookie信息通过https连接传递。
加密通信也可以防止某种形式的会话固定攻击（session fixation），这种攻击在会话传输过程中，截取并操作会话，将预定的会话ID注入到用户的web浏览器。
以下最佳实践关注保护会话ID，并帮助将https集成到web应用中：
1、web应用不应该支持https和http访问之间的切换，因为此切换会将会话ID暴漏在网络数据中。
2、web应用不应该在相同域名下，支持https和http对不同资源的访问，因为未加密的通道会泄露会话ID.
3 web应用不应该在相同的域名下，支持公用资源访问和私有资源访问， 建议使用不同域名访问， 公用资源访问使用一个域名只支持 80端口， 私有资源访问使用另一个域名只支持443端口。
重要地强调下，https不能防止会话ID预测、暴力破解、客户端篡改和固化。
然而，通过网络流量抓取和泄露会话ID仍然是当前最盛行的攻击手段。
基于cookie的会话ID交换机制提供了多重安全功能，以cookie属性的形式，能被用于保护会话ID交换过程。
secure属性指导浏览器，只在https连接中发送cookie信息。
会话保护机制是必须的对于防止中间人攻击，需要确保攻击者不能简单从浏览器的网络抓获会话ID.
单纯强制规定web应用只能使用https连接，不能根本上保护会话ID不泄露，浏览器可能被欺骗使用为加密的连接发送请求，从而以明文方式发送会话ID.
httponly属性规定此cookie不能被脚本访问，例如document.cookie. 此种保护是必须的，对于防止会话ID被XSS攻击手段窃取。
domain属性规定浏览器只能发送cookie到本domain和所有子domain的主机上，如果此属性未被设置，将默认为原始服务器。
path属性规定浏览器只能发送cookie到本路径和所有子路径上，如果此属性未被设置，将默认为请求资源并设置cookie的路径。
建议设置这两个属性为窄的和严格约束的范围，这种方法，domain属性不应该设置（保证cookie属于原始服务器），path属性应该尽量严格设置为使用它的web应用的路径。
会话管理机制，利用cookie实现，分为两种，一种为持久的，另外一种为非持久型的，
如果设置了expire或者max-age属性，则cookie在浏览器端被存储到磁盘上，直到超期。
典型，对于认证之后的会话ID，一般为非持久的，这样有个好处，如果浏览器实例关闭，则会话ID丢失，会话就相当于失效了，这样可尽量减少黑客获取会话ID的时间窗口。
有两种类型的会话管理机制，一种容许性 一种严格性
容许性会话，可以接受客户端指定的内容作为会话ID，严格性只接受web应用自己生成的会话ID
尽管现代都采用严格型管理，但是程序员需要保证在特性情况下，程序中没有容许性情况出现，
web应用不应该接受一个它没有产生过的会话ID,当收到这样一个会话ID后，它需要提供一个新的自己产生的会话ID，遇到这种情况，应用应该检测为 可疑活动，一个告警应该产生。
会话ID跟其他用户输入一样，需要经过后台的校验和验证，由于会话的管理机制，会话ID从客户端的请求中获取，get post url参数或者cookie，所以客户端的发送需要经过校验。
如果服务器端不校验会话ID，就处理相应请求，攻击者就会利用web弱点，例如如果会话ID存储在数据库中，他尝试SQL注入。
会话ID应该被更新或者产生，在用户会话级别改变。
最常见的情况是， 当用户从未认证的状态切换到认证状态，会话ID必须改变，在认证过程。
其他常见场景，包括 密码改变， 权限改变， 用户级别改变（从普通用户切换为管理员），
对于web应用的关键资源，当请求到达后，需要将之前的会话ID失效，并产生一个新的会话ID给客户端，此为关键资源的授权管理机制。
如果web应用使用cookie作为会话ID交换机制， 并且多个cookie被设置到给定的会话中，则web应用必须验证所有的cookie，然后允许访问用户会话。
非常常见现象是， 用户未登录时候，会话非配一个会话ID给用户， 当用户登陆后， 分配一个新的用户ID给用户， 这两个cookie之间的关系就被确定， 如果不校验两个cookie，则攻击者很有可能使用 未登录的cookie访问已经登陆授权的资源。
为了减少攻击者攻击时间，攻击者发送攻击或者劫持会话， 必须设置会话超时时间，对于每一个会话。
不足够的会话超时，增加其他基于会话攻击的暴漏程度， 攻击者可以攻击或者劫持还生效的会话ID.
越是少的会话时间段，越是少的时间，让攻击者攻击。但是对于用户体验，也需要考虑均衡，不能为了安全，让用户经常遇到超时现象，不停登陆。
对于高风险值的会话，一般设置超时时间为 二到五分钟， 低风险值会话设置为 十五到半小时。
当会话超期，应用需要主动销毁客户端和服务器段的会话ID，后台的销毁动作更加关键。
无请求超时时间，为自从上一次页面访问之后， 到这个超时时候， 需要销毁所有超期的会话。
此机制，可以限制攻击者猜测到正确会话ID的可能性。
但是如果用户劫持此会话， idle timeout则不生效， 会话可以被攻击者一直更新， 导致此会话一直生效。
绝对超时时间，定义了会话的最大可活动时间段， 时间一到，不管用户时候活动， 都需要将当前会话销毁，要求用户重新提供认证信息。
此机制，能够限制攻击者攻击和劫持会话的时间， 冒充用户的时间。
更新超时时间， 是在此超时时间后， 会话ID将自动更新， 在用户会话过程中，与会话活动和超时无关。
新的会话ID产生后， 老的会话ID非立刻失效， 等待新的ID第一次被请求后， 则新ID生效，老的ID失效。
这种场景，减少一个给定会话ID的生存时间，同时不影响用户的会话的生存周期，
减少攻击者劫持会话的时间。
web应用应该提供机制， 对于安全敏感的用户， 则可以主动操作退出会话。
web应用应该提供可见的易于访问的退出按钮， 在任何资源页面上， 让用户可随时退出。
会话超期后， 客户端可能还是存在服务器发送回来的资源， 需要保证这些资源的的缓存类型为 不缓存
同时如果根据缓存策略， 有些内容需要缓存，但是请保证会话ID一定不能缓存。
推荐：
Cache-Control: no-cache="Set-Cookie, Set-Cookie2
客户端的保护机制，可以增强安全性， 虽然前端的保护，一般为js校验和验证， 极为有限， 对于有经验的攻击者可以绕过，但是对于入侵者， 可以增加其难度。
对于登陆页面， 也需要设置超时时间， 如果超时时间达到， 则需要将登陆页面刷新， 重新获取新的会话ID
这样可以减少会话攻击， 如果前面一个攻击者，使用错误用户名和密码登陆失败, 记住了会话ID，然后一个合法用户过来登陆，其登陆使用的还是同一个会话ID， 这样非法用户就会使用相同的会话ID，仿冒合法用户执页面操作。
使用js可以检测到浏览器窗口的关闭事件， 当事件发生， 可以模仿用户退出动作，主动销毁当前会话，
让后台会话状态可以跟前台一同销毁。
用户在一个tab中登陆， 如果用户想在另外一个新开的tab访问， 则使用js使得访问为未登陆状态。
这种方法，对cookie不适用， 因为cookie对不同tab是公用的。
使用js代码在所有页面实现， 一旦会话超期， 自动跳转到登陆页面， 这样后台会话跟着前台一并消失。
好处是， 用户可以认识到，前台超时意味着后台也超期， 是一体的，安全得很。
同时， 可以避免用户填写大量表单， 然后点提交后， 数据丢失的用户不易用问题。
攻击者为了猜测和暴力破解会话ID，其必然会通过同一个IP，将发动多次请求，使用不同的会话ID尝试。
如果发现同一个IP上会话尝试太多， 则将此IP攻击者告警 或者 锁定。
当合法会话发生操作的时候， 通过web程序内部逻辑检测异常， 有助于防范攻击，存在的cookie被删除，或者修改
会话ID在另外一个用户上重用， 例如使用user-agent来辅助检测。
会话的创建、销毁， 以及执行重要的动作， 以及会话ID更新。
并发登陆是设计的策略， 如果不支持，需要采取有效的动作，当新的会话校验后， 或者隐式销毁掉前一个会话，或者询问用户是否要销毁。
如果支持， 建议提供用户随时都可以使用的， 多用户并发访问的校验、检测和告警功能。
支持用户手动远程结束会话， 跟踪账户活动历史，记录多个客户端的 IP USER-AGENT 时间、耗时
当web应用的代码不能修改， 则引入web application firewall
标签：
原文地址：http://www.cnblogs.com/lightsong/p/4217569.html
