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

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、VBScript、ActiveX、Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。

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

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

当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入一个脚本，比如一个错误信息、搜索结果等，未进行过滤直接返回到用户的浏览器上。一般发生在前后端一体的应用中，服务端逻辑会改变最终的网页代码。

反射型 XSS 的攻击步骤：

DOM 型 XSS 攻击，实际上就是前端 JavaScript 代码不够严谨，把不可信的内容插入到了页面。我们知道，网页本身的 JavaScript 也是可以改变 HTML 的，黑客正是利用这一点来实现插入恶意脚本。

基于DOM 的 XSS 攻击步骤：

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

存储型 XSS 的攻击步骤：

存储型XSS攻击的原因仍然是没有做好数据过滤：

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

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

输入检查和过滤：对所有用户输入进行严格的检查和过滤，防止恶意代码注入。这包括对表单输入、URL参数、Cookie等进行检查。确保不允许直接在页面上输出用户提交的数据，特别是在HTML中，应该对特殊字符进行转义。在用户提交时，由前端过滤输入，然后提交到后端，这种方法不可行，因为攻击者可能绕过前端过滤，直接构造请求，提交恶意代码。一般在写入数据库前，后端对输入数据进行过滤。虽然输入侧过滤能够在某些情况下解决特定的 XSS 问题，但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。

使用POST代替GET：因为GET请求会将数据放在URL中，容易被恶意用户利用来执行XSS攻击。而POST请求则将数据放在请求体中，更安全。

避免直接在Cookie中泄露用户隐私：比如email、密码等。其次通过使cookie和系统ip绑定来降低cookie泄露后的危险。

验证码：防止脚本冒充用户提交危险操作。

使用HTTPOnly标记来限制cookie的访问，防止cookie被盗用：当用户的登录凭证存储于服务器的 session 中，而在浏览器中是以 cookie 的形式存储的。很多XSS攻击目标都是窃取用户cookie伪造身份认证。可以通过在 cookie 中设置 HttpOnly 属性，js脚本将无法读取到 cookie 信息。

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

针对不同类型的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 等， 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

跨站请求伪造（CSRF）是一种黑客攻击技术，攻击者通过伪装来自受信任的用户的请求来攻击受信任的网站，利用网站对于用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作。

典型的CSRF攻击是这样的：

常见的CSRF攻击类型👇

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

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

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

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

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

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

由上面对CSRF的介绍我们知道了：

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

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

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

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

此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。

在浏览器向服务器发起请求时，服务器生成一个CSRF Token。CSRF Token 其实就是服务器生成的随机字符串，然后将该字符串植入到返回的页面中，通常是放到表单的隐藏输入框中，这样能够很好的保护CSRF Token 不被泄漏。

当浏览器再次发送请求的时候，就需要携带这个CSRF Token 值一起提交。

服务器验证 CSRF Token 是否一致；从第三方网站发出的请求是无法获取用户页面中的 CSRF Token 值的。

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

Samesite有3种模式：

点击劫持（click hijacking）也称为 UI 覆盖攻击，是一种通过视觉欺骗的手段来达到攻击目的手段。

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

在HTTP投中加入 X-FRAME-OPTIONS 属性，此属性控制页面是否可被嵌入 iframe 中。

判断当前页面是否被嵌入到 iframe 中。

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

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

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

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

integrity 值分成两个部分，第一部分指定哈希值的生成算法（sha256、sha384 及 sha512），第二部分是经过 base64 编码的实际哈希值，两者之间通过一个短横（-）分割。integrity 值可以包含多个由空格分隔的哈希值，只要文件匹配其中任意一个哈希值，就可以通过校验并加载该资源。

开启 SRI 能有效保证页面引用资源的完整性，避免恶意代码执行。

浏览器如何处理 SRI？

当浏览器在 script 或者 link 标签中遇到 integrity 属性之后，会在执行脚本或者应用样式表之前对比所加载文件的哈希值和期望的哈希值。

当脚本或者样式表的哈希值和期望的不一致时，浏览器必须拒绝执行脚本或者应用样式表，并且必须返回一个网络错误说明获得脚本或样式表失败。

强化安全意识：在项目启动阶段，就需要强调安全问题的重要性，强化所有项目成员的安全意识。让每个人都明白自己在保障项目安全方面的责任，并积极参与到安全工作中来。

建立安全管理制度：制定一套完善的安全管理制度，明确各项安全管理要求和标准。包括安全培训制度、安全操作规程、安全检查制度等，确保每个环节都得到有效管理。

实施安全性设计：从设计阶段开始，就需要注意安全性设计。遵循安全性设计原则和标准，考虑可能出现的攻击和漏洞，采取相应的防范措施。同时，需要加强数据加密、访问控制、权限管理等关键环节的安全性设计。

加强代码审查：建立代码审查机制，确保代码质量和安全性。通过定期的代码审查，可以发现并纠正潜在的安全漏洞和错误。同时，需要关注最新的安全漏洞和补丁，及时修复和升级系统。

实施安全培训：对项目成员进行安全培训，提高他们的安全意识和技能。培训内容包括安全基础知识、安全漏洞防范、应急响应等。定期组织安全培训和演练，增强项目成员的安全意识和应对能力。

建立安全测试机制：在项目开发过程中，建立安全测试机制。包括安全性测试、可靠性测试、性能测试等。通过模拟各种攻击场景和漏洞利用方式，发现并修复潜在的安全问题。同时，需要关注最新的漏洞利用方式和攻击手段，及时调整测试策略。

做好数据保护：保护项目中的敏感数据是预防安全问题的关键之一。采取加密、访问控制、数据备份等措施，确保数据的机密性和完整性。同时，需要关注数据的安全审计和监控，及时发现并应对数据安全事件。

定期审查和更新：定期审查和更新项目的安全策略和流程，以适应新的安全威胁和业务需求。同时，需要关注最新的安全漏洞和补丁，及时修复和升级系统。