面试官 🤔：关于Web安全，你知道哪些……为了保护用户的账号、财产不被窃取或利用，会在不同层面采取了一些措施 同源 用

文章包含：

• 同源策略
  • 对于不同的源：在DOM操作、网络请求等方面进行限制
• XSS 攻击
  • 注入方式：页面输入框、URL参数、路由器劫持
  • 阻止：转码、Cookie的 httpOnly、CSP限制页面脚本
• CSRF
  • 利用用户登录状态
  • 阻止：Cookie 的 sameSite、通过 referer / origin 验证来源、CSRF token
• 隔离渲染进程
  • 浏览器在架构层面将渲染进程放入沙箱，防止用户脚本直接操作系统资源
• HTTPS
  • 加密数据：对称加密、非对称加密
  • 验证服务器的真实性：数字证书

---

为了保护用户的账号、财产不被窃取或利用，会在不同层面采取了一些措施

同源

用户打开了网站A，它（以 iframe 形式）嵌着一个不同源的网站B，A、B之间如果可以随意交互的话，就有可能被黑客利用：在A中修改B的界面（诱导用户输入密码）

所以浏览器对不同源之间的DOM操作做了限制，如 window.parent window.opener 等API

现在用户访问了网站C，它里面包含了恶意脚本会把C中包含的用户数据发向 bad.com

所以浏览器又加了限制：不可以向不同的源发送 XHR、fetch 请求

这是同源策略中诸多内容的两个方面，能够说明产生这个策略的目的：给恶意脚本增加一些障碍

（如果对面的面试官只考了个 同源是怎么规定的…… 也不必难过，咱知道这事出有因

打入网站内部

黑客在网站D的评论框输入了一串代码：

<script>xxx</script>

有一用户在浏览网站D的评论时，这串代码就被执行了

黑客就利用这个流程注入了恶意代码，去窃取网站的 Cookie、监听用户输入（密码）…

注入恶意代码的攻击方式被称为 XSS。除了利用输入框注入还有其他方式

• 如果网站将 URL 中的参数直接用于页面中，那也可以将入侵脚本写在这个参数位置
• 在路由器劫持文档，并修改文档注入脚本

对于上述恶意操作，有一些措施可以去阻止：

• 对内容进行过滤/转码
• 对 Cookie 配置 HttpOnly，不让客户端操作重要的 Cookie（比如涉及用户身份）
• 使用 CSP，让网站不去执行其他来源的脚本

跨站脚本（XSS）是一种安全漏洞，允许攻击者向网站注入恶意客户端代码。该代码由受害者执行从而让攻击者绕过访问控制并冒充用户

利用网站的身份

上面黑客直接把恶意脚本送入网站内部，这次他没有

用户登之前录过他的网站E，浏览器存了他的登录信息（存放在 Cookie 中的一些值）。有天它收到一个中奖邮件，就直接点进去

进到了 bad.com，浏览了一会发现也不是什么中奖信息就直接关了。但他打开的那一瞬间，bad.com 就向E网站发了一系列请求（携带着Cookie中的登录信息），黑客利用这些请求可能执行了：修改密码、转账等操作

这种利用用户登录状态的攻击方式称为 CSRF

防止这种攻击也是从登录状态这方面入手：

• 为 Cookie 配置 SameSite 属性，不让第三方网站发送我方请求时携带 Cookie
• 在服务端验证请求来源，通过 Referer 和 Origin 两个 Header
• 登录后，服务端发送给客户端一个“自己人”的标记，CSRF Token，后面的请求都把它带上，用于表明身份

将渲染放入沙箱

上面提到的 XSS和SCRF 都是针对用户（在服务器上的）数据的攻击

还有一种可能：恶意脚本直达用户系统进行破坏

针对这种可怕的情况，浏览器在架构层将渲染进程（用于解析文档、执行脚本这类“危险”操作）放入了一个沙箱中

你在沙箱里做事情，如果出问题，把问题限制在沙箱内部。不要影响其他进程，更不要影响到系统

对于一些依赖系统的功能，通过IPC与其他进程进行通信完成

• 让网络进程沟通下载资源的事情
• 与浏览器主进程沟通展示页面的事情

加密

HTTP 是明文传输，途中任何一个节点都有可能成为黑客窃取/修改数据的机会

所以就有了 HTTPS，对数据进行加密后再发给目标，目标对数据进行解密后再做处理

用一个密钥对数据加密，在服务器使用同一个密钥进行解密（也就是对称加密）。但如果密钥被中途截获，黑客就可以利用它加解密数据

那如果客户端用公钥加密，服务端用私钥（私钥不公开）解密呢？这样可以保证公钥加密的内容（客户端发出）不被窃取，但私钥加密的内容（服务端发出）还是有可能被黑客解密（黑客可以得到公开的公钥）

非对称密钥密码，或公钥密码，是一种密钥成对出现的密码系统。由其中一个密钥执行的变换只能通过另一个密钥来解密。一个密钥（私钥）是保密的，而另一个密钥是公开的。

最终的方案是非对称加密与对称加密结合：用非对称加密来处理密钥，再用这个密钥对数据进行对称加密

• 密钥是客户端用公钥生成的，黑客无法破解（没有私钥）
• 后续数据使用对称加密，保证了效率

如果黑客通过DNS劫持，冒充服务器。那客户端可就白忙活了

面对真假服务器，需要一个权威机构（CA）来帮忙，这个机构会给真服务器一个数字证书

HTTPS连接建立之初，服务端会先把证书发过来，客户端进行验证（利用CA的公钥），“哦，是真的”，进行前面说的加密流程

有了 HTTPS，在网络中传输的数据就更难被窃取

参考

time.geekbang.org/column/arti…

web.dev/articles/sa…

developer.mozilla.org/zh-CN/docs/…

developer.mozilla.org/zh-CN/docs/…

developer.chrome.com/blog/chromi…

developer.mozilla.org/zh-CN/docs/…