提到浏览器安全，解析下⻚面中最基础、最核心的安全策略:
同源策略(Same-origin policy)：如果两个URL的协议、域名和端口都相同，我们就称这两个URL同源，同源策略主要表现在DOM、Web数据和网络这三个层面。
1.DOM层面：同源策略限制了来自不同源的JavaScript脚本对当前DOM对象读和写的操作。
2.数据层面：同源策略限制了不同源的站点读取当前站点的Cookie、IndexDB、LocalStorage等数据。
3.网络层面：同源策略限制了通过XMLHttpRequest等方式将站点的数据发送给不同源的站点。
安全和便利性的权衡
安全性和便利性是相互对立的，让不同的源之间绝对隔离，无疑是最安全的措施，但这也会使得Web项 目难以开发和使用。因此我们就要在这之间做出权衡，出让一些安全性来满足灵活性;而出让安全性又带来了很多安全问题，最典型的是XSS攻击和CSRF攻击。
浏览器出让了同源策略的哪些安全性
- ⻚面中可以嵌入第三方资源
- 跨域资源共享(CORS)和跨文档消息机制（可以通过 window.postMessage的JavaScript接口来和不同源的DOM进行通信）
浏览器安全可以分为三大块：Web⻚面安全、浏览器网络安全和浏览器系统安全。
1.XSS攻击
XSS全称是Cross Site Scripting，为了与“CSS”区分开来，故简称XSS，翻译过来就是“跨站脚本”。XSS 攻击是指黑客往HTML文件中或者DOM中注入恶意脚本，从而在用戶浏览⻚面时利用注入的恶意脚本对用戶 实施攻击的一种手段。
如果⻚面被注入了恶意JavaScript 脚本，恶意脚本都能做哪些事情：
1.可以窃取Cookie信息
2.可以监听用戶行为
3.可以通过修改DOM，伪造假的登录窗口，用来欺骗用戶输入用戶名和密码等信息，在⻚面内生成浮窗广告等。
常⻅的注入方式：
- 存储型XSS攻击
首先黑客利用站点漏洞将一段恶意JavaScript代码提交到网站的数据库中;
然后用戶向网站请求包含了恶意JavaScript脚本的⻚面; 当用戶浏览该⻚面的时候，恶意脚本就会将用戶的Cookie信息等数据上传到服务器。 - 反射型XSS攻击
用戶将一段含有恶意代码的请求提交给Web服务器，Web服务器接收到请求时， 又将恶意代码反射给了浏览器端，这就是反射型XSS攻击，Web服务器不会存储反射型XSS攻击的恶意脚本，这是和存储型XSS攻击不同的地方 - 基于DOM的XSS攻击
基于DOM的XSS攻击是不牵涉到⻚面Web服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用戶的⻚ 面中，比如通过网络劫持在⻚面传输过程中修改HTML⻚面的内容，这种劫持类型很多，有通过WiFi路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在Web资源传输过程或者在用戶使用⻚面的过程中修改Web⻚面的数据。
如何阻止XSS攻击
存储型XSS攻击和反射型XSS攻击都是需要经过Web服务器来处理的，是服务端的安全漏洞。
基于DOM的XSS攻击全部都是在浏览器端完成的，因此基于DOM的XSS攻击是属于前端的安全漏洞。
- 服务器对输入脚本进行过滤或转码
- 充分利用CSP
CSP有如下几个功能：
限制加载其他域下的资源文件，这样即使黑客插入了一个JavaScript文件，这个JavaScript文件也是无法 被加载的;
禁止向第三方域提交数据，这样用戶数据也不会外泄;
禁止执行内联脚本和未授权的脚本; 还提供了上报机制，这样可以帮助我们尽快发现有哪些XSS攻击，以便尽快修复问题。 - 使用HttpOnly属性
很多XSS攻击都是来盗用Cookie的，因此还可以通过使用HttpOnly属性来保护我们Cookie的安全。
2.CSRF攻击
CSRF英文全称是Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用戶打开黑客的网站，在黑客的网站中，利用用戶的登录状态发起的跨站请求。
和XSS不同的是，CSRF攻击不需要将恶意代码注入用戶的⻚ 面，仅仅是利用服务器的漏洞和用戶的登录状态来实施攻击。
如何防止CSRF攻击
- 充分利用好Cookie 的 SameSite 属性
- 验证请求的来源站点，服务器的策略是优先判断Origin，如果请求头中没有包含Origin属性，再根据实际情况判断是否使用 Referer值。
- CSRF Token
第一步，在浏览器向服务器发起请求时，服务器生成一个CSRF Token。
第二步，在浏览器端如果要发起转账的请求，那么需要带上⻚面中的CSRF Token，然后服务器会验证该 Token是否合法。如果是从第三方站点发出的请求，那么将无法获取到CSRF Token的值，故服务器就会判断不执行。
网友评论