Cookie && Session && Token

Cookies

Cookie的由来:

HTTP 本身是一个无状态的 request/response 协议. server接收一个来自client的request, 处理完以后返回一个response。可是这个过程中, server差点儿没有什么信息能够用来判定是哪个client(用户)发来的request, 也无法记录用户的请求顺序.

Cookie是眼下识别用户。实现持久会话最好的方式。Cookie通常会跟User-Agent。Referer。X-Forwarded-For，JS等技术共同使用，为server提供更为详细的信息。

简而言之，cookie就是server为了记录用户信息而给client生成的特定信息。而且保存在client，下次发送request时携带的一个信息。

Cookie的创建

首次訪问的时候server会在返回的信息头中放入set-cookie

taobao中。client可能有不同的屏幕尺寸,我们会尽可能的去适应client屏幕，不同的分辨率、长宽比。给不同比例尺寸的图片。

这时，我们就须要client主动的告诉我们它的信息。在chrome里面我们能看到这样一个cookie的值。

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

html页面里面的一段javascript。当用户首次訪问taobao主站时。它并不会携带这个信息，此时server能够通过发现_med来推断client是否携带了这个cookie，假设发现没有携带。那么就会在响应的html页面中添加一段javascript

Session

保存在server端的client标志。

生成过程：

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

2. 开辟数据存储空间。通常会在内存中创建对应的数据结构，但这种情况下。系统一旦掉电。全部的会话数据就会丢失，假设是电子商务站点，这种事故会造成严重的后果。

只是也能够写到文件中甚至存储在数据库中，这样尽管会添加I/O开销，但session能够实现某种程度的持久化，而且更有利于session的共享；

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

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

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

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

Application：

模拟登录中Cookies

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

session劫持

參考coolshell

參考51CTO

XSS跨站

 cookie窃取和session劫持

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

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

username：明文存放。

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

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

2）上述三个东西会存在server上。server的验证用户须要验证clientcookie里的这三个事。

3）这种设计会有什么样的效果，会有以下的效果。

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

b）登录序列是用来做盗用行为检測的。

假设用户的cookie被盗后。盗用者使用这个cookie訪问站点时。我们的系统是以为是合法用户。然后更新“登录token”，而真正的用户回来訪问时，系统发现仅仅有“username”和“登录序列”同样，可是“登录token” 不正确，这种话。系统就知道，这个用户可能出现了被盗用的情况。于是，系统能够清除并更改登录序列和登录token，这样就能够令全部的cookie失效，并要求用户输入口令。并给警告用户系统安全。

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

XSS防范：

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

2. 设置sessionId的cookie为HttpOnly（使jsclient无法获取）

Token

跨站请求伪造CSRF防护方法

 CSRF危害

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

Token一般用在两个地方:

防止表单反复提交、

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

明白这个需求是，攻击者伪造链接/表单给用户目的是让server推断这个链接/表单不是正常产生的

两者在原理上都是通过session token来实现的。当client请求页面时。server会生成一个随机数Token，而且将Token放置到session其中，然后将Token发给client（一般通过构造hidden表单）。

下次client提交请求时，Token会随着表单一起提交到server端。

然后，假设应用于“anti csrf攻击”，则server端会对Token值进行验证。推断是否和session中的Token值相等，若相等，则能够证明请求有效，不是伪造的。

只是。假设应用于“防止表单反复提交”。server端第一次验证同样过后。会将session中的Token值更新下。若用户反复提交，第二次的验证推断将失败，因为用户提交的表单中的Token没变，但server端session中Token已经改变了。

上面的session应用相对安全，但也叫繁琐，同一时候当多页面多请求时，必须採用多Token同一时候生成的方法，这样占用很多其他资源，运行效率会减少。因此，也可用cookie存储验证信息的方法来取代session Token。

比方。应对“反复提交”时。当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，因为cookie已经有提交记录。因此第二次提交会失败。

只是，cookie存储有个致命弱点，假设cookie被劫持（xss攻击非常easy得到用户cookie），那么又一次gameover。黑客将直接实现csrf攻击。

所以。安全和高效相对的。

详细问题详细对待吧。

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

还需注意的是。对数据库有修改的增删改操作，须要加token验证，对于查询操作，一定不要加token。防止攻击者通过查询操作获取token进行csrf攻击。

但并非这样攻击者就无法获得token，仅仅是增大攻击成本而已。