Web View

_book/Chapter3/3-1.md

@@ -0,0 +1,36 @@
+### SameSite 防御 CSRF 的原理
+
+**1. `SameSite=Strict`**
+
+这是最严格的模式。它规定：**只有当请求是同站发出的，浏览器才会发送 Cookie**
+
+- **同站请求**：比如你在 `bank.com` 内部点击一个链接，请求 `bank.com/profile`，浏览器会发送 Cookie
+- **跨站请求**：当你在 `evil.com` 上，通过任何方式（表单提交、`<img>` 标签、`<a>` 链接）向 `bank.com` 发起请求时，浏览器**都不会**发送 Cookie
+
+**防御效果**：`Strict` 模式可以完全防御 CSRF 攻击，因为恶意请求无法携带会话 Cookie
+
+**缺点**：过于严格，可能会影响用户体验。例如，如果你从其他网站（如社交媒体或搜索引擎）点击一个链接跳转到 `bank.com`，因为这是跨站导航，`Strict` 模式下的 Cookie 也不会被发送，你可能需要重新登录
+
+**2. `SameSite=Lax`**
+
+这是折中且更常用的模式。它在 `Strict` 的基础上做了一些放宽：
+
+- **同站请求**：会发送 Cookie
+- **跨站导航**：当通过 `<a href="..."` 链接进行 GET 请求导航时，会发送 Cookie
+- **其他跨站请求**：通过 `POST` 表单、`<img>` 标签、`<iframe>`、AJAX 等方式发起的请求，**不会**发送 Cookie
+
+**防御效果**：`Lax` 模式可以防御大部分 CSRF 攻击，特别是那些利用 POST 表单进行的攻击。同时，它允许用户从外部网站通过链接跳转到你的网站，而不会强制重新登录，改善了用户体验
+
+**现代浏览器默认行为**：目前，大多数现代浏览器（如 Chrome）已经将 `SameSite` 的默认值设置为 `Lax`，即使你在服务器端没有明确设置
+
+**3. `SameSite=None`**
+
+这是最宽松的模式。它规定：**在任何情况下都发送 Cookie，包括跨站请求**
+
+**防御效果**：不提供任何 CSRF 防御
+
+**使用场景**：通常用于需要跨站发送 Cookie 的场景，例如：
+
+- OAuth 认证（需要从第三方登录页面返回你的网站并携带 Cookie）
+- 第三方嵌入服务，如嵌入式评论或广告
+- 在这种模式下，为了安全，必须同时设置 `Secure` 属性，即 `SameSite=None; Secure`，要求 Cookie 只能通过 HTTPS 发送

_book/Chapter3/3-2.md

@@ -0,0 +1,53 @@
+### JSON 格式的 CSRF 如何防御
+
+**1. 使用 CSRF Token**
+
+这是最常见和最可靠的防御方法
+
+- **工作原理**：
+
+  1. 服务器在用户登录后，生成一个随机、唯一的 CSRF Token，并将其存储在**会话中**或**某个安全的地方**（如 `sessionStorage`）
+  2. 服务器将 Token 发送给客户端
+  3. 客户端在发起任何敏感操作的请求时，都必须将这个 Token 放在**HTTP 请求头**或 **POST 请求体**中
+  4. 服务器接收到请求后，会验证请求中的 Token 是否与服务器上存储的 Token 相匹配。如果不匹配，则拒绝请求
+
+- **在 JSON 请求中的实践**： 客户端的 JavaScript 代码在发起 POST 请求时，将 Token 放在一个自定义的 HTTP 头中，例如 `X-CSRF-TOKEN`
+
+  ```js
+  fetch('https://your-api.com/transfer', {
+    method: 'POST',
+    body: JSON.stringify({ to: 'attacker', amount: 1000 }),
+    headers: {
+      'Content-Type': 'application/json',
+      'X-CSRF-TOKEN': 'your-generated-token'
+    }
+  });
+  ```
+
+  **防御原理**：攻击者无法从 `your-api.com` 域获取有效的 CSRF Token。由于同源策略的限制，恶意网站的 JavaScript 无法读取你的 API 返回的 HTML 或 JSON 数据，因此无法获取 CSRF Token。此外，即使是简单请求，自定义的 HTTP 头也会触发预检请求，同样会被 CORS 机制拦截
+
+**2. 使用 SameSite Cookie**
+
+前面我们讨论过 `SameSite` 属性。在 JSON API 的场景中，`SameSite=Lax` 同样是有效的防御
+
+- **工作原理**： 将你的会话 Cookie 的 `SameSite` 属性设置为 `Lax` 或 `Strict`。当攻击者从恶意网站发起 POST 请求时，浏览器不会携带这个会话 Cookie。服务器在验证请求时，因为没有会话信息，会直接拒绝请求
+
+  ```
+  Set-Cookie: sessionid=xxxx; SameSite=Lax; Secure; HttpOnly
+  ```
+
+- **最佳实践**：
+
+  - `SameSite=Strict`：提供了最强的防御，但可能影响用户体验
+  - `SameSite=Lax`：在大多数情况下提供了足够的保护，同时不影响用户从其他网站通过 GET 链接跳转到你的网站
+
+**3. 验证 Referer 或 Origin 头**
+
+这种方法是辅助性的，但可以提供额外的安全层
+
+- **工作原理**： 服务器检查请求头中的 `Referer` 或 `Origin` 字段，验证请求的来源是否为你的合法域名
+  - `Referer`：表示发起请求的 URL
+  - `Origin`：表示请求的来源域，通常用于 CORS 预检请求中
+- **局限性**：
+  - `Referer` 字段可以被一些浏览器或代理软件修改或删除
+  - 这不是一个完全可靠的防御方法，应作为辅助手段而非主要策略

_book/Chapter3/3-3.md

@@ -0,0 +1,17 @@
+### Ajax 发送 POST 请求会发几个数据包
+
+AJAX 发送一个 POST 请求，通常会发送**一个**数据包
+
+这个数据包里包含了所有 POST 请求所需的信息，比如请求头（Headers）、请求体（Body）等。请求头里会指定 Content-Type 为 `application/x-www-form-urlencoded` 或 `application/json` 等，告诉服务器数据格式。请求体里则携带了实际要发送的数据。
+
+**特殊情况：OPTIONS 预检请求**
+
+不过，在某些跨域（CORS）场景下，浏览器在正式发送 POST 请求之前，会先发送一个 **OPTIONS** 请求，这个 OPTIONS 请求被称为“**预检请求**”（Preflight Request）
+
+所以，如果满足以下任一条件，浏览器就会先发一个 OPTIONS 预检请求，然后再发 POST 请求：
+
+- 使用了自定义请求头（如 `X-Requested-With`）
+- Content-Type 不属于 `application/x-www-form-urlencoded`、`multipart/form-data` 或 `text/plain`。比如，使用了 `application/json`
+- 请求方法为 PUT、DELETE 等，或 POST 请求与服务器的 API 路径不同
+
+这个 OPTIONS 请求的目的是询问服务器是否允许当前域名、请求方法、自定义请求头等进行跨域操作。如果服务器返回的响应头里包含了允许的信息（如 `Access-Control-Allow-Origin`），浏览器才会继续发送实际的 POST 请求

_book/Chapter3/README.md

@@ -0,0 +1,20 @@
+# 网安面试题（涵盖护网、红队、逆向、二进制）
+
+上万道安全面试题已经全部为您划分好，适用于网络安全所有岗位！！！
+
+HR：请问…………
+
+我：叽里咕噜说啥呢，看看八股文上写了没
+
+（Summary.md 是目录噢！！）
+
+**🙏 特别感谢名单**
+
+在整理和完善本项目的过程中，以下朋友给予了宝贵的帮助与支持，在此表示诚挚的感谢！（排名不分先后）
+
+- **@用户名1** —— 提供了大量安全面试题方向的补充  
+- **@用户名2** —— 纠正了多个问题的答案与表述  
+- **@用户名3** —— 贡献了真实面试题经验分享  
+- **@用户名4** —— 对内容结构与目录提出改进建议  
+
+如果您也愿意参与本项目，欢迎通过 **微信: XR3327026244** 投稿面试题或反馈问题，我们会在后续版本中加入您的名字