2. 会话（SESSION）管理
2.1 生成SESSION的方法
无序不规则且足够长的数字、字母、符号[*1]组合成SESSION ID，既可以防止被人为猜出，也可以最大程度避免字典式攻击
*1 安全起见，推荐使用框架自动生成的SESSION ID
2.2 传输SESSION
（1）使用cookie传输是最常用的手段，但是需要防止XSS攻击，采取另外的措施（后续章节说明）
（2）把SESSION ID加入到URL上发送到后台
A. 不能直接处理此SESSION ID，因为URL是公开可见的，SESSION ID会暴露无遗，引起很多安全问题，不推荐这种方式[*1]
B. 加入cookie等元素，后台处理时根据cookie判断访问源头是否正常，比如从不同浏览器来的cookie不同，就算SESSION ID一样，也无效
C. 如果设计上允许不同浏览器访问，则可以使用类似上述手机号认证的方式，即事先生成临时密码，在不同浏览器中打开链接后提示输入临时密码
*1 手机应用开发等不会轻易暴露具体URL的情况下，可以适当使用
2.4 何时生成SESSION ID
2.4.1 恶用例：Session Fixation攻击
Session Fixation攻击，是指在要使用的Session中，加入了用户账号等相关机密信息，以此来设计开发程序时引起的问题，具体流程如下：
首先，用户通过某种途径访问登录页面，这时Session开始，Session ID随之返送给用户；
接着，输入用户名和密码等必要的登录信息，与刚才的Sesssion ID一起提交到服务器，认证成功后，即把该Session ID与用户信息关联起来。
这种情况下，攻击者通过各种手段让用户使用攻击者预先准备好的Session ID，一旦用户登录成功后，攻击者即得到同等授权，利用这个Session ID进行正常用户可以使用的任何操作。
2.4.2 对策
一句话概括，即在用户登录后，生成新的Session ID返送给用户，再进行后续操作。
就算用户使用攻击者预先准备的Session ID登录，但在服务器端认证通过后，服务器生成一个全新的Session ID返送给用户，从根本上杜绝攻击者。
不仅已有用户的登录，还是新用户的注册，都应该在设计和开发时加入该对策。
所以，在服务器端认证通过的时刻，必须要重新生成Session ID。
2.5 CSRF对策
2.5.1 根本性对策，是要让攻击者无法制造“陷阱”。
攻击者主要是通过推测页面表单里含有的各种参数信息来制造“陷阱”，所以如果表单里不含有能推测的信息，攻击者也就无从下手。
比如，通常的做法，在用户要结束某个操作之前（比如网购时点下“付款”按钮的时刻），安全起见，让用户重新输入密码，才能完成本次操作。
总之，密码也好，其它信息也好，在提交到服务器的信息中，只要有至少一个让攻击者无法预测、猜测的数据，就可根本上杜绝攻击。
2.5.2 另外一方面，面向大众开放的网站服务不能根本杜绝，但在企业等小众以及银行等有严格安全要求的网站服务上，有适用的解决方案。
（1）利用Refer的header属性。
header中保存了最近一次访问页面的URL，一般对这个URL时行判断，即可知道是否从“正规”渠道跳转过来的。
因为面向大众开放的网站服务具有多样性，无法保证该URL是否是预想的那样，所以适用性不强；
但小众的拥有特定用户的网站，并不会希望从各个渠道跳转过来，所以一开始设计时就要求URL的“正规性”，就能很好地适用。
（2）设计有步骤性的一连串多个页面。
攻击者的基本心理，是想尽快地让用户掉进“陷阱”，会设计出相对简单的页面和流程来诱导用户。
所以为了完成一个特定操作，可以设计多个步骤页面（当然不能无端随意让用户反感），“繁琐”的步骤让攻击者制造“陷阱”费时费力，较容易放弃。
每个页面都会从上个页面继承相关信息继而往下处理，这样到达服务端的数据才会完整，才能正常地被处理。
2.6 直接访问的防患与对策
。
。
这些“页面”，包括了静态的链接、文档（pdf、word等）、图像、影音流媒体、动态可执行的Javascript程序等，也在Session安全设计的对象之内。