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


本文转载自: https://blog.csdn.net/m0_66139206/article/details/129979511
版权归原作者 沈七QWQ 所有, 如有侵权,请联系我们删除。

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

还没有评论