安全相关

关注公众号 jb51net

关闭
首页 > 网络编程 > 安全相关 > 前端常见安全问题及防范

前端常见的安全问题以及防范措施总结大全

作者：南玖

随着互联网的发达,各种WEB应用也变得越来越复杂,满足了用户的各种需求,但是随之而来的就是各种网络安全的问题,这篇文章主要给大家介绍了关于前端常见的安全问题以及防范措施的相关资料,需要的朋友可以参考下

前言

随着互联网的高速发展，信息安全问题已经成为行业最为关注的焦点之一。总的来说安全是很复杂的一个领域，在移动互联网时代，前端人员除了传统的 XSS、CSRF 等安全问题之外，还时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。这篇文章会介绍一些常见的安全问题及如何防范的内容，在当下其实安全问题越来越重要，已经逐渐成为前端开发必备的技能了。

前端安全问题

跨站脚本攻击（XSS）

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。

一般可以通过三种方式来注入恶意脚本：

反射型XSS攻击

顾名思义，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又将这部分返回给用户，恶意脚本在页面中被执行。一般发生在前后端一体的应用中，服务端逻辑会改变最终的网页代码。

反射型 XSS 的攻击步骤：

基于DOM的XSS攻击

目前更流行前后端分离的项目，反射型 XSS 无用武之地。 但这种攻击不需要经过服务器，我们知道，网页本身的 JavaScript 也是可以改变 HTML 的，黑客正是利用这一点来实现插入恶意脚本。

基于DOM 的 XSS 攻击步骤：

存储型XSS攻击

又叫持久型 XSS，顾名思义，黑客将恶意 JavaScript 脚本长期保存在服务端数据库中，用户一旦访问相关页面数据，恶意脚本就会被执行。常见于搜索、微博、社区贴吧评论等。

存储型 XSS 的攻击步骤：

这几种XSS攻击类型的区别

XSS防范措施

由上面对XSS攻击的介绍我们知道，XSS攻击主要有两大步骤：

所以我们可以针对这两点来制定防范措施：

输入过滤

在用户提交时，由前端过滤输入，然后提交到后端，这种方法不可行，因为攻击者可能绕过前端过滤，直接构造请求，提交恶意代码。一般在写入数据库前，后端对输入数据进行过滤。虽然输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

预防存储型和反射型 XSS 攻击

预防 DOM 型 XSS 攻击

DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。

在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。

如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。

DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

<!-- 内联事件监听器中包含恶意代码 -->
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">

<!-- 链接内包含恶意代码 -->
<a href="UNTRUSTED" rel="external nofollow" >1</a>

<script>
// setTimeout()/setInterval() 中调用恶意代码
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")

// location 调用恶意代码
location.href = 'UNTRUSTED'

// eval() 中调用恶意代码
eval("UNTRUSTED")
</script>

Content Security Policy

严格的 CSP 在 XSS 的防范中可以起到以下的作用：

使用 W3C 提出的 CSP (Content Security Policy，内容安全策略)，定义域名白名单

其他措施

XSS攻击案例

跨站请求伪造（CSRF）

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF是怎么攻击的？

典型的CSRF攻击是这样的：

常见的CSRF攻击类型

GET类型的CSRF

GET类型的CSRF利用非常简单，只需要一个HTTP请求，一般会这样利用：

 <img src="http://bank.example/withdraw?amount=10000&for=hacker" >

在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

POST类型的CSRF

这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

POST类型的攻击通常比GET要求更加严格一点，但仍并不复杂。任何个人网站、博客，被黑客上传页面的网站都有可能是发起攻击的来源，后端接口不能将安全寄托在仅允许POST上面。

链接类型的CSRF

链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击

  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" rel="external nofollow"  taget="_blank">
  重磅消息！！
  <a/>

CSRF的特点

CSRF防范措施

由上面对CSRF的介绍我们知道了，CSRF通常发生在第三方域名，并且CSRF攻击者不能获取到受害者的cookie等信息，只是借用他们的登录状态来伪造请求。所以我们可以针对这两点来制定防范措施：

同源检测

既然CSRF大多来自第三方网站，那么我们就直接禁止第三方域名（或者不受信任的域名）对我们发起请求。

在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名，确定请求的来源域。同时服务器应该优先检测 Origin。为了安全考虑，相比于 Referer，Origin 只包含了域名而不带路径。

CSRF Token

给 Cookie 设置合适的 SameSite

当从 A 网站登录后，会从响应头中返回服务器设置的 Cookie 信息，而如果 Cookie 携带了 SameSite=strict 则表示完全禁用第三方站点请求头携带 Cookie，比如当从 B 网站请求 A 网站接口的时候，浏览器的请求头将不会携带该 Cookie。

点击劫持（ClickJacking）

点击劫持（Clickjacking）是一种通过视觉欺骗的手段来达到攻击目的手段。往往是攻击者将目标网站通过 iframe 嵌入到自己的网页中，通过 opacity 等手段设置 iframe 为透明的，使得肉眼不可见，这样一来当用户在攻击者的网站中操作的时候，比如点击某个按钮（这个按钮的顶层其实是 iframe），从而实现目标网站被点击劫持。

点击劫持防范措施

HTTP严格传输安全（HSTS）

HTTP严格传输安全(HSTS)是一种安全功能，web服务器通过它来告诉浏览器仅用HTTPS来与之通讯，而不是使用HTTP。

HSTS代表HTTP严格传输安全性，由IETF在2012年的RFC 6797中指定。创建它是为了在站点通过HTTPS运行时强制浏览器使用安全连接。它是您添加到Web服务器的安全标头，并在响应标头中反映为Strict-Transport-Security。HSTS很重要，因为它解决了以下问题：

注意，如果之前没有使用HTTPS协议访问过该站点，那么HSTS是不奏效的，只有浏览器曾经与服务器创建过一次安全连接并且网站通过HTTPS协议告诉浏览器它支持HSTS，那么之后浏览器才会强制使用HTTPS，即使链接被换成了HTTP。

虽然我们的系统默认更喜欢HTTPS版本，但您也可以通过将您的HTTP站点重定向到您的HTTPS版本并在您的服务器上实施HSTS标头，使其他搜索引擎更清楚这一点。 —— 谷歌安全团队

开启HSTS

在Apache中启用HSTS

将以下代码添加到您的虚拟主机文件中。

Header always set Strict-Transport-Security max-age=31536000

在NGINX中启用 HSTS

将以下代码添加到您的NGINX配置中。

add_header Strict-Transport-Security max-age=31536000

事实上，添加HSTS标头有性能优势。如果有人试图通过HTTP访问您的站点，而不是发出HTTP请求，它只是重定向到HTTPS版本。

CDN劫持

CDN原理？

它的名字就叫做CDN——Content Delivery Network，内容分发网络。具体来说，CDN就是采用更多的缓存服务器（CDN边缘节点），布放在用户访问相对集中的地区或网络中。当用户访问网站时，利用全局负载技术，将用户的访问指向距离最近的缓存服务器上，由缓存服务器响应用户请求。（有点像电商的本地仓吧？）CDN应用广泛，支持多种行业、多种场景内容加速，例如：图片小文件、大文件下载、视音频点播、直播流媒体、全站加速、安全加速。

什么是CDN劫持？

网络上有很多黑客为了让用户能够登录自己开发的钓鱼网站，都会通过对CDN进行劫持的方法，让用户自动转入自己开发的网站。而很多用户却往往无法察觉到自己已经被劫持。其实验证被劫持的方法，就是输入任何网址看看所打开的网页是否和自己输入的网址一致，

CDN劫持防范措施

使用SRI来解决CDN劫持

SRI 全称 Subresource Integrity - 子资源完整性，是指浏览器通过验证资源的完整性（通常从 CDN 获取）来判断其是否被篡改的安全特性。

通过给 link 标签或者 script 标签增加 integrity 属性即可开启 SRI 功能，比如

<script type="text/javascript" src="//s.url.cn/xxxx/aaa.js" 
    integrity="sha256-xxx sha384-yyy"
    crossorigin="anonymous"></script>

integrity 值分成两个部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是经过 base64 编码的实际哈希值，两者之间通过一个短横（-）分割。integrity 值可以包含多个由空格分隔的哈希值，只要文件匹配其中任意一个哈希值，就可以通过校验并加载该资源。开启 SRI 能有效保证页面引用资源的完整性，避免恶意代码执行。

浏览器如何处理 SRI

内容安全策略（CSP）

内容安全策略（Content Security Policy）简称 CSP，通过它可以明确的告诉客户端浏览器当前页面的哪些外部资源可以被加载执行，而哪些又是不可以的。

CSP的意义

防XSS等攻击的利器。CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置。CSP 大大增强了网页的安全性。攻击者即使发现了漏洞，也没法注入脚本，除非还控制了一台列入了白名单的可信主机。

CSP的分类

CSP的使用

Content-Security-Policy: script-src 'self' https://apis.google.com
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">

安全沙箱（Sandbox）

多进程的浏览器架构将主要分为两块：浏览器内核和渲染内核。而安全沙箱能限制了渲染进程对操作系统资源的访问和修改，同时渲染进程内部也没有读写操作系统的能力，而这些都是在浏览器内核中一一实现了，包括持久存储、网络访问和用户交互等一系列直接与操作系统交互的功能。浏览器内核和渲染内核各自职责分明，当他们需要进行数据传输的时候会通过 IPC 进行。

而渲染进程的工作是进行 HTML、CSS 的解析，JavaScript 的执行等，而这部分内容是直接暴露给用户的，所以也是最容易被黑客利用攻击的地方，如果黑客攻击了这里就有可能获取到渲染进程的权限，进而威胁到操作系统。所以需要一道墙用来把不可信任的代码运行在一定的环境中，限制不可信代码访问隔离区之外的资源，而这道墙就是浏览器的安全沙箱。

安全沙箱的存在是为了保护客户端操作系统免受黑客攻击，但是阻止不了 XSS 和 CSRF。

安全沙箱是利用操作系统提供的安全技术，这样渲染进程在运行中就无法获取或修改操作系统中的数据。安全沙箱最小隔离单位是进程，所以无法保护单进程浏览器。

Iframe

iframe在给我们的页面带来更多丰富的内容和能力的同时，也带来了不少的安全隐患。因为iframe中的内容是由第三方来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端用户体验。

如何让自己的网站不被其他网站的iframe引用？

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

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

总结

到此这篇关于前端常见的安全问题以及防范措施的文章就介绍到这了,更多相关前端常见安全问题及防范内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文