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一般用在两个地方:

  1. 防止表单反复提交、
  2. 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,仅仅是增大攻击成本而已。

Cookie && Session && Token的更多相关文章

  1. cookie, session, token 是什么 以及相应的安全考量

    Cookie cookie 最常见的是用来保存一些账号信息,比如下图里的 记住账号 就是记录到了cookie里面 cookie 更主要的是针对和server通信的,我们知道http 是无状态的,那如果 ...

  2. Python Web学习笔记之Cookie,Session,Token区别

    一.Cookie,Session,Token简介 # 这三者都解决了HTTP协议无状态的问题 session ID or session token is a piece of data that i ...

  3. cookie session token详解

    cookie session token详解 转自:http://www.cnblogs.com/moyand/ 发展史 1.很久很久以前,Web 基本上就是文档的浏览而已, 既然是浏览,作为服务器, ...

  4. django基础之day10,cookie session token

    https://www.cnblogs.com/Dominic-Ji/p/10886902.html cookie session token

  5. cookie,session,token介绍

    本文目录 发展史 Cookie Session Token 回到目录 发展史 1.很久很久以前,Web 基本上就是文档的浏览而已, 既然是浏览,作为服务器, 不需要记录谁在某一段时间里都浏览了什么文档 ...

  6. cookie & session & token compare

    cookie & session & token compare cookie.session.token 区别和优缺点 存储位置 cookie 存在 client 端 session ...

  7. cookie,session,token的定义及区别

    参考了很多文章总结的. 1.cookie(储存在用户本地终端上的数据) 服务器生成,发送给浏览器,浏览器保存,下次请求同一网站再发送给服务器. 2.session(会话) a.代表服务器与浏览器的一次 ...

  8. cookie,session,token的理解

    Get  POST 区别异同点 淘宝token的 理解   过程算法 防止伪造请求  伪造相对难 简单发展史  登录的操作: 哪些人往自己的购物车中放商品,  也就是说我必须把每个人区分开,这就是一个 ...

  9. cookie session token

    HTTP    HTTP是无状态(stateless)的网络协议.HTTP协议自身不对请求和响应之间的通信状态进行保存.也就是说HTTP协议对于发送过的请求或响应都不做持久化处理. 为了实现保持状态功 ...

  10. cookie session token 详解

    cookie 是保存在本地终端的数据.cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器. 可以在浏 ...

随机推荐

  1. $P5269 欧稳欧再次学车$

    \(problem\) 哇 看各位巨佬都来发\(T1\)的题解 我也来发一篇.(别的题目不会别瞎bb) 题目大意就是 \(T\) 秒 能走多少路程 第一行六个整数 \(T,N,L,R,X,K\) 接下 ...

  2. Android布局属性LayoutParams的理解

    在一次笔试中搞混LayoutParams的用法,特来总结一番: LayoutParams继承于Android.View.ViewGroup.LayoutParams.LayoutParams相当于一个 ...

  3. Spring思维课程导图——bean属性的设置

  4. Linux命令(002) -- free

    一.准备知识 Linux和Windows系统在内存管理机制方面有很大的不同.在Linux中经常发现空闲内存很少,似乎所有的内存都被系统占用了,表面感觉是内存不够用了,其实不然.这是Linux内存管理的 ...

  5. C# 接口命名规范

    接口命名规范:1.大写约定PascalCasing:帕斯卡命名法,每个单词首字母大写应用场景:命名空间.类型.接口.方法.属性.事件.字段.枚举.枚举值eg:HtmlTag IOStream注意:两个 ...

  6. vue 中展示PDF内容

    vue 中展示PDF内容 不久前有个需要改的需求,以前是直接根据链接让用户下载对应pdf文件来查看,最主要是给用户查看,然而这种并不是很安全的,其他用户可以进行下载或者使用pdf链接分享给其他人,所以 ...

  7. [Windows Server 2008] 安装IIS7.5及FTP

    ★ 欢迎来到[护卫神·V课堂],网站地址:http://v.huweishen.com★ 护卫神·V课堂 是护卫神旗下专业提供服务器教学视频的网站,每周更新视频.★ 本节我们将带领大家:安装IISII ...

  8. 您厉害您赚得多:聪明投资者的聊天记录,雪球CEO的21条投资理念

    3星|<您厉害您赚得多>:雪球创始人的投资理念.原则.技巧,及其在雪球上跟一些用户的互动的内容 作者是雪球创始人.CEO,全书基本是作者的一些投资理念+作者在雪球上跟用户的互动的内容,还有 ...

  9. HDU_5723_最小生成树+任意两点距离的期望

    Abandoned country Time Limit: 8000/4000 MS (Java/Others)    Memory Limit: 65536/65536 K (Java/Others ...

  10. C# 获取表中最大值

    ; if (db.LPicture.Any()) { // LPicture Newmode = db.LPicture.Where(n => ).FirstOrDefault(); start ...