浏览器:安全策略

某某某人
279 阅读12分钟

浏览器:进程与线程
浏览器:帧原理&渲染优化的基石
浏览器:安全策略

先有问题再有答案

  1. 浏览器有哪些安全策略
  2. api接口签名是什么
  3. 有了https为什么还需要api接口签名？
  4. 跨域的含义是什么
  5. 哪些操作受到同源策略限制
  6. 哪些不受到同源策略限制
  7. 有哪些常见的攻击手段
  8. 如何预防防范

系统安全

沙箱隔离

在浏览器:进程与线程这篇文章中我们介绍了渲染进程和其他进程的通信。

首先思考两个问题：

1：为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不直接从渲染进程内部去请求网络资源？

2：为什么渲染进程只负责生成页面图片，生成图片还要经过 IPC 通知浏览器内核模块，然后让浏览器内核去负责展示图片？

因为渲染进程负责执行js 解析dom,解析css等操作，如果渲染进程中出现了系统级别的漏洞，让恶意的代码控制了进程，那么将可以通过渲染进程，直接和操作系统交互甚至控制系统，这将严重危害用户。因此需要将渲染进程和系统进行隔离，并严格控制渲染进程。因此沙盒出现了。

沙箱让渲染进程在执行过程中无法访问或者修改操作系统中的数据，在渲染进程需要访问系统资源的时候，他需要先通过浏览器内核来实现访问操作，然后浏览器内核再将访问的结果通过 IPC 转发给渲染进程。

因此受到沙箱的限制：渲染进程不能直接访问网络，持久化文件，显示界面等 都要通过浏览器内核来完成。

站点隔离：

最开始chrome是以标签为单位进行进程划分的 同一个标签下即使有不同域的iframe也会在同一进程下，这带来了很大的安全隐患，恶意程序就能读取渲染进程内的所有内容。因此chrome重构了进程的划分策略，严格按照同源策略来分配渲染进程，这就是 Chrome 中的站点隔离。

网络安全：

https保护网络数据传输

http.png

  1. 数据加密：HTTPS 使用 SSL/TLS 协议对数据进行加密，确保数据在传输过程中的安全。即使数据被第三方截获，由于它们是加密的，因此第三方也无法读取到数据的真实内容。
  2. 身份验证：HTTPS 使用 SSL/TLS 证书对服务器进行身份验证。当用户访问一个 HTTPS 网站时，服务器会向用户发送一个证书。用户的浏览器会检查这个证书的有效性，包括证书的签发机构、证书的有效期、以及证书中的公钥是否与服务器的公钥匹配。只有当证书有效时，浏览器才会认为这个服务器是可信的，并建立安全连接。
  3. 完整性校验：HTTPS 使用消息摘要算法对数据进行完整性校验。这可以确保数据在传输过程中没有被篡改。
  4. 防止中间人攻击：由于 HTTPS 的身份验证和数据加密机制，即使在存在中间人的情况下，中间人也无法伪装成服务器与用户进行通信，也无法解密用户与服务器之间的通信内容。

api接口签名

在网络通信中，客户端向服务器发送请求时，通常会包含一些参数。为了防止这些参数在传输过程中被篡改，或者防止非法的请求，我们可以对这些参数进行签名。

  1. 验证请求的合法性：服务器可以通过对接收到的请求数据进行签名，并将此签名与客户端发送过来的签名进行比对，来验证此次请求是否为合法请求。只有当两者签名匹配时，服务器才会接受此次请求。

  2. 保证数据的完整性：由于客户端在生成签名时涵盖了所有的请求参数，因此，如果请求数据在传输过程中被修改，那么服务器重新生成的签名就无法与客户端传递过来的签名匹配。因此，服务器就可以据此判断出请求数据在传输过程中被篡改过。

  3. 防止重放攻击：接口签名通常会结合时间戳或者 nonce（随机数）一起使用，每次请求的签名都是唯一的。这样，即使攻击者拦截到了一次请求，并想在以后重复发送这个请求（重放攻击），由于签名已经变化，他们无法构造出有效的签名，服务器端也就可以拒绝这种被篡改过的请求。

接口签名&https区别

  1. https作用于传输层 接口签名作用于应用层
  2. https可以让让客户端验证服务器是安全的，接口签名是让服务器可以验证请求来源是安全的。

页面安全

同源策略

同源策略的"源"是由协议、主机名和端口号三部分组成的。只有当这三部分都相同，两个 URL 才被认为是同源的. 其他情况都可称为跨域

同源策略主要是用来限制不同源之间的JavaScript交互，防止恶意脚本访问或修改敏感数据。

被限制的情况

  1. dom访问
    一个网页上的 JavaScript 不能访问来自不同源的网页的 DOM。
// A页面
window.open('https://www.a.test.com'); 

// B页面
const father = window.opener.document; 
father.document.title = "aaaaa";

A&B同源B可以获取到A的dom，否则会报错。

  1. 数据存储
    JavaScript 不能读取或设置来自不同源的 Cookie, LocalStorage, sessionStorage, IndexedDB。

  2. AJAX请求

截屏2024-02-22 下午2.52.11.png

截屏2024-02-22 下午2.54.43.png

例如在www.baidu.com 访问 juejin.cn 请求可以正常发出，服务器也可以正常响应 但是拿不到返回结果 因为被浏览器拦截了。

针对限制的解决

  1. 跨域AJAX网络请求：
    可以使用cors, 服务端代理，jsonp等方案解决。

  2. 数据存储&Dom访问：

可以采用跨文档通信机制例

  • postMessage ：window.postMessage，它允许不同源的窗口之间发送和接收消息。这是一种安全的通信方式，因为发送者可以指定消息的接收者，接收者也可以验证消息的来源。

  • MessageChannel：MessageChannel API 创建了一个新的消息通道，并返回两个 MessagePort 对象，分别代表这个通道的两个端口。你可以将其中一个端口通过 postMessage 方法发送给另一个文档（包括跨域文档），然后这两个文档就可以通过这个通道进行通信。

可以跨文档但不能跨域的通信方式：

  • 窗口引用（Window references） ：如果一个窗口（或者标签、iframe）是由另一个窗口打开的，那么这两个窗口可以通过 window.opener 和 window.open 方法来相互引用。然而，这种方法只能在同源的窗口之间使用。

  • 广播频道（BroadcastChannel） ：这是一个较新的 API，它允许同源的不同窗口、标签页、iframe、web worker 之间进行通信。每个频道都有一个名字，同源的上下文可以创建或加入同名的频道，然后通过这个频道发送和接收消息。

  • 共享工作线程（Shared Worker） ：Shared Worker 是一种特殊的 web worker，它可以被同源的多个窗口、标签页、iframe 共享。这些上下文可以通过 Shared Worker 来交换消息，实现通信。

不受限制的情况

资源类标签不受跨域的影响： script, img, link, video, audio, iframe。

因为同源策略并不限制资源类的标签加载，因此页面中可以引用第三方资源，不过这也暴露了很多诸如 XSS 的安全问题，因此又在这种开放的基础之上引入了内容安全策略(CSP)来限制其自由程度。

csp(对内容的约束)

  • 限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
  • 禁止向第三方域提交数据，这样用户数据也不会外泄；
  • 禁止执行内联脚本和未授权的脚本；
  • 提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。因此，利用好 CSP 能够有效降低 XSS 攻击的概率。

截屏2024-02-23 上午11.20.08.png 在github里面动态执行脚本会被csp拦截

截屏2024-02-23 上午11.21.56.png 在google里面是可以正常执行的。

cookie安全

同源策略限制页面内的请求发送
同站策略限制请求的cookie发送

在chrome80一下浏览器默认设置samesite：none。所以 当浏览器发送请求时，如果请求的 URL 匹配 Cookie 的域和路径，那么浏览器就会自动附带上 Cookie，无论这个请求是不是跨源的。

例如，假设用户在 www.example.com  这个网站上登录了，网站会在用户的浏览器中设置一个 Cookie，用于标识用户的登录状态。然后，用户访问了另一个网站 www.attacker.com， 这个网站上有一个图片，图片的 URL 是 www.example.com/image.jpg。 当浏览器加载这个图片时，会向 www.example.com  发送一个 GET 请求，尽管这个请求是从 www.attacker.com  发起的，也就是跨源的，但是浏览器仍然会附带上 www.example.com  的 Cookie。

这也是 CSRF 攻击能够发生的一个重要原因，因为攻击者可以利用这一点，构造恶意请求，让浏览器在用户不知情的情况下，附带上 Cookie 发送请求。

chrome80以上将samesite：lax 默认情况下请求第三方不会携带cookie，可以有效解决csrf攻击。

因此需要小心设置cookie的domain, HttpOnly,SameSite等属性

常见的攻击方式

Xss攻击：

介绍

全称是 Cross Site Scripting，为了与“CSS”区分开来，故简称 XSS，翻译过来就是“跨站脚本”。

XSS 攻击是指黑客往HTML 文件中或者DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。但是发展到现在，往 HTML 文件中注入恶意代码的方式越来越多了，所以是否跨域注入脚本已经不是唯一的注入手段了，但是 XSS 这个名字却一直保留至今.

危害

窃取用户数据：攻击者可以通过 XSS 攻击窃取用户的敏感信息，如用户名、密码、电子邮件地址、信用卡信息等。例如，攻击者可以插入一个脚本，当用户访问被攻击的网站时，这个脚本会窃取用户的 Cookie，并将其发送到攻击者的服务器。

身份冒充：由于攻击者可以获取到用户的 Cookie，因此他们可以伪装成用户，进行一些恶意的操作，如发表不当言论、进行欺诈活动等。

内容篡改：攻击者可以通过 XSS 攻击篡改网页的内容，改变网站的正常显示，从而误导用户。

传播恶意软件：攻击者可以通过 XSS 攻击向用户的计算机传播恶意软件，如病毒、木马等。

进行钓鱼攻击：攻击者可以通过 XSS 攻击进行钓鱼攻击，诱骗用户访问假冒的网站，窃取用户的敏感信息。

DDoS攻击：攻击者可以利用 XSS 攻击，将大量的用户转向一个特定的网站，从而对该网站进行 DDoS 攻击。

类型

  1. 存储型: 黑客利用系统漏洞将攻击脚本存储在数据库中，当浏览器请求时返回给前端时执行
  2. 反射型： 用户将输入的恶性代码发送给服务器，服务器直接返回给页面执行，服务端并不存储。
  3. 基于DOM的XSS攻击： 黑客通过拦截网络传输等方式， 将恶意脚本通过网络注入到页面中执行

预防

XSS攻击有一个特点需要向浏览器中注入恶意脚本，所以要阻止 XSS 攻击，我们可以通过阻止恶意 JavaScript 脚本的注入和恶意消息的发送来实现，常用的阻止 XSS 攻击的策略有：

1：存储型和反射型是利用服务器对浏览器的攻击，本质上是服务器的安全问题，所以服务器需要对输入脚本进行过滤或转码，避免恶意的输入。
2：通过csp限制网页内容的加载来源 csp内容安全策略
3：使用httpOnly属性保护cookie数据

csrf攻击：

介绍

CSRF 英文全称是 Cross-site request forgery，又称为“跨站请求伪造”，指黑客引诱用户打开第三方（黑客）的网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站的登录态，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

预防

  1. 保护用户数据, 防止登录态被窃取, 正确设置cookie的安全策略例如httpOnly, 将 Cookie 的 SameSite 属性设置为 Strict

  2. 验证请求来源： 服务器可以检查每个请求的 Referer 头，确保它和请求的目标在同一个域名下。如果不在同一个域名下，那么这个请求可能是一个 CSRF 攻击。

  3. 验证生物信息&二次确认：对于一些重要的操作，如修改密码、转账等，可以要求用户进行二次确认，例如输入密码，人脸识别，指纹信息等。这可以防止攻击者在用户不知情的情况下进行 CSRF 攻击。

参考

avatar
文章
阅读
粉丝