01-浏览器安全模型

目录

• 一、浏览器架构概述
• 二、同源策略
• 三、沙箱与进程隔离
• 四、安全区域与权限模型
• 五、Cookie安全模型
• 六、HTTPS与混合内容
• 七、浏览器安全机制全景
• 八、红队视角总结

---

一、浏览器架构概述

多进程架构 (Chromium)

Browser Process (主进程)
├── GPU Process
├── Network Process
├── Storage Process
├── Renderer Process (每个标签页一个)
│   ├── JS Engine (V8)
│   ├── DOM/CSS Parser
│   ├── Event Loop
│   └── Sandbox
├── Extension Process
└── Plugin Process

安全关键：Renderer进程运行在严格的沙箱中，无法直接访问文件系统或网络。

Site Isolation (站点隔离)

https://bank.com  → Renderer Process A
https://evil.com  → Renderer Process B (不同的进程！)
https://a.bank.com → Renderer Process C (不同子域，可能同进程)

攻击者无法通过Spectre等CPU侧信道跨进程窃取数据

浏览器沙箱机制

层级	机制	说明
进程层	独立Renderer进程	每个站点独立沙箱
系统层	seccomp-bpf (Linux)	限制系统调用
系统层	Sandbox (macOS)	Seatbelt配置
系统层	Job Object (Windows)	作业对象限制
V8层	V8 Sandbox	堆隔离、Code Pointer Integrity
JS层	CSP	内容安全策略
DOM层	SOP	同源策略

二、同源策略 (SOP)

源的构成

协议 + 主机 + 端口 = 源 (Origin)

https://bank.com:443/page/login
^^^^^^   ^^^^^^^^ ^^^
协议     主机     端口(默认443)

同源判定：
https://a.bank.com ≠ https://bank.com       (子域不同)
https://bank.com:443 = https://bank.com     (默认端口相同)
https://bank.com   ≠ http://bank.com        (协议不同)

SOP到底限制什么

可以跨域	不可以跨域
加载资源 (img, script, link)	读取资源内容
提交表单 (form action)	JS读取跨域iframe的DOM
发送请求 (fetch, XHR)	读取跨域fetch/XHR的响应
导航跳转 (点击链接)	读取跨域window的属性
嵌入iframe	JS操作跨域iframe内容
WebSocket连接	(但WS不受SOP限制！)

SOP是”写松散、读严格”

攻击者可以：
  ✓ 向bank.com发送任何请求（写）
  ✓ 在evil.com嵌入bank.com的iframe
  ✓ 加载bank.com的图片、脚本、样式

攻击者不能：
  ✗ 读取bank.com的响应内容（读）
  ✗ JS访问bank.com iframe的DOM
  ✗ 通过fetch获取bank.com跨域数据

三、沙箱与进程隔离

Renderer进程的能力限制

// 浏览器渲染器（Renderer）不能：
require('fs');           // ✗ 没有Node.js模块
const net = require('net');  // ✗ 没有原生网络
exec('whoami');          // ✗ 没有shell
 
// 只有浏览器提供的受限API：
fetch();                 // ✓ 但受SOP/CORS限制
WebSocket;               // ✓ 但可被服务器拒绝
navigator.sendBeacon();  // ✓ 数据外泄通道

绕过沙箱的历史方法

1. 浏览器漏洞（如V8漏洞 → RCE）—— 最值钱的漏洞
2. 插件/扩展（Flash, Silverlight）—— 已被淘汰
3. file:// 协议 —— 本地文件可能有更宽松的权限
4. WebAssembly —— 理论上受限，但与JS共享沙箱
5. Service Worker —— 可拦截请求，但仍有SOP限制

四、安全区域与权限模型

Permissions API

// 检查权限状态
navigator.permissions.query({ name: 'geolocation' })
  .then(result => console.log(result.state));
// 'granted' | 'denied' | 'prompt'
 
// 常见权限
'geolocation'       // GPS位置
'notifications'     // 推送通知
'camera'            // 摄像头
'microphone'        // 麦克风
'midi'              // MIDI设备
'clipboard-read'    // 剪贴板读取（危险）
'clipboard-write'   // 剪贴板写入

Feature Policy / Permissions Policy

<!-- 限制iframe内的权限 -->
<iframe allow="camera 'none'; microphone 'none'; geolocation 'self'" 
        src="https://third-party.com/widget">
</iframe>
 
<!-- HTTP头方式 -->
Permissions-Policy: camera=(), microphone=(), geolocation=(self "https://trusted.com")

红队应用：如果目标网站使用了不安全的iframe allow策略，可能通过iframe内的攻击获得更多权限。

五、Cookie安全模型

Cookie的完整安全模型

Cookie属性安全层级：

第1层：HttpOnly → 防御JS读取（防XSS窃取）
第2层：Secure → 防御中间人（仅HTTPS）
第3层：SameSite → 防御CSRF跨站请求
第4层：__Host- 前缀 → 强制Path=/+Secure+无Domain（最强）
第5层：__Secure- 前缀 → 强制Secure（次强）

Cookie前缀

# __Host- 前缀（最强）
Set-Cookie: __Host-SID=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
# 要求：必须设置 Path=/, Secure, 不能设置 Domain
 
# __Secure- 前缀
Set-Cookie: __Secure-TOKEN=xyz789; Secure; HttpOnly; SameSite=Strict
# 要求：必须设置 Secure
 
# 普通Cookie
Set-Cookie: session_id=weak; HttpOnly; SameSite=Strict

跨站 vs 同站

Same-Site (同站):
  https://a.example.com 和 https://b.example.com  是同站！
  https://example.com 和 https://www.example.com   是同站！

Cross-Site (跨站):
  https://example.com 和 https://other.com         是跨站
  https://a.github.io 和 https://b.github.io       是跨站！
  (github.io 在 Public Suffix List 中，同PSL不算同站)

六、HTTPS与混合内容

混合内容（Mixed Content）

https://example.com
├── <img src="http://insecure.com/photo.jpg">    ← Passive Mixed Content
├── <script src="http://insecure.com/lib.js">     ← Active Mixed Content (BLOCKED)
└── <iframe src="http://insecure.com/frame">      ← Active Mixed Content (BLOCKED)

类型	示例	浏览器行为
Passive	img, video, audio	显示警告（部分阻止）
Active	script, iframe, link	完全阻止

HSTS (HTTP Strict Transport Security)

# 服务器响应头
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

效果：
1. 浏览器强制使用HTTPS（307内部重定向）
2. 用户无法点击"继续访问"不安全网站
3. max-age=31536000 = 1年强制HTTPS
4. includeSubDomains = 子域也强制HTTPS
5. preload = 加入浏览器预加载列表（即使首次访问也强制HTTPS）

证书透明 (Certificate Transparency)

所有公共CA签发的证书必须在CT Log中记录
攻击者无法偷偷签发某域名的证书（会被CT监控检测到）
红队视角：检查目标的CT Log可发现子域、潜在漏洞
  https://crt.sh/?q=%.target.com

七、浏览器安全机制全景

安全机制分层总结

应用层：
  CSP (Content-Security-Policy)          → 脚本/样式/资源白名单
  Permissions-Policy                     → 功能权限限制
  X-Frame-Options                        → 防Clickjacking
  X-Content-Type-Options: nosniff        → 防MIME嗅探
  Referrer-Policy                        → 控制Referer泄露

传输层：
  HTTPS + HSTS                           → 强制加密
  Certificate Transparency               → 证书透明度
  HPKP (已废弃)                          → 公钥固定

浏览器层：
  Same-Origin Policy (SOP)               → 同源隔离
  Site Isolation                         → 进程隔离
  Sandbox + seccomp                      → 系统级沙箱
  XSS Auditor (已从Chrome移除)           → 反射XSS检测

Cookie层：
  HttpOnly, Secure, SameSite             → Cookie保护
  __Host- / __Secure- 前缀               → 强化Cookie

安全机制的缺陷空间

机制	主要降级来源
CSP	'unsafe-inline', 'unsafe-eval'
SOP	CORS配置错误 (Origin: *反射)
HTTPS	混合内容警告被忽略
SameSite	SameSite=None 允许跨站
HSTS	max-age设置过短

八、红队视角总结

浏览器安全边界利用面

最安全（难攻破）：
  → V8 Sandbox (需要浏览器0day)
  → Site Isolation (需要CPU侧信道)
  → HTTPS + HSTS (需要CA劫持)

中等（配置错误）：
  → CSP (unsafe-inline/unsafe-eval)
  → CORS (反射Origin)
  → Cookie (无HttpOnly/Secure/SameSite)
  → Permissions-Policy (过度授权)

最容易（常见漏洞）：
  → XSS (HTML注入)
  → CSRF (无Token)
  → Clickjacking (无X-Frame-Options)
  → CSP未设置（默认无保护）

安全头检测命令

# 一键检测安全头配置
curl -sI https://target.com | grep -iE \
  'strict-transport|csp|frame|content-type|x-xss|referrer|permission'
 
# 关键检查项：
# Strict-Transport-Security: max-age=... → HSTS
# Content-Security-Policy: ...           → CSP
# X-Frame-Options: DENY/SAMEORIGIN       → Clickjacking防护
# X-Content-Type-Options: nosniff        → MIME嗅探防护
# Referrer-Policy: ...                   → Referer控制
# Permissions-Policy: ...                → 权限控制

---

返回 前端基础总目录