前端安全问题以及解决方案汇总

随着大前端的快速发展，各种技术不断更新，前端的安全问题也值得我们重视。今天我们来聊一聊前端常见的7个安全方面问题：
1.iframe
2.opener
3.CSRF（跨站请求伪造）
4.XSS（跨站脚本攻击）
5.ClickJacking（点击劫持）
6.HSTS（HTTP严格传输安全）
7.CND劫持

iframe

1.如何让自己的网站不被其他网站使用iframe引用

if(top.location !== window.location){top.location.href = xxx
}

当发现我们的网站被其他网站引用时，可以强制使网站跳转到其他网站。

2.如何禁用，被使用的 iframe 对当前网站某些操作？

sandbox是html5的新属性，主要是提高iframe安全系数。iframe因安全问题而臭名昭著，这主要是因为iframe常被用于嵌入到第三方中，然后执行某些恶意操作。
现在有一场景：我的网站需要 iframe 引用某网站，但是不想被该网站操作DOM、不想加载某些js（广告、弹框等）、当前窗口被强行跳转链接等，我们可以设置 sandbox 属性。如使用多项用空格分隔。

参考：HTML sandbox 属性

allow-same-origin：允许被视为同源，即可操作父级DOM或cookie等
allow-top-navigation：允许当前iframe的引用网页通过url跳转链接或加载
allow-forms：允许表单提交
allow-scripts：允许执行脚本文件
allow-popups：允许浏览器打开新窗口进行跳转
“”：设置为空时上面所有允许全部禁止

opener

如果在项目中需要打开新标签进行跳转一般会有两种方式：

// 1) HTML -> <a target='_blank' href='http://www.baidu.com'>
// 2)  JS  -> window.open('http://www.baidu.com')/* * 这两种方式看起来没有问题，但是存在漏洞。* 通过这两种方式打开的页面可以使用 window.opener 来访问源页面的 window 对象。* 场景：A 页面通过 <a> 或 window.open 方式，打开 B 页面。但是 B 页面存在恶意代码如下：* window.opener.location.replace('https://www.baidu.com') 【此代码仅针对打开新标签有效】* 此时，用户正在浏览新标签页，但是原来网站的标签页已经被导航到了百度页面。* 恶意网站可以伪造一个足以欺骗用户的页面，使得进行恶意破坏。* 即使在跨域状态下 opener 仍可以调用 location.replace 方法。*/

解决方案：

当使用a标签跳转时，

<a target="_blank" href="" rel="noopener noreferrer nofollow">a标签跳转url</a><!-- 通过 rel 属性进行控制：noopener：会将 window.opener 置空，从而源标签页不会进行跳转（存在浏览器兼容问题）noreferrer：兼容老浏览器/火狐。禁用HTTP头部Referer属性（后端方式）。nofollow：SEO权重优化，详情见 https://blog.csdn.net/qq_33981438/article/details/80909881-->

当使用window.open跳转时，

<button onclick='openurl("http://www.baidu.com")'>click跳转</button>function openurl(url) {var newTab = window.open();newTab.opener = null;newTab.location = url;
}

CSRF / XSRF（跨站请求伪造）

你可以这么理解 CSRF 攻击：攻击者盗用了你的身份，以你的名义进行恶意请求。它能做的事情有很多包括：以你的名义发送邮件、发信息、盗取账号、购买商品、虚拟货币转账等。总结起来就是：个人隐私暴露及财产安全问题。

/** 阐述 CSRF 攻击思想：（核心2和3）* 1、浏览并登录信任网站（举例：淘宝）* 2、登录成功后在浏览器产生信息存储（举例：cookie）* 3、用户在没有登出淘宝的情况下，访问危险网站* 4、危险网站中存在恶意代码，代码为发送一个恶意请求（举例：购买商品/余额转账）* 5、携带刚刚在浏览器产生的信息进行恶意请求* 6、淘宝验证请求为合法请求（区分不出是否是该用户发送）* 7、达到了恶意目标*/

一般CSRF形式上有三种表现：
1.自动发起 Get 请求
模拟代码如下：

1 <!DOCTYPE html> 
<html>
<body> 
<h1> 黑客的站点：CSRF 攻击演示 </h1> 
<img src="https://time.geekbang.org/sendcoin?user=hacker&number=100">
</body> 
</html>

攻击者将请求转账的链接隐藏在精美的图片里，当你点击时，就会想服务器发起请求。

2.自动发起 POST 请求
模拟代码如下：

<!DOCTYPE html> 
<html>
<body>
<h1> 黑客的站点：CSRF 攻击演示 </h1>
<form id='hacker-form' action="https://time.geekbang.org/sendcoin" method="POST">
<input type="hidden" name="user" value="hacker" />
<input type="hidden" name="number" value="100" /> 
</form> 
<script>
document.getElementById('hacker-form').submit(); 
</script>
</body> 
</html>

在这段代码中，我们可以看到黑客在他的页面中构建了一个隐藏的表单，该表单的内容就是极客时间的转账接口。当用户打开该站点之后，这个表单会被自动执行提交；当表单被提交之后，服务器就会执行转账操作。因此使用构建自动提交表单这种方式，就可以自动实现跨站点 POST 数据提交。

引诱用户点击链接
除了自动发起 Get 和 Post 请求之外，还有一种方式是诱惑用户点击黑客站点上的链接，这种方式通常出现在论坛或者恶意邮件上。黑客会采用很多方式去诱惑用户点击链接，示例代
码如下所示：

<div> 
<img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg> </img> 
<a href="https://time.geekbang.org/sendcoin?user=hacker&number=100" taget="_b 4 点击下载美女照片</a> 
</div>

这段黑客站点代码，页面上放了一张美女图片，下面放了图片下载地址，而这个下载地址实际上是黑客用来转账的接口，一旦用户点击了这个链接，那么他的极客币就被转到黑客账户上了。

解决方案：

利用好 Cookie 的 SameSite 属性

在 HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项，如下：
set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT;SameSite=Strict;
SameSite 选项通常有 Strict、Lax 和 None 三个值。
Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方Cookie。简言之，如果你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些Cookie 设置了 SameSite = Strict 的话
那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，
这些场景都不会携带 Cookie。
而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。

验证请求的来源站点
利用http请求头中的referer或者origin字段告诉服务器请求来源，让服务端判断自否禁止该请求。
CSRF Token
除了使用以上两种方式来防止 CSRF 攻击之外，还可以采用 CSRF Token 来验证，这个流程比较好理解，大致分为两步：
第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。你可以参考下面示例代码：

第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到CSRF Token 的值，
所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。

XSS/CSS（跨站脚本攻击）

XSS 全称是 Cross Site Scripting，为了与“CSS”区分开来，故简称 XSS，翻译过来就是“跨站脚本”。XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在
用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。
可以将XSS分为三种：存储型XSS、反射型XSS以及基于dom的XSS。
存储型 XSS 攻击大致需要经过如下步骤：
1.首先黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；
2.然后用户向网站请求包含了恶意 JavaScript 脚本的页面；
3.当用户浏览该页面的时候，恶意脚本就会将用户的 Cookie 信息等数据上传到黑客服务器。

反射型XSS是指将可以script脚本插入用户请求的url中，当请求被服务器处理后又反射回给用户，web服务器并不会存储这段script脚本。

基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内
容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。

解决方案：

服务器对输入脚本进行过滤或转码
不管是反射型还是存储型 XSS 攻击，我们都可以在服务器端将一些关键的字符进行转码，比如最典型的：

code:<script>alert('你被 xss 攻击了')</script>

这段代码过滤后，只留下了：

code：

这样，当用户再次请求该页面时，由于script标签的内容都被过滤了，所以这段脚本在客户端是不可能被执行的。
除了过滤之外，服务器还可以对这些内容进行转码，还是上面那段代码，经过转码之后，效果如下所示：

code:&lt;script&gt;alert(&#39; 你被 xss 攻击了 &#39;)&lt;/script&gt;

经过转码之后的内容，如script标签被转换为<script>，因此即使这段脚本返回给页面，页面也不会执行这段脚本。

充分利用 CSP
csp又叫内容安全策略，可以把它看做是一个白名单，告诉浏览器哪些第三方资源可以执行。
使用 HttpOnly 属性
由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。
通常服务器可以将某些 Cookie 设置为 HttpOnly 标志，HttpOnly 是服务器通过 HTTP 响应头来设置的：

set-cookie: xxx;httpOnly;

ClickJacking（点击劫持）

ClickJacking 翻译过来被称为点击劫持。一般会利用透明 iframe 覆盖原网页诱导用户进行某些操作达成目的。
解决方案：

在HTTP投中加入 X-FRAME-OPTIONS 属性，此属性控制页面是否可被嵌入 iframe 中【DENY：不能被所有网站嵌套或加载；SAMEORIGIN：只能被同域网站嵌套或加载；ALLOW-FROM URL：可以被指定网站嵌套或加载。】
判断当前网页是否被 iframe 嵌套（详情在第一条 firame 中）

HSTS（HTTP Strict Transport Security：HTTP严格传输安全）

网站接受从 HTTP 请求跳转到 HTTPS 请求的做法，例如我们输入“http://www.baidu.com”或“www.baidu.com”最终都会被302重定向到“https://www.baidu.com”。这就存在安全风险，当我们第一次通过 HTTP 或域名进行访问时，302重定向有可能会被劫持，篡改成一个恶意或钓鱼网站。
HSTS：通知浏览器此网站禁止使用 HTTP 方式加载，浏览器应该自动把所有尝试使用 HTTP 的请求自动替换为 HTTPS 进行请求。用户首次访问时并不受 HSTS 保护，因为第一次还未形成链接。我们可以通过 浏览器预置HSTS域名列表 或将HSTS信息加入到域名系统记录中，来解决第一次访问的问题。

CDN劫持

出于性能考虑，前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面，例如 js 脚本和 style 文件。这么做可以显著提高前端应用的访问速度，但与此同时却也隐含了一个新的安全风险。如果攻击者劫持了CDN，或者对CDN中的资源进行了污染，攻击者可以肆意篡改我们的前端页面，对用户实施攻击。
现在的CDN以支持SRI为荣，script 和 link 标签有了新的属性 integrity，这个属性是为了防止校验资源完整性来判断是否被篡改。它通过验证获取文件的哈希值是否和你提供的哈希值一样来判断资源是否被篡改。
使用 SRI 需要两个条件：一是要保证资源同域或开启跨域，二是在script标签中 提供签名 以供校验。