docs: update (#9)

* update

* update

* update

packages/interview/docs/.vitepress/config.ts

@@ -209,6 +209,18 @@ export default defineConfig({
           }
         ]
       },
+      {
+        text:'安全',
+        collapsed: true,
+        items: [
+          { text: '介绍', link: '/security/' },
+          { text: 'XSS', link: '/security/xss.md' },
+          { text: 'CSRF', link: '/security/csrf.md' },
+          { text: 'CORS', link: '/security/cors.md' },
+          { text: 'JWT', link: '/security/jwt.md' },
+          { text: '中间人攻击' , link: '/security/mitm.md'},
+        ]
+      },
       {
         text: '手写代码',
         collapsed: true,

packages/interview/docs/database/index.md

@@ -0,0 +1 @@
+# 数据库

packages/interview/docs/network/url.md

@@ -199,4 +199,4 @@ TCP（Transmission Control Protocol，传输控制协议）连接的关闭是一
 
 4. **第四次挥手**：主机A收到主机B的FIN标记后，它需要确认是否已经收到了这个通知。主机A将发送一个ACK标记给主机B，确认已经收到了FIN标记。此时，主机B到主机A的连接就被关闭了，也就是说主机B不能再发送数据给主机A了。至此，TCP连接的关闭过程完成，主机A和主机B的连接被彻底关闭。
 
-以上是TCP连接关闭过程的基本流程。在实际的网络通信中，由于网络的不稳定性，可能会有数据包丢失、重复等问题，TCP协议需要处理这些问题以确保数据的可靠传输。
+以上是TCP连接关闭过程的基本流程。在实际的网络通信中，由于网络的不稳定性，可能会有数据包丢失、重复等问题，TCP协议需要处理这些问题以确保数据的可靠传输。

packages/interview/docs/security/cors.md

@@ -0,0 +1,8 @@
+# CORS
+
+## CORS 是什么
+
+CORS 是一个 W3C 标准，全称是"跨域资源共享"（Cross-origin resource sharing）。
+
+它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了 AJAX 只能同源使用的限制。
+

packages/interview/docs/security/csrf.md

@@ -0,0 +1,26 @@
+# CSRF
+
+### CSRF（跨站请求伪造）是什么
+CSRF（Cross-Site Request Forgery）是一种网络攻击，其中攻击者诱使已经认证的用户在不知情的情况下发送请求到一个他们已经认证过的应用程序。这种攻击利用了网站对用户浏览器的信任，从而执行非预期的操作。
+
+### CSRF 攻击的具体例子
+假设 Alice 登录了她的银行账户，并且银行网站在她的浏览器中设置了一个会话 Cookie。在不登出银行网站的情况下，她访问了另一个网站，该网站包含了以下恶意 HTML 图片元素：
+
+```html
+<img src="http://bank.com/transfer?amount=1000&to=attacker" style="display:none;">
+```
+
+这个图片请求实际上是一个向银行发起的转账请求。因为 Alice 的浏览器仍然持有她的银行会话，所以银行网站可能会认为这是一个有效的请求，并执行转账操作。
+
+### CSRF 防御措施
+1. **使用 CSRF 令牌**: 最常见的防御方式是在表单中使用一个随机生成的 CSRF 令牌，这个令牌对每个用户会话是唯一的。服务器在处理请求时验证令牌的有效性。
+
+2. **检查 Referer 和 Origin 头部**: 通过验证 HTTP 请求的 `Referer` 或 `Origin` 头部，确保请求是从可信的源发起的。
+
+3. **使用 SameSite Cookie 属性**: 设置 Cookie 的 `SameSite` 属性可以限制 Cookie 在跨站请求中的发送。例如，将 `SameSite` 设置为 `Lax` 或 `Strict` 可以预防 CSRF。
+
+4. **双重提交 Cookie**: 另一种方法是将 CSRF 令牌嵌入到用户的 Cookie 中，并且在表单提交时，将此令牌作为请求的一部分发送，服务器会验证 Cookie 和请求中的令牌是否匹配。
+
+5. **要求自定义请求头**: 自定义请求头（如 `X-Requested-With`）不会在普通的网页请求中自动包含，因此可以用来区分正常请求和由第三方网站发起的请求。
+
+6. **确保 GET 请求不会改变服务器状态**: 遵循 HTTP 方法的语义，确保 GET 请求不会执行任何数据的改变操作，可以防止一些简单的 CSRF 攻击。

packages/interview/docs/security/index.md

@@ -0,0 +1 @@
+# 前端安全

packages/interview/docs/security/jwt.md

@@ -0,0 +1,39 @@
+# JWT
+
+## JWT（JSON Web Tokens）是什么
+JWT（JSON Web Tokens）是一个开放标准（RFC 7519），用于在网络应用环境之间安全地传递声明。JWT 是一个紧凑且自包含的方式，用于作为 JSON 对象传输信息，该信息可以验证和信任，因为它是数字签名的。
+
+## 为什么要使用 JWT
+
+1. **无状态认证**：JWT 适用于单页面应用（SPA），可用于跟踪用户的状态。
+2. **跨域认证**：在多个域中实现用户身份验证（如单点登录系统）。
+3. **在微服务架构中进行认证**：适用于微服务架构，因为它可以在不同服务之间轻松传递用户上下文。
+
+### 优缺点
+#### 优点
+1. **无状态和可扩展性**：JWT 不需要在服务器上存储会话信息，因此适用于分布式系统。
+2. **自包含**：JWT 包含所有用户验证所需信息，减少了数据库查询次数。
+3. **跨平台**：可以在不同的编程环境中使用。
+
+#### 缺点
+1. **Token 失效问题**：一旦 JWT 被颁发，在过期之前都是有效的，这可能导致安全问题。
+2. **性能问题**：JWT 可能比传统的会话 cookie 大，增加了数据传输量。
+3. **存储安全性**：在客户端存储 JWT 可能导致 XSS 攻击。
+
+### 安全问题
+1. **容易泄露**：JWT 如果通过不安全的通道传输，容易被拦截。
+2. **XSS 攻击**：如果 JWT 存储在本地存储中，可能会被 XSS 攻击利用。
+3. **CSRF 攻击**：如果 JWT 存储在 Cookie 中，可能会被 CSRF 攻击利用。
+
+### 解决方案
+1. **使用 HTTPS**：始终通过安全的通道传输 JWT。
+2. **短期有效性**：为 JWT 设置较短的过期时间，以减少风险。
+3. **使用 HttpOnly Cookie**：存储 JWT，避免 JavaScript 直接访问。
+4. **CSRF 保护**：如果使用 Cookie，应实施 CSRF 保护措施。
+5. **密钥管理**：保证签名密钥的安全性。
+
+### 总结
+JWT 提供了一种高效、可扩展的认证和授权机制，特别适用于无状态的应用场景和跨域认证。然而，它们也带来了一些安全挑战，特别是在存储和管理方面。因此，使用 JWT 时需要权衡其优势和潜在的安全风险，并采取适当的安全措施来缓解这些风险。
+
+## 参考
+[https://jwt.io/introduction](https://jwt.io/introduction)

packages/interview/docs/security/mitm.md

@@ -0,0 +1,5 @@
+# 中间人攻击
+
+
+## 参考
+[维基百科-中间人攻击](https://zh.wikipedia.org/wiki/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB)

packages/interview/docs/security/xss.md

@@ -0,0 +1,92 @@
+# XSS
+
+## 什么是 XSS 攻击？
+
+XSS（Cross Site Scripting）跨站脚本攻击，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行，从而获取用户的敏感信息。
+
+## XSS 攻击的分类
+
+XSS（跨站脚本攻击）主要分为三种类型：反射型、存储型和 DOM 型。这三种类型的攻击各有其特点和执行方式：
+
+### 反射型 XSS（Reflected XSS）
+- **工作原理**: 反射型 XSS 攻击是通过诱使用户点击一个恶意链接来实现的。这个链接包含攻击脚本，并且当用户点击该链接时，攻击脚本被发送到服务器，然后服务器将脚本“反射”回浏览器，最终在用户的浏览器上执行。
+- **特点**: 这种攻击通常是一次性的，并且需要诱骗用户点击链接。攻击脚本不会存储在服务器上。
+
+### 存储型 XSS（Stored XSS）
+- **工作原理**: 存储型 XSS 攻击发生在恶意脚本被永久地存储在目标服务器上（例如在数据库、消息论坛、评论区等）。当用户访问含有恶意脚本的页面时，脚本会被执行。
+- **特点**: 这种攻击的影响更为严重，因为它不需要特定的用户交互，任何访问了含有恶意脚本页面的用户都可能受到攻击。
+
+### DOM 型 XSS（DOM-based XSS）
+- **工作原理**: DOM 型 XSS 攻击是通过操纵页面的 DOM（文档对象模型）来实现的，而不是通过服务器的响应。攻击者在 URL 中嵌入恶意脚本，当页面脚本读取该 URL 并处理这些数据时，恶意脚本就会被执行。
+- **特点**: 这种攻击完全在客户端进行，不涉及到服务器端的处理。攻击者利用存在安全漏洞的 JavaScript 代码来实施攻击。
+
+## 具体案例
+
+### 反射型 XSS 攻击的例子
+假设有一个搜索框，用户输入的搜索词会被直接显示在搜索结果页面上。攻击者可以构造一个包含恶意脚本的搜索词链接，比如：
+
+```
+http://example.com/search?query=<script>alert('XSS')</script>
+```
+
+如果网站没有正确处理用户输入，当其他用户点击这个链接时，他们的浏览器会执行 `<script>alert('XSS')</script>`，导致一个弹窗显示“XSS”。
+
+### 存储型 XSS 攻击的例子
+考虑一个论坛帖子或评论系统，用户可以提交自己的评论。攻击者在评论中插入一个恶意脚本：
+
+```
+<script>alert('XSS');</script>
+```
+
+如果这个脚本被存储在服务器上，并且在其他用户浏览帖子时原样显示，那么每个访问该帖子的用户都会看到一个弹窗显示“XSS”。
+
+### DOM 型 XSS 攻击的例子
+假设一个网页上的 JavaScript 代码会根据 URL 的参数动态更改页面内容，例如：
+
+```javascript
+document.getElementById('someElement').innerHTML = location.hash;
+```
+
+攻击者可以构造一个带有恶意脚本的 URL，比如：
+
+```
+http://example.com/#<script>alert('XSS');</script>
+```
+
+当用户访问这个链接时，页面上的 JavaScript 会将 URL 中的 hash 部分（`<script>alert('XSS');</script>`）插入到页面中，导致脚本执行。
+
+
+## XSS 攻击的危害
+
+XSS 攻击可以对网站造成以下危害：
+
+- 盗取用户的身份信息，冒充用户发起恶意请求。
+
+- 盗取用户的敏感信息，如网银账号等。
+
+- 在页面中生成浮窗广告，影响用户体验。
+
+- 注入恶意代码，攻击网站的其他漏洞。
+
+## XSS 攻击的防御
+
+防御 XSS（跨站脚本攻击）的关键是采取多层防御策略，确保即使一个措施失败，其他措施仍然能够提供保护。以下是一些有效的防御 XSS 攻击的方法：
+
+1. **内容安全策略（CSP）**: 通过设置 HTTP 响应头中的 `Content-Security-Policy`，你可以控制浏览器加载和执行的资源。例如，你可以限制只能从可信域名加载脚本，阻止内联脚本的执行，以及禁用 `eval()` 等不安全的 JavaScript 功能。
+
+2. **转义用户输入**: 在将用户提供的数据插入 HTML、JavaScript、CSS 或其他上下文中时，应该对数据进行适当的转义。例如，对于插入 HTML 的数据，应该转义 `<`, `>`, `&`, `"`, `'` 等字符。
+
+3. **验证和清理用户输入**: 使用库如 OWASP Java HTML Sanitizer、Google Caja 等来清理和验证用户输入，确保移除或转义潜在的恶意内容。
+
+4. **使用安全的框架**: 许多现代的前端框架（如 React、Angular、Vue.js）自带防御 XSS 的机制，比如自动转义绑定到视图的数据。确保充分利用这些框架提供的安全特性。
+
+5. **避免使用 `innerHTML`**: 使用 `innerHTML` 属性插入用户提供的内容时特别危险，因为它可以执行 HTML 中的脚本。改用 `textContent` 或框架提供的安全替代方法。
+
+6. **Cookie 的 `HttpOnly` 标志**: 将 `HttpOnly` 标志添加到 Cookie 上，可以防止 JavaScript 通过 XSS 访问 Cookie。这有助于减少某些类型的 XSS 攻击所能造成的影响。
+
+7. **验证和过滤 URL**: 对于从用户输入或其他不可信源获取的 URL，应进行严格的验证和过滤，确保它们不包含 JavaScript: 等不安全的协议。
+
+8. **安全的文件上传处理**: 如果允许用户上传文件，确保对上传的文件进行严格的验证，防止上传恶意脚本文件。
+
+
+