0
0

前端安全大总结！

本文已收录于专栏
⭐️ 《计算机网络》⭐️

学习指南：

语雀前端知识沉淀

CSP 防御

CSP 是一种 浏览器的安全策略，可以帮助减少跨站点脚本攻击（XSS）、数据注入攻击等 Web 安全威胁。

CSP 的基本思想是，通过指定一系列允许加载的资源规则，实现对页面载入的外部资源的控制，防止恶意脚本注入，从而提高 Web 应用的安全性。

CSP 提供了一系列的策略指令，允许 Web 应用程序开发人员定义白名单，用于限制展示在 Web 页面中的资源的来源。

其中最基本的指令包括以下几种：

  1. default-src:
  • 用于指定加载 Web 页面时允许加载资源的默认源，包括 JavaScript 文件、CSS 文件、图片文件等。
  1. script-src:
  • 用于指定加载 JavaScript 文件的源，限制脚本文件只能来自于白名单内的源地址。
  1. style-src:
  • 用于指定加载 CSS 文件的源，限制样式文件只能来自于白名单内的源地址。
  1. img-src:
  • 用于指定加载图片文件的源，限制图片只能来自于白名单内的源地址。

为了有效使用 CSP 来防御恶意攻击，可以采取以下几个步骤：

  1. 启用 CSP：
  • 通过使用 HTTP 响应头来启用 CSP，可以让浏览器在加载 Web 页面时识别 CSP 策略。
  1. 配置 CSP 的指令：
  • 根据具体的 Web 应用程序的安全要求，设置 CSP 的指令，可以根据场景限制 Web 页面加载的来源。
  1. 使用 nonce 或 key：
  • 为了防止攻击者通过劫持 Web 页面中的资源，可以通过使用 nonce 或者 key 机制，限制只能加载特定的资源，并确保 CSP 生效。

同源 策略

如果两个URL的协议、域名和端口都相同，我们就称这两个URL同源。
比如下面这两个URL，它们具有相同的协议HTTPS、相同的域名time.geekbang.org，以及相同的端口443，
所以我们就说这两个URL是同源的。

https://time.geekbang.org/?category=1

https://time.geekbang.org/?category=0

浏览器默认两个相同的源之间是可以相互访问资源和操作DOM的。

  • 两个不同的源之间若想要相互访问资源或者操作DOM，那么会有一套基础的安全策略的制约
  • 浏览器会根据请求头中的 Origin 字段，判断出当前请求的源与目标服务器的源是否相同时
  • 如果不同浏览器会对客户端的请求进行拦截和控制，我们把这称为同源策略。

具体来讲，同源策略主要表现在DOM、Web数据和网络这三个层面。

  • 第一个，DOM层面。

同源策略限制了来自不同源的JavaScript脚本对当前DOM对象读和写的操作。

  • 第二个，数据层面。

同源策略限制了不同源的站点读取当前站点的Cookie、IndexDB、LocalStorage等数据。

  • 第三个，网络层面。

同源策略限制了通过XMLHttpRequest等方式将站点的数据发送给不同源的站点。

默认情况下，如果在A页面去请求非同源的B服务器的资源，这时同源策略会阻止其向B服务器发送请求，这样会大大制约我们的生产力。

为了解决这个问题，我们引入了跨域资源共享（CORS），使用该机制可以进行跨域访问控制，从而使跨域数据传输得以安全进行。

为什么会要有同源策略
同源策略是为了保护 Web 安全而存在的。

在 Web 上，不同的网站之间经常需要互相交换数据，如果没有同源策略的限制，就可能会导致一些安全问题。

例如，一个恶意网站可以通过某种方式，让用户在其他网站上执行一些危险操作，例如盗取用户的信息、发起 CSRF 攻击等等。

因此，浏览器引入了同源策略的限制，要求同源的网站之间才能互相交换数据。

同源指的是协议、域名、端口号都相同，只有满足这三个条件的网站之间才能互相通信。
这样，恶意网站就无法访问其他网站的数据，也无法执行一些危险操作。

XSS 攻击

Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。

攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。

利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

XSS 常见的注入方法：

  • 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入。
  • 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等）。
  • 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签。
  • 在标签的 href、src 等属性中，包含 javascript: (伪协议)等可执行代码。
  • 在 onload、onerror、onclick 等事件中，注入不受控制代码。
  • 在 style 属性和标签中，包含类似 background-image:url(“javascript:…”); 的代码（新版本浏览器已经可以防范）。
  • 在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

XSS 攻击类型

根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。

存储型 XSS

存储型 XSS 的攻击步骤：

  1. 攻击者将恶意代码提交到目标网站的数据库中。
  2. 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

存储型 XSS(又被称为持久性XSS)攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

它是最危险的一种跨站脚本，相比反射型XSS和DOM型XSS具有更高的隐蔽性，所以危害更大，因为它不需要用户手动触发。
任何允许用户存储数据的web程序都可能存在存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储，当所有浏览者访问某个页面时都会被XSS。

反射型 XSS

反射型 XSS 的攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。

反射型 XSS (也被称为非持久性XSS)漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

DOM 型 XSS

DOM 型 XSS 的攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户打开带有恶意代码的 URL。
  3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
注意:
DOM通常代表在html、xhtml和xml中的对象，使用DOM可以允许程序和脚本动态的访问和更新文档的内容、结构和样式。

它不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，所以防范**DOM型XSS完全就是前端的责任,必须注意!!!**。

image.png

防御方法

HttpOnly

在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。

输入检查

对于用户输入的数据，要进行语法、格式、长度、类型等的检查，规范化用户输入的内容，确保输入内容不含有特定的字符和代码片段，例如HTML标签、JavaScript脚本等等。

转义 HTML

转义 HTML 以避免在 HTML 中引入新标签或其他不安全的文本。

如果拼接 HTML 是必要的，就需要对于引号，尖括号，斜杠进行转义,但这还不是很完善.

想对 HTML 模板各处插入点进行充分的转义,就需要采用合适的转义库.(可以看下这个库,还是中文的)

functionescape(str){
  str = str.replace(/&/g,'&')
  str = str.replace(/</g,'&lt;')
  str = str.replace(/>/g,'&gt;')
  str = str.replace(/"/g,'&quto;')
  str = str.replace(/'/g,'&#39;')
  str = str.replace(/`/g,'&#96;')
  str = str.replace(/\//g,'&#x2F;')return str
}

CSP 防御

Content Security Policy (内容安全策略) 是一种用于指定当前页面中允许哪些来源的内容，例如 JavaScript、CSS、图片等内容的组成。

CSP可以限制客户端浏览器只从特定的来源获取并执行代码，防止恶意的脚本代码被执行。

CSP 通过定义一个白名单来允许载入的资源(如脚本、CSS、图片等)，不允许内联的脚本执行，也不允许使用绕过白名单的行内样式和 script 元素。

当浏览器执行页面，并发现有不在白名单中的源或资源，就会阻止加载页面并报告安全警告。

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

存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。

预防这两种漏洞，有两种常见做法：

  • 改成纯前端渲染，把代码和数据分隔开。
  • 对 HTML 做充分转义。

HTML转义前面已经说过,这里仅仅谈谈纯前端渲染。

纯前端渲染

  1. 浏览器先加载一个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。
  2. 然后浏览器执行 HTML 中的 JavaScript。
  3. JavaScript 通过 Ajax 加载业务数据，调用 DOM API 更新到页面上。

在纯前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。

但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文”预防 DOM 型 XSS 攻击“部分）。

在很多内部、管理系统中，采用纯前端渲染是非常合适的。但对于性能要求高，或有 SEO 需求的页面，我们仍然要面对拼接 HTML 的问题,这时就需要对HTML进行充分的转义。

预防 DOM 型 XSS 攻击

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

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

DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等。

都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。

<!-- 内联事件监听器中包含恶意代码 --><img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,"><!-- 链接内包含恶意代码 --><a href="UNTRUSTED">1</a><script>// setTimeout()/setInterval() 中调用恶意代码setTimeout("UNTRUSTED")setInterval("UNTRUSTED")// location 调用恶意代码
location.href ='UNTRUSTED'// eval() 中调用恶意代码eval("UNTRUSTED")</script>

CSRF 攻击

跨站请求伪造（英语：Cross-site request forgery），通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。
你这可以这么理解CSRF攻击：攻击者盗用了受害者的身份，以受害者的名义发送恶意请求。
CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

  1. 登录受信任网站A，并在本地生成Cookie。
  2. 在不登出A的情况下，访问危险网站B。

CSRF 攻击类型

GET类型的CSRF

<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防御也都在服务端进行。
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

Token

最常用防御方式就是在每一个请求中包含一个验证Token。
Web应用程序将该token与用户绑定，并使用该token验证提交的请求，攻击者无法伪造该token，因此无法通过这种方式提交伪造申请。

验证码

可以在敏感操作中使用验证码，要求用户手动输入正确的验证码，从而可以有效的防御CSRF的攻击。

设置同源策略

同源策略是浏览器的一项安全措施，它限制页面的脚本和数据只能与同一源（协议、域名和端口）的资源进行交互，不同源的资源无法读取和修改另一源的数据。
可以在服务器端设置这个策略，浏览器将在发送请求之前检查这个策略是否允许。

避免在URL中暴露敏感信息

尽量避免在URL参数中暴露用户的敏感数据，将这些数据作为POST请求的BODY参数或用HTTPS传输。

CSRF的特点

  • 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
  • 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
  • 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
  • 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。
  • 部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

DOS 攻击

(Denial of Service),翻译过来就是拒绝服务,一切能引起DOS行为的攻击都被称为DOS攻击。攻击者通过一系列手段，使得一个网络服务无法正常运行，或者某个网络设备无法正常工作，从而造成服务或设备的不可用或奔溃。

DOS的攻击类型

TCP SYN 攻击：

  • 攻击者发送大量伪造的 TCP SYN 请求，让服务器耗费大量资源来等待请求的响应，从而使得服务器无法处理其他合法请求，造成拒绝服务（DoS）。

UDP 攻击

  • 攻击者通过发送大量的 UDP 数据报，淹没目标主机或路由器，使其无法正常工作，造成拒绝服务。

ICMP 攻击

  • 攻击者发送大量 ICMP 数据报文，伪造 ICMP 错误信息来欺骗网络中的各个节点，造成网络拥堵，也是造成拒绝服务（DoS）的一种手段。

HTTP 攻击

  • 攻击者通过发送大量 HTTP 请求，欺骗服务器，导致服务器无法正常处理合法请求。

防御方法

配置防火墙

  • 防火墙可以通过规则过滤不合法的请求，防范 DOS 攻击。

加强身份验证

  • 有限制访问的 IP 范围、增加安全认证等。

加强监控

  • 监控网络流量，通过实时监控流量变化并且进行流量分析，以及异常行为报告等来保障网络安全管理。

加强容错机制

  • 当服务器面对流量攻击时，容错机制可以分散攻击压力，从而缓解对网络的影响。

中间人攻击

攻击者利用中间人攻击技术，通过在通信的两端间截获信息，实现信息窃取、篡改或欺骗等行为，从而达到获取敏感信息、控制通讯内容等目的。
攻击者不仅能获得双方的通信信息，还能修改通信信息。

防御方法

HTTPS

HTTPS 采用证书验证和对称加密技术，可以防止数据被窃取、篡改或重放，从而有效避免中间人攻击。

数字签名

数字签名技术能够在保证信息完整性的同时，验证信息来源的可靠性，有效防止中间人攻击，减少网络安全风险。

完结散花

ok以上就是对 前端安全大总结！的全部讲解啦，很感谢你能看到这儿。如果有遗漏、错误或者有更加通俗易懂的讲解,欢迎小伙伴私信我，我后期再补充完善。

标签： 前端 安全 javascript
本文转载自: https://blog.csdn.net/m0_66139206/article/details/129979511
版权归原作者 沈七QWQ 所有， 如有侵权，请联系我们删除。
登录后发布评论

“前端安全大总结！”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

腾讯 IEG 游戏安全面经：挑战与成长

初次使用Python+unitest+selenium环境配置

Axios与Java Spring交互：RESTful API设计与实现全解析

GitHub、Gitee、GitLab介绍

开源模型应用落地-Qwen2.5-7B-Instruct与vllm实现推理加速的正确姿势-Gradio

Spring Boot中实现多数据源连接和切换的方案

生产力神器Xmind AI：一键生成思维导图

文章导航