第 6 卷
11. 解释跨站请求伪造(CSRF)攻击及其防御机制
已登录目标网站的用户，在不知情的情况下向目标网站发起恶意请求（如转账、修改密码、提交表单等），利用用户的合法身份（Cookie/Session）完成攻击，核心危害是「冒充用户执行未授权操
作」。
一、CSRF攻击的核心原理与流程
• 核心前提：用户已登录目标网站，浏览器保存了该网站的身份凭证（如Session Cookie），且
Cookie默认会随跨域请求自动携带。
• 攻击流程：
- 攻击者构造恶意请求（如转账接口的HTTP请求），并将其隐藏在恶意网页/链接中（如图片标
签、iframe、诱导点击的链接）。
- 诱导已登录目标网站的用户访问该恶意网页/点击链接。
- 用户浏览器在加载恶意内容时，自动携带目标网站的Cookie，向目标网站发起恶意请求。
- 目标网站验证Cookie有效，误认为是用户主动发起的请求，执行恶意操作（如转账成功、密码被
修改）。
二、CSRF攻击的典型场景
- 金融类网站：诱导用户发起转账、支付请求。
- 用户中心：诱导用户修改密码、绑定恶意手机号、修改收货地址。
- 内容管理系统：诱导管理员发布恶意文章、删除数据。
三、CSRF的核心防御机制（前端+后端协同）
CSRF防御的核心原则是「让服务器能够区分请求是用户主动发起的，还是攻击者伪造的」，关键在于验证请求的「合法性」和「用户意图」，主要防御手段如下：
- 核心防御：添加CSRF Token（推荐，最有效）
• 原理：服务器为每个登录用户生成一个唯一的、随机的CSRF Token（令牌），并将Token存储在
Session中（后端）和页面中（如隐藏表单字段、前端存储）；用户发起请求时，必须携带该 Token，服务器验证Token的有效性（是否存在、是否与Session中的一致），验证通过才执行请
求。由于攻击者无法获取用户页面中的CSRF Token，无法构造合法请求。
• 实现流程：
- 前端发起请求：表单提交时自动携带csrfToken字段，或AJAX请求时在请求头中添加X-CSRF-
Token字段。
- 服务器验证：接收请求后，对比请求携带的Token与Session中的Token，一致则放行，不一致
则拒绝（返回403 Forbidden）。
• 前端注意事项：AJAX请求需主动在请求头中携带Token，避免遗漏；禁止将Token存储在Cookie
中（防止被攻击者利用），优先存储在页面DOM或localStorage中。
- 验证请求来源：检查Referer/Origin请求头
• 原理：HTTP请求头中的Referer字段记录了请求的来源页面URL，Origin字段记录了请求的来源域
名（不含路径）。服务器可通过验证Referer/Origin是否为可信域名（如目标网站自身域名），拒绝来自不可信域名的请求。
• 实现方式：
- 验证Referer：如目标网站域名为example.com，仅放行Referer以https://example.com/开头的
请求。
- 验证Origin：仅放行Origin为https://example.com的请求（Origin优先级高于Referer，更安全，
无路径信息，避免Referer被篡改）。
• 局限性：Referer可能被浏览器插件、代理服务器篡改或隐藏（如用户设置隐私模式），无法作为唯
一防御手段，仅作为辅助防御。
- 强化Cookie安全：设置SameSite属性
• 原理：Cookie的SameSite属性用于限制Cookie在跨域请求中的携带行为，从根源上阻止攻击者利
用用户Cookie发起跨站请求。
• SameSite属性值：
- SameSite=Strict：仅在同源请求中携带Cookie，完全禁止跨站请求携带，防御效果最强（可能
影响正常跨域业务，如第三方登录）。
- SameSite=Lax：仅在GET请求、用户主动点击链接等“安全的跨站请求”中携带Cookie，禁止
嵌入在恶意网页中的跨站请求（如图片、iframe）携带，是平衡安全性和可用性的推荐值。
- SameSite=None：允许跨域请求携带Cookie，需配合Secure属性（仅HTTPS协议下生效），适
用于需要跨域携带Cookie的场景（如第三方支付、跨域单点登录）。
- 实现方式：后端设置Cookie时添加SameSite属性，如Set-Cookie: sessionId=xxx;
SameSite=Lax; Secure; HttpOnly。
- 其他辅助防御手段
• 重要操作二次验证：对敏感操作（如转账、修改密码），添加验证码、短信验证、密码再次输入等
• 限制请求方法：敏感接口仅允许POST请求（GET请求易被嵌入图片、链接中触发），但POST请求
- 缩短Session/Cookie有效期：减少用户登录状态的持续时间，降低CSRF攻击的窗口时间。
12. 什么是SQL注入攻击?尽管主要是后端的问题，前端开发者如何帮助防
御?
SQL注入攻击（SQL Injection）是攻击者通过将恶意SQL代码插入到用户输入的数据中，欺骗服务器执行该恶意SQL语句，从而实现窃取数据库数据、修改/删除数据库内容、甚至控制服务器的一种严重
Web安全漏洞。其核心原因是「后端未对用户输入进行严格过滤，直接将用户输入拼接到SQL语句中执行」。
一、SQL注入攻击的核心原理与示例
• 核心原理：后端程序将用户输入的字符串直接拼接到SQL语句中，导致用户输入的恶意SQL代码被
解析并执行。
• 攻击示例：
- 正常场景：用户登录页面，后端SQL语句为 SELECT * FROM users WHERE
username='{$username}' AND password='{$password}'，用户输入合法用户名/密码（如admin/123456），SQL语句正常执行。
- 攻击场景：攻击者在用户名输入框输入 ' OR '1'='1，密码任意输入，拼接后的SQL语句变
为 SELECT * FROM users WHERE username='' OR '1'='1' AND password='xxx'。由于 '1'='1' 恒为真，该SQL语句会查询出所有用户数据，攻击者无需正
确密码即可登录。
二、SQL注入的危害
- 窃取敏感数据：如用户账号密码、个人信息、交易记录、商业机密等。
- 篡改数据库：修改用户数据、添加恶意账号、篡改网站内容。
- 删除数据：执行DELETE、DROP语句，导致数据丢失、网站瘫痪。
- 控制服务器：通过SQL注入获取服务器权限，植入恶意程序、挖矿病毒等。
三、前端开发者的防御协助措施
SQL注入的核心防御责任在后端（如使用参数化查询、ORM框架），但前端作为用户输入的“第一道关口”，可通过输入过滤、数据校验等手段，从源头减少恶意输入的可能性，辅助后端提升防御能
力。
全站分卷索引 · 10 卷
- 1第 1 卷
- 浏览器缓存核心面试题全解析
- 浏览器缓存核心面试题（全解析）
- 1. 浏览器缓存的工作原理
- 完整工作流程
- ◦ ✅ 缓存有效：直接读取本地缓存（强缓存），不发起网络请求，状态码 200 OK (from
- ◦ ❌ 缓存失效：发起条件请求到服务器，服务器根据资源标识判断资源是否更新：
- ▪ 资源未更新：返回 304 Not Modified，无资源体，浏览器复用本地缓存（协商缓
- 缓存存储位置（优先级从高到低）
- • Memory Cache（内存缓存）：速度最快，生命周期随浏览器标签页关闭而消失，存储小体积、高
- • Disk Cache（磁盘缓存）：速度稍慢，持久化存储，关闭浏览器后仍存在，存储大体积、低频使用
- • Service Worker Cache：独立于浏览器的缓存，可自定义缓存规则，支持离线访问（PWA核
- 2. HTTP头中与缓存策略相关的字段
- 2第 2 卷
- 4. 强缓存和协商缓存（核心区别+定义）
- ✅ 强缓存（本地缓存直接生效，无网络请求）
- • Cache-Control: max-age=xxx 未过期
- • Expires 时间戳未到（客户端时间未超过该值）
- • 无网络请求，加载速度最快
- • 状态码： 200 OK (from disk cache/memory cache)
- • 核心控制字段： Cache-Control（主）、 Expires（辅）
- ✅ 协商缓存（需与服务器验证，轻量网络请求）
- • 强缓存过期（ max-age 到期/ Expires 超时）
- • 手动刷新页面（F5），强制跳过强缓存
- • 资源设置 Cache-Control: no-cache
- • 有网络请求，但仅传输少量头部信息，带宽消耗低
- 3第 3 卷
- ✅ 四、CDN缓存协同优化（生产必备）
- ✅ 五、避坑要点（缓存策略常见问题）
- ✅ 六、最终缓存策略总结（生产环境标配）
- 追加交付物提议
- 6. 浏览器缓存如何影响HTTP请求？不同的缓存策略会如何改变请求响
- 一、浏览器缓存对HTTP请求的核心影响
- • 拦截请求：强缓存生效时，浏览器直接复用本地缓存，不向服务器发起任何HTTP请求，彻底跳过
- • 优化请求：协商缓存时，浏览器发起“条件请求”（仅携带资源标识等少量头部信息），服务器仅
- • 改变响应逻辑：缓存存在时，服务器可能返回304（资源未更新）而非200（新资源），浏览器需复
- • 延长资源复用周期：合理的缓存策略可让资源在本地重复使用，减少同一资源的重复下载请求，提
- 二、不同缓存策略对请求响应的具体改变
- • 强制刷新（Ctrl+F5）：完全禁用缓存，请求头携带Cache-Control: no-cache、Pragma: no-
- 4第 4 卷
- • Local Storage/Session Storage：虽非HTTP缓存，但可查看页面存储的本地数据，辅助判断是
- • Clear storage：一键清除所有缓存（包括磁盘/内存缓存、Service Worker缓存），方便重新测试
- 三、调试缓存的核心流程（实战步骤）
- 8. 描述浏览器如何处理强缓存和协商缓存的决策过程
- 完整决策流程（步骤拆解）
- 特殊决策场景（影响流程的关键因素）
- • 资源无缓存规则：服务器未返回任何缓存相关HTTP头，浏览器默认不缓存该资源，每次请求都从
- • 设置Cache-Control: no-cache：强制跳过强缓存流程，直接进入协商缓存，每次请求都需向服务
- • 设置Cache-Control: no-store：完全禁用缓存，浏览器不存储任何资源副本，每次请求都从服务
- • 手动/强制刷新：手动刷新（F5）强制跳过强缓存，进入协商缓存；强制刷新（Ctrl+F5）禁用所有
- 9. 其他缓存相关的问题
- 一、缓存穿透（缓存未命中，请求直达服务器）
- 5第 5 卷
- • 核心解决方案：
- 四、CDN缓存与浏览器缓存的协同
- • 核心原则：CDN缓存作为“中间代理缓存”，应与浏览器缓存规则保持一致，同时承担“就近分
- • 协同策略：
- 五、HTTP1.0与HTTP1.1缓存机制的差异
- • HTTP1.0：仅支持Expires（绝对时间戳）和Pragma: no-cache，依赖客户端本地时间，易出现缓
- • HTTP1.1：新增Cache-Control（支持max-age、public/private等多指令）、ETag，优先级高于
- 一、XSS攻击的三种主要类型
- • 攻击流程：攻击者将恶意脚本注入到目标网站的数据库中（如评论区、用户资料、留言板等可提交
- • 攻击流程：攻击者构造包含恶意脚本的URL → 诱导用户点击该URL → 目标网站将URL中的恶意脚
- • 特点：恶意脚本不存储在服务器，仅存在于攻击URL中，需用户主动点击才能触发，危害相对存储
- • 攻击流程：攻击者构造包含恶意脚本的URL → 用户点击后，目标网站的前端JavaScript代码从URL
- 6第 6 卷
- 11. 解释跨站请求伪造(CSRF)攻击及其防御机制
- 一、CSRF攻击的核心原理与流程
- • 核心前提：用户已登录目标网站，浏览器保存了该网站的身份凭证（如Session Cookie），且
- • 攻击流程：
- 二、CSRF攻击的典型场景
- 三、CSRF的核心防御机制（前端+后端协同）
- • 原理：服务器为每个登录用户生成一个唯一的、随机的CSRF Token（令牌），并将Token存储在
- • 实现流程：
- • 前端注意事项：AJAX请求需主动在请求头中携带Token，避免遗漏；禁止将Token存储在Cookie
- • 原理：HTTP请求头中的Referer字段记录了请求的来源页面URL，Origin字段记录了请求的来源域
- • 实现方式：
- • 局限性：Referer可能被浏览器插件、代理服务器篡改或隐藏（如用户设置隐私模式），无法作为唯
- 7第 7 卷
- • 输入合法性校验：根据业务场景，对用户输入的数据类型、格式、长度进行严格校验，拒绝不符合
- • 特殊字符过滤/转义：对用户输入中的SQL特殊字符（如单引号'、双引号"、分号;、逗号,、星号*、-
- • 对所有用户输入字段设置合理的长度限制（如用户名3-20位、密码6-20位、评论内容0-500字），
- • 目的：缩短攻击者可注入的恶意SQL代码长度，降低攻击成功率（复杂的恶意SQL语句通常需要较
- • 禁止在前端将用户输入拼接到任何类似SQL的字符串中（即使是前端模拟数据展示），避免被攻击
- • 示例：前端搜索功能，禁止将用户输入的关键词直接拼接到类似 SELECT * FROM goods
- • 敏感操作使用POST请求：GET请求的参数会暴露在URL中，易被攻击者篡改和利用；敏感接口
- • 避免在URL中暴露敏感参数：如用户ID、订单ID、数据库表名等敏感信息，不要作为URL参数传递
- • 对用户输入的非法内容，给出明确的错误提示（如“用户名仅允许字⺟、数字、下划线”），引导
- • 避免给出详细的错误信息：如用户登录失败时，提示“用户名或密码错误”，而非“用户名不存
- • 前端向后端传递用户输入时，采用“键值对”的形式传递原始数据（而非拼接后的字符串），让后
- • 示例：登录请求传递 {username: "admin", password: "123456"}，而非传递拼接后的
- 8第 8 卷
- 14. 解释同源策略(SOP)及其对Web安全的意义
- 一、同源的定义（三个条件必须同时满足）
- • 协议（Protocol）相同：如都是HTTP或都是HTTPS（http://example.com与
- • 域名（Domain）相同：如example.com与www.example.com不同源（子域名不同），
- • 端口（Port）相同：如http://example.com:80与http://example.com:8080不同源（默认端口可
- 二、同源策略的核心限制范围
- • 不同源的脚本无法访问当前源页面的DOM元素，如通过iframe嵌入的不同源页面，父页面无法获取
- • 示例：攻击者在恶意网站中嵌入银行网站的iframe，由于同源策略限制，恶意脚本无法获取iframe
- • 不同源的脚本无法访问当前源的本地存储数据，包括Cookie、localStorage、sessionStorage、
- • 示例：恶意网站的脚本无法读取用户访问银行网站时存储在localStorage中的用户信息，也无法获
- • 不同源的脚本无法向当前源发起AJAX/Fetch请求（跨域请求），浏览器会拦截该请求，返回CORS
- • 示例：前端项目部署在http://frontend.com，无法直接通过AJAX请求http://backend.com的接口
- 9第 9 卷
- • 场景描述：PWA（渐进式Web应用）等支持离线访问的应用，对离线存储的业务数据（如离线订
- 二、前端加密的核心限制（不可替代后端加密）
- • 前端加密的密钥必须存储在前端代码中（如JS文件）或通过网络传输到前端，攻击者可通过查看源
- • 示例：前端使用RSA加密密码，公钥存储在JS文件中，攻击者可直接获取公钥，无法保证加密的安
- • 前端代码完全暴露在客户端，攻击者可通过修改JS代码篡改加密逻辑（如禁用加密、替换为明文传
- • 示例：攻击者通过浏览器开发者工具修改登录页面的JS代码，绕过密码加密逻辑，直接提交明文密
- • 前端加密依赖浏览器的加密API（如Web Crypto API），若浏览器存在安全漏洞，或用户使用被篡
- • 前端加密仅能保证数据传输过程的安全性，无法保证后端接收数据后的数据存储、处理过程的安全
- • 前端加密（尤其是非对称加密）需要消耗浏览器的CPU资源，可能影响页面性能（如复杂加密逻辑
- • 部分旧浏览器不支持现代加密API（如Web Crypto API），存在兼容性问题，需额外处理降级方
- 三、前端加密的使用原则
- • 前端加密仅作为「补充防护」，核心安全保障必须依赖后端加密（如HTTPS、后端参数验证、数据
- 10第 10 卷
- • 实现方式：使用AJAX请求拦截器，对需要特定权限的接口，前端先验证用户是否拥有该权限，无权
- • 注意：前端接口级权限控制仅为辅助，后端必须对每个敏感接口再次验证用户权限，防止攻击者绕
- 三、前端认证和授权的安全加固措施
- • 使用HTTPS协议：所有认证相关的请求（登录、令牌刷新、敏感接口）必须通过HTTPS传输，防
- • 安全存储令牌：
- • 设置合理的令牌有效期：JWT令牌有效期不宜过长（如2小时），同时实现令牌刷新机制（Refresh
- • 防范XSS攻击窃取令牌：开启CSP（内容安全策略）、对用户输入进行过滤编码、避免使用
- • 防范CSRF攻击：若使用Cookie存储令牌，必须设置SameSite属性；同时对敏感操作（如修改密
- • 用户退出登录时清理数据：用户点击退出登录后，前端需清除存储的令牌、权限信息等，同时调用
- • 敏感操作二次验证：对核心敏感操作（如修改密码、绑定手机号、大额转账），添加验证码、短信
- 四、常见问题与避坑要点
- • ❌ 仅依赖前端权限控制：后端必须对所有敏感接口进行权限验证，前端权限控制仅为用户体验优