1. XSS攻击
XSS攻击:注入恶意代码攻击.
比如input框里面别人如果输入一段恶意的脚本代码直接解析,就有可能造成数据的不安全
解决办法:
1.cookie设置httpOnly
2.转义页面上的输入内容和输出内容
2. CSRF:跨站点请求伪造
解决办法:
1.get请求不修改数据;
2.不被第三方网站访问到用户的 cookie;
3.设置白名单,不被第三方网站请求;
4.请求加校验
3. 没有同源策略限制的两大危险场景
浏览器是从两个方面去做这个同源策略的,一是针对接口的请求,二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。
3.1 没有同源策略限制的接口请求
有一个小小的东西叫cookie大家应该知道,一般用来处理登录等场景,目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录,服务端验证通过后会在响应头加入Set-Cookie字段,然后下次再发请求的时候,浏览器会自动将cookie附加在HTTP请求的头字段Cookie中,服务端就能知道这个用户已经登录过了。知道这个之后,我们来看场景:
你准备去清空你的购物车,于是打开了买买买网站www.maimaimai.com
,然后登录成功,一看,购物车东西这么少,不行,还得买多点。
你在看有什么东西买的过程中,你的好基友发给你一个链接www.nidongde.com
,一脸yin笑地跟你说:“你懂的”,你毫不犹豫打开了。
你饶有兴致地浏览着www.nidongde.com
,谁知这个网站暗地里做了些不可描述的事情!由于没有同源策略的限制,它向www.maimaimai.com
发起了请求!聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段,然后下次再发请求的时候,浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”,这样一来,这个不法网站就相当于登录了你的账号,可以为所欲为了!如果这不是一个买买买账号,而是你的银行账号,那……
3.2 没有同源策略限制的DOM查询
有一天你刚睡醒,收到一封邮件,说是你的银行账号有风险,赶紧点进www.yinghang.com
改密码。你吓尿了,赶紧点进去,还是熟悉的银行登录界面,你果断输入你的账号密码,登录进去看看钱有没有少了。
睡眼朦胧的你没看清楚,平时访问的银行网站是www.yinhang.com
,而现在访问的是www.yinghang.com
,这个钓鱼网站做了什么呢?
<iframe name="yinhang" src="www.yinhang.com"></iframe>
// JS
// 由于没有同源策略的限制,钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node},我还拿不到你刚刚输入的账号密码吗`)
由此我们知道,同源策略确实能规避一些危险,不是说有了同源策略就安全,只是说同源策略是一种浏览器最基本的安全机制,毕竟能提高一点攻击的成本。其实没有刺不穿的盾,只是攻击的成本和攻击成功后获得的利益成不成正比。