Cookie && Session && Token

Cookies

Cookie的由来:

HTTP 本身是一个无状态的 request/response 协议. 服务器接收一个来自客户端的request, 处理完以后返回一个response。 但是这个过程中, 服务器几乎没有什么信息可以用来判定是哪个客户端(用户)发来的request, 也无法记录用户的请求顺序.

Cookie是目前识别用户，实现持久会话最好的方式。Cookie通常会跟User-Agent，Referer，X-Forwarded-For，JS等技术共同使用，为服务器提供更为详细的信息。简而言之，cookie就是服务器为了记录用户信息而给客户端生成的特定信息，并且保存在客户端，下次发送request时携带的一个信息。

Cookie的创建

首次访问的时候服务器会在返回的信息头中放入set-cookie



taobao中，客户端可能有不同的屏幕尺寸,我们会尽可能的去适应客户端屏幕，不同的分辨率、长宽比，给不同比例尺寸的图片。这时，我们就需要客户端主动的告诉我们它的信息。在chrome里面我们能看到这样一个cookie的值。

_med参数就是表面屏幕尺寸的

html页面里面的一段javascript。当用户首次访问taobao主站时，它并不会携带这个信息，此时服务器可以通过发现_med来判断客户端是否携带了这个cookie，如果发现没有携带，那么就会在响应的html页面中加入一段javascript



Session

保存在服务器端的客户端标志。

生成过程：

1. 生成全局唯一标识符（sessionid）

2. 开辟数据存储空间。 一般会在内存中创建相应的数据结构，但这种情况下，系统一旦掉电，所有的会话数据就会丢失，如果是电子商务网站，这种事故会造成严重的后果。不过也可以写到文件里甚至存储在数据库中，这样虽然会增加I/O开销，但session可以实现某种程度的持久化，而且更有利于session的共享；

3. 将session的全局唯一标示符发送给客户端。 问题的关键就在服务端如何发送这个session的唯一标识上。联系到HTTP协议，数据无非可以放到请求行、头域或Body里，基于此，一般来说会有两种常用的方式：cookie和URL重写。

4. 服务端只要设置Set-cookie头就可以将session的标识符传送到客户端，而客户端此后的每一次请求都会带上这个标识符，由于cookie可以设置失效时间，所以一般包含session信息的cookie会设置失效时间为0，即浏览器进程有效时间。至于浏览器怎么处理这个0，每个浏览器都有自己的方案，但差别都不会太大（一般体现在新建浏览器窗口的时候）；

5. URL重写 所谓URL重写，顾名思义就是重写URL。试想，在返回用户请求的页面之前，将页面内所有的URL后面全部以get参数的方式加上session标识符（或者加在path info部分等等），这样用户在收到响应之后，无论点击哪个链接或提交表单，都会在再带上session的标识符，从而就实现了会话的保持。读者可能会觉得这种做法比较麻烦，确实是这样，但是，如果客户端禁用了cookie的话，URL重写将会是首选。

Session的数据结构的要求：同步、易操作。因此使用ConcurrentHashMap来存放。

Application：

模拟登录中Cookies

验证码问题，访问/login，同时访问了验证码生成页面/codeimage，此时的Session[‘codeimage’]=此时生成的验证码。要是刷新一下，服务器Session存储就变成新的了。

session劫持

参考coolshell

参考51CTO

XSS跨站

cookie窃取和session劫持

服务器生成的用以标识客户信息的cookie一般被称为sessionId，而通过一些手段获取其它用户sessionId的攻击就叫session劫持。

1）在cookie中，保存三个东西——用户名，登录序列，登录token。

用户名：明文存放。

登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。

登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。

2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。

3）这样的设计会有什么样的效果，会有下面的效果，

a）登录token是单实例登录。意思就是一个用户只能有一个登录实例。

b）登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token” 不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。

4）当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址

XSS防范：

1. 过滤用户输入，防止XSS漏洞

2. 设置sessionId的cookie为HttpOnly（使js客户端无法获取）

Token

跨站请求伪造CSRF防护方法

CSRF危害

Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。

Token一般用在两个地方:

防止表单重复提交、

anti csrf攻击（跨站点请求伪造）。

明确这个需求是，攻击者伪造链接/表单给用户目的是让服务器判断这个链接/表单不是正常产生的

两者在原理上都是通过session token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端。

然后，如果应用于“anti csrf攻击”，则服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。

不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。

上面的session应用相对安全，但也叫繁琐，同时当多页面多请求时，必须采用多Token同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用cookie存储验证信息的方法来代替session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，由于cookie已经有提交记录，因此第二次提交会失败。

不过，cookie存储有个致命弱点，如果cookie被劫持（xss攻击很容易得到用户cookie），那么又一次gameover。黑客将直接实现csrf攻击。

所以，安全和高效相对的。具体问题具体对待吧。

此外，要避免“加token但不进行校验”的情况，在session中增加了token，但服务端没有对token进行验证，根本起不到防范的作用。

还需注意的是，对数据库有改动的增删改操作，需要加token验证，对于查询操作，一定不要加token，防止攻击者通过查询操作获取token进行csrf攻击。但并不是这样攻击者就无法获得token，只是增大攻击成本而已。