sofishaaa/cybersecurity-labs

# 网络安全实验室 — 浏览器安全 一系列包含 5 个动手实践的实验室，使用基于 Node.js/Express 构建的模拟 WebMail 应用程序来探索浏览器安全机制。 ## 架构 该项目模拟了一个多源 Web 生态系统： | 服务器 | 端口 | 角色 | |--------|------|------| | GoodHost | 3000 | 主 WebMail 应用程序 | | StaticHost (CDN) | 8001 | 静态资源 (JS, CSS, 图像) | | TrustCo (Partner) | 4000 | 支持聊天小部件 | | WeatherApp (Utility) | 8002 | 天气小部件 / 攻击者 | | Proxy | 8080 | MitM 代理 (仅限实验室 5) | ## 实验 1 — 浏览器安全基础 **概念：** 同源策略 (SOP) 和 CORS ### 任务 5 — 默认模式：CORS 错误 浏览器默认阻止跨源 fetch 请求 (同源策略)。 来自端口 4000 的 `support.js` 在没有 CORS 头部的情况下无法从端口 3000 获取数据。  ### 任务 6 — 模式1：CORS 已修复 向服务器添加 `cors()` 中间件允许跨源通信。 所有外部脚本成功加载，支持聊天功能正常运行。  ### 任务 7 — 恶意 WeatherApp (XSS) 切换到 `breach1` 模式的 WeatherApp 会执行恶意脚本，读取 `document.cookie` 和 `innerHTML` —— 演示了通过第三方脚本信任进行的 XSS 攻击。  ## 实验 2 — 内容安全策略 (CSP) **概念：** 使用 HTTP 头部限制浏览器可以加载的资源。 ### 任务 1 — 严格 CSP (`default-src 'self'`) 所有外部资源均被阻止 —— 包括来自其他源的脚本、样式和图像。 最高安全性会破坏所有第三方集成。  ### 任务 2 — 平衡的 CSP 细粒度的策略允许受信任的源 (4000, 8001)，同时阻止恶意的 WeatherApp (8002)。即使 WeatherApp 处于 `breach1` 模式，弹窗也不会触发。  ## 实验 3 — 供应链安全与 SRI **概念：** 子资源完整性 (SRI) —— 脚本的加密哈希验证。 ### 任务 1 — CDN 违规 (无 SRI) CDN 被攻陷 —— `react-mock.js` 返回恶意弹窗。 由于端口 8001 是受信任的，CSP 无法检测到这一点。弹窗被触发。  ### 任务 2 — SRI 激活 (违规被阻止) 向 script 标签添加 `integrity="sha256-..."` 会使浏览器验证文件哈希。 被篡改的脚本哈希不匹配 —— 因此被阻止。  ### 任务 3 — SRI 与版本更新 将 CDN 更新到 `v1.0.1` (一次合法更改) 会导致应用程序中断，直到 `integrity` 哈希被更新。SRI 强制实行严格的版本管理。  ## 实验 4 — 会话管理与 Cookie 安全 **概念：** Cookie 安全标志及其对会话 token 保护的影响。 ### 任务 1 — 朴素 Cookie 在未设置任何标志的情况下设置的 Cookie。`document.cookie` 会向 JavaScript 暴露会话 token。  ### 任务 2 — 隐秘的 Cookie 窃取 处于 `breach2` 模式的 WeatherApp 通过 `fetch()` 静默窃取 Cookie。 被盗的 `SessionID` 会出现在攻击者的服务器终端中 —— 没有可见的弹窗警告。  ### 任务 3 — HttpOnly 标志 `HttpOnly` 将 Cookie 对 `document.cookie` 隐藏。JavaScript 返回空字符串。 攻击者的 `fetch()` 发送的内容毫无用处 —— 窃取被阻止。  ### 任务 4 — 路径限制 Cookie 作用域限定为 `Path=/api`。仅发送到 `/api/*` 路由，而不是根路径。 在 `/api/emails` 上存在 Cookie：  在 `/` 上不存在 Cookie：  ## 实验 5 — 网络安全与 MitM 攻击 **概念：** `Secure` 标志以及针对网络层拦截的防护。 ### 任务 1 — MitM 代理拦截 HttpOnly Cookie 代理服务器位于浏览器和应用程序之间。即使设置了 `HttpOnly`， 代理也会读取原始的 HTTP 头部并以明文形式记录会话 token。  ### 任务 2 — Secure 标志 向 Cookie 添加 `Secure` 会指示浏览器仅通过 HTTPS 发送它。 在普通的 HTTP 下 (通过代理)，浏览器会保留不发送该 Cookie。 注意：Chrome 对 localhost 有例外处理，但 `Set-Cookie` 头部确认该标志已设置。  ## Cookie 安全总结 | 实验 | 模式 | 标志 | 攻击结果 | |-----|------|-------|---------------| | 实验 4 任务 1 | `task1-naive` | 无 | Cookie 通过 JS 被盗 | | 实验 4 任务 2 | `task1-naive` | 无 | Cookie 被静默窃取 | | 实验 4 任务 3 | `task3-httponly` | `HttpOnly` | JS 窃取被阻止 | | 实验 4 任务 4 | `task4-path` | `HttpOnly; Path=/api` | 作用域受限 | | 实验 5 任务 1 | `task5-httponly` | `HttpOnly` | MitM 依然有效 | | 实验 5 任务 2 | `task5-secure` | `HttpOnly; Secure` | MitM 被阻止 | ## 如何运行 ``` # 在每个 server 文件夹中安装 dependencies cd labN/goodhost && npm install cd labN/statichost && npm install cd labN/trustco && npm install cd labN/weatherapp && npm install # 启动 servers（4个终端） node server.js # goodhost (port 3000) node server.js # statichost (port 8001) node server.js # trustco (port 4000) node server.js --mode breach1 # weatherapp (port 8002) # 仅限 Lab 5 — proxy cd lab5/proxy && npm install node server.js --mode breach # proxy (port 8080) ```

标签：CISA项目, Cookie Flags, Cookie安全, CORS, CSP, Express, GNU通用公共许可证, HttpOnly, HTTP安全头, MitM, MITM代理, Node.js, Secure, SOP, SRI, Syscall, Web安全, Web开发, XSS, 中间人攻击, 内容安全策略, 前端安全, 同源策略, 多模态安全, 子资源完整性, 安全实验, 安全标准, 安全测试, 安全防护, 安全靶场, 攻击性安全, 数据可视化, 漏洞修复, 漏洞情报, 网络安全, 网络安全培训, 蓝队分析, 规则仓库, 跨域资源共享, 跨站脚本攻击, 隐私保护