企业官网建设流程全解析

前言

1. 业务流程中的安全管控

毫无疑问，你访问的大多数WebApp、移动App，都需要你注册登录才能使用，这里面有着商业、风控、合规等原因，也有业务本身就需要的原因。就像你去银行取钱，银行得先确认你是谁，然后基于“你是谁”，再判断你能不能进行取钱这个操作。总结一下这个过程：

1. 身份认证（看你的身份证）
2. 会话管理（持续面对面，标识你已经认证过了，为你办理业务）
3. 访问控制（你存钱的金额=取钱最大金额）

当我们将这些由人操作的业务流程实现为一个计算机信息系统/网络应用时，也必须提供相应的机制

1. 身份认证（账号+口令）
2. 会话管理（客户端会话ID（唯一标识）+服务端会话数据结构）
3. 访问控制（权限ACL）

2. WebApp中安全机制的实现

传统的鉴权机制的实现：

整个机制没有问题，只有拥有账号密码的实体才能通过认证，只有认证过后才拥有一个唯一的身份凭据session id（session ID 存储在Cookies中）。

问题在于，浏览器对同一站点的cookie是自动携带的，不管请求来源是哪里。

3. CSRF的形成

3.1 成因

CSRF漏洞形成因素概括为3个层次：
第一层：浏览器的 Cookie 机制

Cookie 的设计初衷：让无状态的 HTTP 协议维持状态 Cookie 的携带规则：只要请求的目标域名匹配，就自动携带 不管这个请求是谁触发的

这意味着：用户访问evil.com，页面里如果有一个指向bank.com的请求，浏览器会自动把bank.com的 Cookie 带上去。这不是浏览器的 bug，而是设计如此。

第二层：服务端的信任边界模糊

服务端收到一个请求 → 看到 Cookie 有效 → 认为是用户本人操作 → 执行 问题：服务端缺少一个关键判断—— "这个请求真的是用户在我们的页面上主动发起的吗？"（有可能是跨站发起的请求，因为Cookie是自动携带的）

服务端只做了身份认证（Authentication），没有做请求来源验证（Origin Validation）

第三层：请求的"可预测性"

攻击者必须能构造出目标站能理解和执行的请求： - 知道 URL（如 /transfer） - 知道参数名（如 to, amount） - 知道请求方法（GET / POST） 如果这些信息都可预测/可获取 → 攻击成立

三个层次合在一起：

自动携带凭证（浏览器机制） × 服务端不验证来源（服务端缺陷） × 请求可被构造（信息泄露） ＝ CSRF 攻击成立

3.2 攻击原理与流程

用户登录 bank.com → 浏览器获得 Cookie（Session ID） ↓ 用户访问攻击者控制的 evil.com ↓ evil.com 页面中的恶意代码自动向 bank.com 发起请求 ↓ 浏览器自动携带 bank.com 的 Cookie ↓ bank.com 服务器认为是合法用户的操作 → 执行转账等操作

4. CSRF漏洞总结