Chapter 01

Web 安全基础

从 CIA 三要素到同源策略——建立正确的安全思维框架，理解 Web 安全的底层原则

安全三要素 CIA

信息安全的核心框架

CIA 三要素（CIA Triad）是信息安全领域最基础的概念框架，所有安全控制措施的目标都可以归结为保护这三个属性中的一个或多个。

C — Confidentiality
保密性
确保信息只被授权的人访问，未授权者无法读取。数据加密（TLS 传输加密、AES 存储加密）、访问控制（身份认证+授权）都是保护保密性的手段。典型威胁：数据泄露、中间人攻击（MITM）、账号盗取。
I — Integrity
完整性
确保信息在存储和传输过程中未被未授权修改。数字签名（JWT 签名、代码签名）、消息认证码（HMAC）、哈希校验（SHA-256 文件校验）都是完整性保护手段。典型威胁：中间人篡改、SQL 注入修改数据、供应链投毒。
A — Availability
可用性
确保系统和服务在需要时可以正常访问。冗余部署、限速（Rate Limiting）、CDN 防护、WAF（Web 应用防火墙）都是可用性保护手段。典型威胁：DDoS 攻击（分布式拒绝服务）、勒索软件、资源耗尽型漏洞。
CIA 在 Web 开发中的实际意义

当你看到一个安全漏洞报告时，思考它破坏了哪个 CIA 属性：SQL 注入可以泄露数据（破坏保密性）、修改数据（破坏完整性）；DDoS 破坏可用性；XSS 劫持用户 Session（破坏保密性）。用 CIA 框架分析，有助于快速评估漏洞的业务影响。

Web 安全威胁全景

三大标准体系：OWASP / CVE / CWE

OWASP
Open Web Application Security Project，开放式 Web 应用安全项目。非营利组织，发布 Web 应用安全领域最权威的研究成果，最著名的是每4年更新一次的 OWASP Top 10——Web 应用最常见的 10 大安全风险排行榜，已成为行业标准参考文档。
CVE
Common Vulnerabilities and Exposures，通用漏洞披露。由 MITRE 公司维护的漏洞数据库，每个漏洞分配唯一的 CVE 编号（如 CVE-2021-44228 即 Log4Shell）。全球安全团队、厂商和用户通过 CVE 编号统一引用和跟踪特定漏洞。
CWE
Common Weakness Enumeration，通用缺陷枚举。描述软件和硬件设计缺陷的分类体系（如 CWE-89 = SQL 注入，CWE-79 = XSS）。CVE 描述"具体的漏洞实例"，CWE 描述"缺陷类型"，两者是实例与分类的关系。
NVD
National Vulnerability Database，美国国家漏洞数据库，基于 CVE 数据并增加了 CVSS 评分、受影响产品列表（CPE）等信息。是查询漏洞严重程度和影响范围的权威来源（nvd.nist.gov）。

HTTP 协议安全要素

HTTPS 与 TLS：加密传输的基石

HTTP 是明文协议——所有数据（包括密码、Cookie、个人信息）都以明文在网络上传输，任何网络中间节点（路由器、ISP、公共 WiFi 热点）都可以读取甚至篡改流量。HTTPS = HTTP + TLS，提供了传输加密、身份认证（服务器证书）、数据完整性三重保护。

TLS 握手过程（TLS 1.3 简化版） 客户端 服务器 │─── ClientHello（支持的加密套件列表）──────────→│ │←── ServerHello（选定套件）+ 证书 + Finished ───│ │─── Finished（完成握手，开始加密通信）──────────→│ │═══════════════ 加密的 HTTP 数据 ══════════════│ TLS 1.3 相比 TLS 1.2 的改进： - 握手减少到 1-RTT（TLS 1.2 需要 2-RTT） - 支持 0-RTT 会话恢复（需谨慎：有重放攻击风险） - 移除了所有不安全算法（RC4、MD5、SHA-1、DH<2048bit） - 所有握手消息在第一次 ServerHello 后即加密

HSTS：强制 HTTPS 的最后防线

即使服务器支持 HTTPS，用户第一次访问 http://example.com 时，仍有被降级攻击（SSL Stripping）的风险。HSTS（HTTP Strict Transport Security）通过 HTTP 响应头告诉浏览器：该域名在指定时间内只允许 HTTPS 访问，浏览器将拦截所有 HTTP 请求并自动升级为 HTTPS。

# HSTS 响应头示例
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# max-age=31536000 表示 365 天内强制 HTTPS
# includeSubDomains 对所有子域名生效（谨慎：影响所有子域）
# preload 表示申请加入浏览器内置 HSTS 预加载列表
# 预加载列表：https://hstspreload.org/
# 加入预加载列表后，即使第一次访问也会直接使用 HTTPS

TLS 证书校验与常见错误

证书链验证
浏览器不直接信任所有证书，而是验证证书链：服务器证书 → 中间 CA 证书 → 根 CA 证书。根 CA 证书内置在操作系统/浏览器中（受信任锚点）。如果任一环节签名无效或证书已过期，浏览器会显示警告。
证书透明度（CT）
Certificate Transparency，要求所有公开信任的证书必须被记录到公开的 CT 日志服务器（如 Google 的 Argon 日志）。这使任何人都可以监控是否有 CA 为某域名颁发了未授权证书（防止 CA 被黑或被迫签发假证书）。
证书固定（Pinning）
客户端预置服务器证书/公钥的指纹，只信任特定证书而非整个 CA 系统。常用于高安全要求的移动 App（如银行 App）。已从 Chrome 中移除 HTTP Public Key Pinning（HPKP）标准，但应用层固定仍在使用。

同源策略 SOP 与 CORS

同源策略（Same-Origin Policy）

同源策略是浏览器最核心的安全机制之一。同源的定义是：协议（scheme）+ 域名（host）+ 端口（port）三者完全相同。不同源的页面之间，JavaScript 默认不能读取对方的 DOM、Cookie、LocalStorage，也不能读取 XHR/Fetch 响应内容。

同源判断示例（以 https://example.com:443 为基准） https://example.com/page ✅ 同源（路径不同，但协议/域/端口相同） https://example.com:8080/ ❌ 跨源（端口不同：443 vs 8080） http://example.com/ ❌ 跨源（协议不同：https vs http） https://api.example.com/ ❌ 跨源（子域名不同） https://evil.com/ ❌ 跨源（域名不同）

CORS：跨域资源共享

CORS（Cross-Origin Resource Sharing）是一种允许服务器声明哪些跨源请求被允许的机制。它通过 HTTP 响应头实现，完全由服务器控制——浏览器发送跨域请求时，检查服务器响应中的 CORS 头，决定是否允许 JavaScript 读取响应。

# 宽松配置（危险！允许任意来源）
Access-Control-Allow-Origin: *

# 正确配置（只允许指定来源）
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
# 注意：Access-Control-Allow-Credentials: true 时
# Access-Control-Allow-Origin 不能为 *，必须指定具体来源
CORS 常见配置错误

动态反射来源是最危险的错误：服务器读取请求的 Origin 头，直接原样返回 Access-Control-Allow-Origin: <任意Origin>，加上 Allow-Credentials: true，等同于任何网站都可以携带用户 Cookie 读取 API 响应——这是严重的安全漏洞。正确做法：维护一个允许来源的白名单，严格校验后再返回。

安全开发生命周期 SDLC

安全开发生命周期（Security Development Lifecycle，SDL 或 Secure SDLC）是将安全活动融入软件开发各个阶段的实践框架，而不是在开发完成后才"打补丁"。

开发阶段安全活动工具示例
需求阶段 定义安全需求、隐私需求；识别合规要求（GDPR/PCI-DSS） 威胁模型文档、STRIDE
设计阶段 威胁建模、安全架构审查、最小权限设计 OWASP Threat Dragon、draw.io
编码阶段 安全编码规范、IDE 安全插件、代码审查 SonarQube、Semgrep、ESLint security
测试阶段 SAST 静态分析、DAST 动态测试、渗透测试 OWASP ZAP、Burp Suite、CodeQL
部署阶段 依赖扫描、容器镜像扫描、配置审计 trivy、Snyk、checkov
运营阶段 日志监控、告警、漏洞响应、Bug Bounty SIEM、Datadog Security、HackerOne

核心名词解释

CVE 编号
Common Vulnerabilities and Exposures，格式为 CVE-年份-序号。例如 CVE-2021-44228（Log4Shell）、CVE-2014-0160（Heartbleed）。通过 CVE 编号可在 NVD 数据库查询详细信息和补丁。
CVSS 评分
Common Vulnerability Scoring System，通用漏洞评分系统。0.0-10.0 分制：0.0 = 无风险，7.0-8.9 = High（高危），9.0-10.0 = Critical（严重）。评分考虑攻击向量、复杂度、所需权限、用户交互、影响范围（机密性/完整性/可用性）等维度。
渗透测试
Penetration Testing（Pentest），授权的模拟攻击行为。测试人员像真实攻击者一样尝试攻破系统，目的是在恶意攻击者之前发现漏洞。分为黑盒（不提供任何信息）、白盒（提供源码等完整信息）、灰盒（提供部分信息）三种模式。
Bug Bounty
漏洞赏金计划，企业公开邀请安全研究人员挖掘并负责任地报告漏洞，给予金钱奖励。主要平台：HackerOne、Bugcrowd、Intigriti。谷歌、微软、苹果、Facebook 等都有数百万美元级别的赏金计划。
零日漏洞（0-day）
供应商尚未得知、因此没有补丁的漏洞。"零日"指供应商有"零天"时间来修复。0-day 漏洞在地下市场极为昂贵（可高达数百万美元），通常被 APT（高级持续性威胁）组织掌握。
WAF
Web Application Firewall，Web 应用防火墙。工作在 HTTP 层，检测并过滤恶意请求（SQL 注入特征、XSS 载荷等）。常见产品：Cloudflare WAF、AWS WAF、ModSecurity（开源）。注意：WAF 是防御层之一，不能替代安全编码。

安全工具入门

Burp Suite

Burp Suite 是 Web 安全测试最广泛使用的工具，由 PortSwigger 开发。核心功能是 HTTP/HTTPS 代理——拦截浏览器与服务器之间的所有流量，让测试人员可以查看、修改、重放任意请求。免费社区版功能已相当强大，专业版（约 $450/年）增加了主动扫描器和更多高级功能。

Burp Suite 核心模块速览

OWASP ZAP

OWASP Zed Attack Proxy（ZAP）是完全开源免费的 Web 安全扫描器。功能与 Burp Suite 社区版类似，但额外提供了自动扫描器，特别适合集成到 CI/CD 流水线中进行自动化安全测试。ZAP 提供 Docker 镜像，可以一行命令扫描 Web 应用。

# OWASP ZAP Docker 快速扫描（基线扫描，用于 CI/CD）
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://your-app.example.com \
  -r zap-report.html

# 完整 AJAX 爬虫扫描（更彻底，用于定期安全评估）
docker run -t owasp/zap2docker-stable zap-full-scan.py \
  -t https://your-app.example.com \
  -r zap-full-report.html
本章小结

Web 安全的基础是三个核心概念：① CIA 三要素——保密性、完整性、可用性，是所有安全控制的目标；② HTTP 安全层——HTTPS/TLS 保护传输，HSTS 防止降级攻击，证书体系提供身份认证；③ 同源策略是浏览器安全的核心边界，CORS 是服务器明确放宽该限制的机制，必须谨慎配置。建立这些基础概念后，才能真正理解各类 Web 漏洞的根本原因。