Browser Security Knowledge

XSS

The full name of XSS is Cross Site Scripting. In order to distinguish it from "CSS", it is abbreviated as XSS, which is translated “跨站脚本”. XSS attack refers to a method in which hackers inject malicious scripts into HTML files or DOM, so as to use the injected malicious scripts to attack users when they browse the page.

Stored XSS attack

Stored XSS attacks generally need to go through the following steps:
1 First, hackers use site vulnerabilities to submit a piece of malicious JavaScript code to the website's database;
2 The user then requests a page containing a malicious JavaScript script from the website;
3 When the user browses the page, the malicious script will upload the user's cookie information and other data to the server.

Reflected XSS attack

The malicious JavaScript script is part of the request sent by the user to the website, and the website then returns the malicious JavaScript script to the user. When a malicious JavaScript script is executed in a user page, hackers can use the script to do some malicious operations.
For example, if I post a malicious script to the website behind the uninstall link, when someone clicks the link, it will trigger the malicious script.
Web servers do not store malicious scripts for reflected XSS attacks, which is different from stored XSS attacks.

DOM-based XSS attacks

Hackers inject malicious scripts into users' pages through various means, such as modifying the content of HTML pages during page transmission through network hijacking. There are many types of hijacking, some are hijacked by WiFi routers, and some are hijacked by local malware , their common point is to modify the data of the Web page in the process of Web resource transmission or in the process of user using the page.

Solution

Don't trust any input from the user, 对用户输入内容进行检查、过滤和转义.
HttpOnly HttpOnly is set by the server through the HTTP response header 使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中, so this cookie cannot be read through JavaScript.

CSRF

跨站请求伪造,CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。
一个疑问：受浏览器同源政策影响，在另一个伪造网址发送请求，为什么能到正规网站返回给用户的 session。如果是 CSRF 攻击，那么黑客是拿不到受害者站点数据的。但是黑客会在他的 A 站点中调用受害者 B 站点的 http 接口，这些接口可以是转账，删帖或者设置等。这个过程中你需要注意一点，在黑客 A 站点中调用受害者 B 站点的 http 接口时，默认情况下，浏览器依然会把受害者的 Cookie 等信息数据发送到受害者的 B 站点，【注意这里并不是黑客的 A 站点】。如果 B 站点存在漏洞的话，那么黑客就会攻击成功，比如将受害者的金币转出去了！

解决办法

Cookie 的 SameSite 属性。在 HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项，如下：

set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT; path=/;domain=.google.com; SameSite=none

SameSite 选项通常有 Strict、Lax 和 None 三个值。
Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。简言之，如果你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。
- 验证请求的来源站点
  - 由服务器端验证当前请求的来源站点，HTTP 请求头中的 Referer 和 Origin 属性 Origin 属性只包含了域名信息，并没有包含具体的 URL 路径，这是 Origin 和 Referer 的一个主要区别。
- CSRF Token
  - 第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token，存到前端。
  - 第二步，在浏览器端如果要发起转账的请求或敏感操作时，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。

安全沙箱

设计现代浏览器体系架构时，将浏览器划分为不同的进程是为了增加其稳定性。虽然设计成了多进程架构，不过这些模块之间的沟通方式却有些复杂，也许你还有以下问题：

为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不直接从进程内部去请求网络资源？
为什么渲染进程只负责生成页面图片，生成图片还要经过 IPC 通知浏览器内核模块，然后让浏览器内核去负责展示图片？
通过以上方式不是增加了工程的复杂度吗？
首先现在的 浏览器内核被划分为浏览器内核和渲染内核两个核心模块，浏览器内核包含了网络线程、GPU 进程、浏览器进程。所有的与系统相关的操作或者 id 操作都是在浏览器内核中进行的，例如（cookie 存储、cache 存储、文件下载、文件读取、网络请求等），而渲染内核中的渲染进程做哪些？（html、css 解析、js、布局、绘制）。
安全沙箱最小的保护单位是进程，所以被安全沙箱保护的进程就是渲染进程。在网络上你下载一个恶意程序，如果你不去执行他是不会有任何影响的，只有你去执行了才会有破坏，而浏览器中执行的这一步就是渲染进程去做的。

站点隔离

所谓站点隔离是指 Chrome 将同一站点（包含了相同根域名和相同协议的地址）中相互关联的页面放到同一个渲染进程中执行。
最开始 Chrome 划分渲染进程是以标签页为单位，也就是说整个标签页会被划分给某个渲染进程。但是，按照标签页划分渲染进程存在一些问题，原因就是一个标签页中可能包含了多个 iframe，而这些 iframe 又有可能来自于不同的站点，这就导致了多个不同站点中的内容通过 iframe 同时运行在同一个渲染进程中。
比如一个网站有 ABC 三个 iframe，其中 a Iframe 存在漏洞问题或者恶意程序，但是此时他们在一个渲染进程中，就有可能会对其他网站造成影响。因为沙箱隔离当前情况下只针对渲染进程，而他们却都在一个渲染进程下。
实现了站点隔离，就可以将恶意的 iframe 隔离在恶意进程内部，使得它无法继续访问其他 iframe 进程的内容，因此也就无法攻击其他站点了

HTTPS

从 HTTP 协议栈层面来看,HTTP->TCP->IP>数据链路层,而 HTTPS 实际上就是在 HTTP 和 TCP 中插入了一个安全层， HTTP->安全层（SSL/TLS）->TCP->IP>数据链路层. 安全层所做的事情就 2 件：对发起的 http 请求进行加密，对接受到的 http 内容进行解密。

对称加密

首先浏览器向服务器发送一个加密套件列表和随机数 client-random。这里的加密套件是指加密的方法，加密套件列表就是指浏览器能支持多少种加密方法列表。
服务器接收到后，选择一个加密套件，然后也生成一个随机数 service-random，然后把这些东西返回给浏览器。
此时浏览器和服务器都有了指定的加密套件和各自的随机数，使用相同的加密方法将 client-random 和 service-random 生成密钥，然后发送的内容都用密钥加密和解密。 ::: tip 浏览器和服务器在首次交换加密套件和随机数的时候是明文的，这个过程被截获的话，黑客同样能生成相对应的密钥。 :::

非对称加密

首先还是浏览器发送加密套件列表给服务器
服务器接受到后将加密套件和一个公钥返回给浏览器，浏览器自己存有私钥。
之后浏览器就用公钥加密，传给浏览器，服务器用私钥解密。然后返回的信息服务器用私钥加密，传给浏览器，浏览器用公钥解密，完成信息的交换。因为私钥只存在服务器端，黑客即使拿到数据也没办法解密。

::: tip

黑客确实没办法解密浏览器端用公钥加密的信息，但是他可以在最开始明文交换密钥的时候拿到公钥，那他就可以解密服务器端用私钥加密的信息。
非对称加密的效率太低了，这会严重影响到加解密数据的速度，进而影响到用户打开页面的速度。 :::

对称加密和非对称加密搭配使用

首先浏览器生成随机数 client-random，向服务器发送对称加密套件列表、非对称加密套间列表和 client-random。
服务器接收到以上信息后，生成 service-random，选择一个对称加密套间和非对称加密套间（生成公钥和私钥），将 service-random、公钥、对称加密套间这些信息发回给浏览器。
浏览器保存拿到的公钥，再生成一个随机数 pre-master，用公钥加密这个 pre-master，将加密的信息发送给服务器。
服务器用私钥解密出 pre-master 信息。此时服务器端和浏览器端都具有三个随机数 client-random、service-random、pre-master，利用这个三个随机数信息和指定的对称加密算法进行生成对称密钥，之后就用这个对称密钥进行信息的加解密。（黑客可以截获 pre-master，但他无法解密，因为他没有私钥）

简单来说就是在传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输。用非对称加密进行对称加密时的密钥交换，是其不以明文的形式暴露。 ::: tip 是黑客通过 DNS 劫持将极客时间官网的 IP 地址替换成了黑客的 IP 地址，这样我访问的其实是黑客的服务器了，黑客就可以在自己的服务器上实现公钥和私钥，而对浏览器来说，它完全不知道现在访问的是个黑客的站点。所以问题了来了，我怎么证明我是我？ :::