From 40e54244831b0f45382814867b33a52efd9c0d15 Mon Sep 17 00:00:00 2001
From: lvzl <627417163@qq.com>
Date: Tue, 19 Sep 2023 10:23:18 +0800
Subject: [PATCH] feat(network)

---
 articles/network/cross-origin.md   | 10 ++++
 articles/network/csrf.md           | 76 ++++++++++++++++++++++++++++++
 articles/network/http-resp-code.md | 39 +++++++++++++++
 articles/network/index.md          | 11 +++++
 articles/network/nav.js            |  4 ++
 articles/network/xss.md            | 65 +++++++++++++++++++++++++
 6 files changed, 205 insertions(+)
 create mode 100644 articles/network/cross-origin.md
 create mode 100644 articles/network/csrf.md
 create mode 100644 articles/network/http-resp-code.md
 create mode 100644 articles/network/index.md
 create mode 100644 articles/network/nav.js
 create mode 100644 articles/network/xss.md

diff --git a/articles/network/cross-origin.md b/articles/network/cross-origin.md
new file mode 100644
index 0000000..adbb015
--- /dev/null
+++ b/articles/network/cross-origin.md
@@ -0,0 +1,10 @@
+---
+title: 跨域及其解决方案
+author: lvzl
+---
+
+<script setup>
+  import XmindViewer from '@/XmindViewer'
+</script>
+
+<XmindViewer url="https://mp-cb2e47ef-a802-469a-a81c-2b6efa9f8b60.cdn.bspapp.com/blog-resource/xmind/cross-origin.xmind"/>
diff --git a/articles/network/csrf.md b/articles/network/csrf.md
new file mode 100644
index 0000000..f4adf0b
--- /dev/null
+++ b/articles/network/csrf.md
@@ -0,0 +1,76 @@
+---
+title: 网络安全之CSRF攻击
+author: lvzl
+---
+
+## 是什么
+
+CSRF（Cross-site request forgery）跨站请求伪造：攻击者**诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求**。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
+
+一个典型的 CSRF 攻击有着如下的流程：
+
+1. 受害者登录 a.com，并保留了登录凭证（Cookie）。
+2. 攻击者引诱受害者访问了 b.com。
+3. b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会…
+4. a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
+5. a.com 以受害者的名义执行了 act=xx。
+6. 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作。
+
+## 特点是什么
+
+1. CSRF（通常）发生在第三方域名。
+2. CSRF 攻击者不能获取到 Cookie 等信息，只是使用。
+3. 通常是跨域请求
+
+## 有哪些类型
+
+### GET 类型的 CSRF
+
+```html
+ <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
+
+```html
+ <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 操作。
+
+### 链接类型的 CSRF
+
+```html
+  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
+  重磅消息！！
+  <a/>
+
+```
+
+需要点击才会中招。
+
+## 如何防范
+
+1. 同源检测，通过请求头中的 origin、referer 确定域名是否是合法的域名，外域直接禁止。但在某些场景可能两者都获取不到，这种情况建议直接禁止；还有可能 referer 被修改，并不太可靠。
+2. CSRF Token
+  - 用户登录以后 -> 加密算法对数据进行加密生成 token，并将用户信息放到 session -> 返回给前端，但是不能放到 cookie 了
+  - 用户请求，带上这个 token -> 服务器解密这个 token，并从 session 取出用户信息比对，看是否一致。不过针对那种 标签上的 href、src 等请求，就需要开发人员手动设置上 token
+  - 这种方式 session 默认存储在单机服务器内存中，只能运用在单机的服务器上，不适用于分布式的服务。
+  - 读取和验证CSRF Token会引起比较大的复杂度和性能问题
+3. 分布式校验
+  - 服务器通过一种加密算法根据用户信息得到一个token（userinfo.签名），保证签名不容易被破解，不再往 session 存 token
+  - 请求携带过来的token，拿到 userinfo，只需要再按同样的加密算法计算一次，比较与携带过来的是否一致，即可得出是不是伪造的token
+  - 比较可靠
+4. 双重cookie验证，双重Cookie采用以下流程：
+  - 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
+  - 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
+  - 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
+  - 安全性还是没有CSRF Token高
+5. sameSite 设置为 strict，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie，绝无例外。
diff --git a/articles/network/http-resp-code.md b/articles/network/http-resp-code.md
new file mode 100644
index 0000000..26b1c40
--- /dev/null
+++ b/articles/network/http-resp-code.md
@@ -0,0 +1,39 @@
+---
+title: http 响应状态码
+author: lvzl
+---
+
+HTTP 请求状态码是 Web 服务器向客户端返回的 3 位数字代码，用于指示 HTTP 请求的结果和状态。这些状态码分为五个不同的类别，每个类别具有特定的含义。以下是一些常见的 HTTP 请求状态码和它们的含义：
+
+1. **1xx（信息性状态码）**：这些状态码表示请求已被接收，继续处理。
+
+   - **100 Continue**: 服务器正在等待继续的请求头。客户端可以发送请求的主体部分。
+
+2. **2xx（成功状态码）**：这些状态码表示请求已成功被服务器接收、理解、并接受。
+
+   - **200 OK**: 请求成功，服务器已经返回请求的资源。
+   - **201 Created**: 请求已成功，并且服务器创建了新的资源。
+   - **204 No Content**: 请求成功，但服务器没有返回任何内容。
+
+3. **3xx（重定向状态码）**：这些状态码表示客户端需要执行额外的操作以完成请求。
+
+   - **301 Moved Permanently**: 资源已永久移动到新位置，客户端应该更新其链接。
+   - **302 Found**: 资源临时移动到新位置，客户端应该使用新位置重新发起请求（有时用于实现重定向）。
+   - **304 Not Modified**: 资源未被修改，客户端可以使用缓存的内容。
+
+4. **4xx（客户端错误状态码）**：这些状态码表示客户端发送的请求有误，服务器无法处理。
+
+   - **400 Bad Request**: 请求语法或参数错误，服务器无法理解。
+   - **401 Unauthorized**: 请求未进行身份验证或身份验证失败。
+   - **403 Forbidden**: 服务器拒绝了请求，通常因为权限不足。
+   - **404 Not Found**: 请求的资源在服务器上未找到。
+   - **405 Method Not Allowed**: 请求使用了不被允许的 HTTP 方法。
+
+5. **5xx（服务器错误状态码）**：这些状态码表示服务器在处理请求时发生了错误。
+
+   - **500 Internal Server Error**: 服务器遇到了意外的错误，无法完成请求。
+   - **502 Bad Gateway**: 服务器作为网关或代理，从上游服务器接收到无效响应。
+   - **503 Service Unavailable**: 服务器暂时不可用，通常是由于维护或过载。
+   - **504 Gateway Timeout**: 服务器作为网关或代理，从上游服务器没有及时收到响应。
+
+这些 HTTP 状态码是 HTTP 协议的一部分，用于在客户端和服务器之间传递关于请求和响应状态的信息。它们帮助开发人员和系统管理员了解请求的结果以及如何处理它们。当开发 Web 应用程序时，理解这些状态码是非常重要的，因为它们可以帮助您调试和解决问题。
diff --git a/articles/network/index.md b/articles/network/index.md
new file mode 100644
index 0000000..32733f5
--- /dev/null
+++ b/articles/network/index.md
@@ -0,0 +1,11 @@
+---
+title: 网络
+author: lvzl
+---
+记录一些网络相关的知识！
+
+<script setup>
+  import XmindViewer from '@/XmindViewer'
+</script>
+
+<XmindViewer url="https://mp-cb2e47ef-a802-469a-a81c-2b6efa9f8b60.cdn.bspapp.com/blog-resource/xmind/browser-rendering-flow.xmind"/>
diff --git a/articles/network/nav.js b/articles/network/nav.js
new file mode 100644
index 0000000..49817e7
--- /dev/null
+++ b/articles/network/nav.js
@@ -0,0 +1,4 @@
+module.exports = {
+  navText: '计算机网络相关',
+  sort: 9,
+}
diff --git a/articles/network/xss.md b/articles/network/xss.md
new file mode 100644
index 0000000..3de02c0
--- /dev/null
+++ b/articles/network/xss.md
@@ -0,0 +1,65 @@
+---
+title: 网络安全之XSS攻击
+author: lvzl
+---
+
+## 是什么
+
+`Cross-Site Scripting`（跨站脚本攻击）简称 `XSS`，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 `Cookie` 等，进而危害数据安全。
+为了和 `CSS` 区分，这里把攻击的第一个字母改成了 `X`，于是叫做 `XSS`。
+`XSS` 的本质是：**恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。**
+
+## 特点是什么
+
+**恶意代码直接在用户的终端执行，可以访问用户信息（cookie 等），发起攻击请求**
+
+## 有哪些类型
+
+`XSS` 攻击可分为`存储型`、`反射型`和 `DOM 型`三种。
+
+### 存储型
+
+假如我在掘金写的文章里，加了一些恶意的脚本：
+
+```html
+<script>alert('我正在攻击你')</script>
+```
+
+如果掘金没有处理，那么当别的用户打开我的文章，我的脚本就能执行，这就是典型的存储型`XSS` 攻击。
+
+### 反射型
+
+我这次改了一种方式，我在文章里加了一个超链接：
+
+```html
+嘿，点击这里查看有趣的照片：<a href="https://xxx.com/?image=<script>alert('这可是你自己点了，我才攻击你');</script>">点击这里</a>
+```
+
+这就是典型的反射型`XSS` 攻击。
+
+### DOM 型
+
+假如掘金的评论是前端动态添加到页面，那么我在评论中写到：
+
+```html
+<script>alert('我正在攻击你')</script>
+```
+
+此时正在浏览这篇文章的另一个人的客户端收到我新增的评论，然后未经过任何处理的情况下添加了这个评论到页面（比如通过 `document.write`、`innerHtml`），那么恶意代码将执行。
+
+### 区别
+
+- 反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
+- DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
+
+## 如何防范
+
+1. 输入校验长度、合法性能避免一些 XSS 攻击
+2. 后端使用可靠的转义库来转译 html
+3. 纯前端渲染，明确的告诉浏览器：要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式（.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码。针对内部管理系统可以，SEO 要求高的系统不行
+4. DOM 中的内联事件监听器，慎用
+5. Vue 中慎用 v-html
+6. Js 中使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。
+7. cookie 设置成 Http-Only，这样可以防止脚本被 JS 读取
+8. 敏感操作加验证码多层验证，防止脚本冒充用户执行
+9. 合理配置CSP（内容安全策略）
\ No newline at end of file