写在前面
chrome要慢慢的强制禁止第三方cookie,由于这个涉及到cookie隐私安全性的。就想到与cookie强相关的跨域和跨站的问题。
跨站(Cross Site)
跨站顾名思义就是两个站之间的访问,经过A去访问B。
假如现在有一个站点A:www.example.top:443 ,那么关于跨站关系参考下表
站点B | 表现 | 是否跨站 |
---|---|---|
www.remex.com:443 | 不同域名 | 跨站 |
test.example.top:443 | 子域名不同 | 同站 |
www.example.top:443 | 协议不同 | 跨站 |
example.top:443 | www缺省 | 同站 |
www.example.top:8080 | 端口不同 | 同站 |
基本可以理解为,协议相同,二级域名相同就可以被认为是同站。
跨源(Cross Origin)
源即来源,与站类似却又不同的概念。
假如现在有一个站点A:www.example.top:443 ,那么关于跨站关系参考下表
站点B | 表现 | 是否跨站 |
---|---|---|
www.remex.com:443 | 不同域名 | 跨源 |
test.example.top:443 | 子域名不同 | 跨源 |
www.example.top:443 | 协议不同 | 跨源 |
example.top:443 | www缺省 | 跨源 |
www.example.top:8080 | 端口不同 | 跨源 |
www.example.top:443 | 完全匹配 | 同源 |
www.example.top | 默认端口缺省 | 同源 |
可以看到,跨源更为严格,必须协议、域名、端口完全匹配才被认定为同源。
安全问题
知道跨站和跨域的概念,我们来简单说一下安全问题。
跨站有CSRF(即,跨站请求伪造),跨域有CORS(即,跨域资源共享)。本质上,他俩都是通过窃取用户Cookie凭证,来去伪造该用户做一些相关操作。
CSRF
因为浏览器的机制,你登陆过的站点浏览器会把你的凭证Cookie给存储下来,当你再次访问的时候避免二次登录,直接从浏览器存储中取出来放至会话中,CSRF就是用了这个逻辑。
假如某个站点A未作安全校验,通过伪造站点B的方式,诱导你点击,来向你登陆过的某个站点发起请求,达到在你不知情的情况下进行修改数据的操作,比如修改密码。此时,你从恶意站点B被偷偷向站点A发起攻击者构造好的请求,便是跨站请求伪造。
CORS
而跨域资源共享,则是在Chrome之前推出的SOP(同源策略)基础上,由于配置不当导致的信息泄露的问题。SOP本质上限制的都是JS发起的请求,form表单并不在限制范围内。
当推出SOP策略后,由于网站本身有很多跨源的需求,比如加载第三方link等等,所以谷歌也是给出了解决方案即CORS,允许你去配置CORS策略来共享一些跨源的资源。但是,由于配置不当,比如来源限制为*(通配符,即任意),那么就可能造成预料之外的安全问题。
比如,站点A在获取用户信息处未配置好严格的CORS策略,那么攻击者可以伪造恶意站点B,向站点A的获取用户信息处通过前端JS发起异步请求,并获取信息存储。用户在登录过的站点A有过登录态,cookie被浏览器存储之后,访问站点B,那么该用户又被偷偷向站点A发起了异步请求,这个阶段浏览器会自动带上A的Cookie,这是浏览器的特性,从而获取用户信息。
假定站点A不存在CORS配置错误,严格限制来源,那么从站点B到站点A就是一个跨源请求,是不可能成功的,是会被浏览器阻断的。但是配置错误为*,就代表默认允许所有来源访问,那么就会出问题。
防范
先说CORS,SOP的策略在一定程度上保护了用户的Cookie被跨站传输恶意利用,只要严格限制CORS,那么在chrome中跨源传输cookie是不可能。
但是,CORS仅仅只能限制住由JS发起的异步请求,而CSRF使用的是form表单是不受CORS限制的。那么怎么防范呢?
在Http数据包中有一个Referer字段,假如通过B向A发起请求时,Referer即来源就是B的域名,所以粗暴的方式就是判断来源域名,或者更安全的一点是关键接口生成随机token,每次都不一样对token进行验证,即http请求中常见的csrf_token,这样的话就可以有效避免CSRF了。