Web 安全常见面试题总结：SQL 注入、XSS、CSRF、SSRF 与接口安全

Guide约 4307 字大约 14 分钟

这篇文章按后端面试常见攻击面整理，重点放在漏洞产生条件、修复手段和工程限制。认证、JWT、OAuth 2.0 与权限模型见认证与授权常见面试题总结。

输入与浏览器安全

⭐️什么是 SQL 注入？如何防止？

SQL 注入发生在应用把不可信输入作为 SQL 代码的一部分拼接执行。攻击者可以改变原查询语义，读取、修改甚至删除不该访问的数据。

主要防护手段是：

使用 PreparedStatement、ORM 参数绑定或 MyBatis #{}，让数据库区分 SQL 代码和数据。
表名、列名和排序方向无法使用普通绑定参数时，使用服务端枚举或白名单映射，不能直接拼接用户输入。
数据库账号遵循最小权限，读服务不授予写权限，应用账号不使用 DBA 权限。
输入校验作为补充，但不能用“过滤几个关键字”代替参数化查询。

MyBatis ${} 是文本替换，适合受控的 SQL 片段。直接接收前端排序字段再写入 ${orderBy} 仍然会产生注入风险。

⭐️什么是 XSS？有哪些类型？

XSS（Cross-Site Scripting，跨站脚本攻击）让攻击者控制的内容在其他用户浏览器中作为代码执行。

常见类型有：

反射型 XSS：恶意输入随当前请求返回并执行，例如搜索参数直接写回页面。
存储型 XSS：恶意内容被保存到数据库，其他用户查看时执行，例如评论、昵称和富文本。
DOM 型 XSS：前端脚本把不可信数据写入危险 DOM API，漏洞主要发生在浏览器端。

防护重点是按输出上下文编码：HTML、属性、URL、JavaScript 和 CSS 上下文不能共用同一种转义。需要展示富文本时使用成熟的 HTML Sanitizer，并限制协议、标签和属性；减少 innerHTML、document.write、eval 等危险 API。CSP 可以降低部分攻击影响，但不能代替正确编码和净化。

⭐️什么是 CSRF？如何防止？

CSRF（Cross-Site Request Forgery，跨站请求伪造）利用浏览器会自动携带 Cookie 等凭据的行为，诱导已登录用户向目标站点发起非本人意愿的状态变更请求。

CSRF 利用浏览器自动携带 Cookie 发起请求

常见防护措施包括：

对状态变更请求校验不可预测并绑定会话的 CSRF Token。
根据架构使用同步 Token 或正确实现的 Double Submit Cookie。
校验 Origin，缺失时再按策略检查 Referer。
给会话 Cookie 配置合适的 SameSite，并使用 Secure、HttpOnly。
不用 GET 执行转账、改密、删除等状态变更操作。
对支付、改密等高风险操作要求用户再次确认或重新认证。

XSS 可能绕过很多 CSRF 防护，因此两类漏洞需要同时治理。CORS 也不是通用的 CSRF 防护方案。

⭐️什么是 SSRF？如何防止？

SSRF（Server-Side Request Forgery，服务端请求伪造）发生在服务端根据用户可控 URL 发起请求。攻击者可能借此访问本机管理端口、云元数据服务或内网系统。

防护时优先取消任意 URL 能力：业务只需要访问固定合作方时，对协议、域名、端口和路径做白名单。还要继续处理：

只允许 https 等必要协议，拒绝 file、gopher 等无关协议。
DNS 解析后校验目标 IP，阻止环回、私网、链路本地和保留地址；跳转后的目标也要重新校验。
防范 DNS Rebinding、IPv6、十进制或混合编码 IP 等绕过。
通过出口代理、网络 ACL 和云防火墙限制应用可访问的地址。
设置连接/读取超时、响应大小和重定向次数上限。

只用正则判断 URL 字符串不够，因为域名解析和重定向可能把请求带到另一个地址。

CORS 是什么？它能阻止接口被调用吗？

CORS（Cross-Origin Resource Sharing）是浏览器执行的跨源读取控制机制。服务端通过响应头声明哪些 Origin、方法和请求头可以被浏览器页面使用。

CORS 不能替代认证和授权：curl、服务端程序、恶意 App 不受浏览器同源策略约束，仍然可以直接请求 API。简单跨源请求甚至可能已经发送到服务端，只是浏览器不把响应内容交给脚本。

配置带凭据请求时，不能把 Access-Control-Allow-Origin 随意反射为任意 Origin，也不能与通配符混用。允许列表要精确匹配协议、主机和端口。

接口与传输安全

⭐️如何防止接口请求被篡改和重放？

HTTPS 负责保护传输链路；接口签名用于验证请求来自持有密钥的一方，并校验关键字段没有被修改。常见签名内容包括 HTTP 方法、规范化路径、查询参数、Body 摘要、时间戳、随机数和客户端标识。

服务端需要：

使用 HMAC 或数字签名验证完整性和来源。
限制时间戳允许的偏差。
在有效窗口内记录并拒绝重复 nonce 或请求 ID。
使用恒定时间比较签名，提供密钥轮换和吊销能力。
对业务操作继续做幂等校验，不能把安全防重放等同于业务幂等。

签名不能隐藏请求内容，不能替代 HTTPS。把固定密钥硬编码在前端 JavaScript 或可被反编译的客户端中，也无法建立可靠的客户端身份。

HTTPS 如何保证传输安全？

HTTPS 在 HTTP 与 TCP 之间使用 TLS，主要提供：

机密性：会话密钥加密应用数据。
完整性：认证加密或 MAC 防止数据被静默修改。
身份认证：客户端验证服务端证书链、域名和有效期。

TLS 握手通常利用非对称密码和证书完成身份验证与密钥协商，后续数据使用效率更高的对称加密。生产环境应全站使用 HTTPS，正确校验证书，禁用过时协议和弱密码套件，并根据场景启用 HSTS。

下面以 TLS 1.2 的 ECDHE_RSA 握手为例：

TLS 1.2 ECDHE_RSA 握手流程

HTTPS 不能修复 SQL 注入、越权或 XSS。它保护的是通信链路，不会自动保证业务代码安全。

CORS、CSRF 和 XSS 有什么区别？

名称	解决或利用的问题	主要防护
CORS	浏览器是否允许页面脚本读取跨源响应	精确配置允许的 Origin、方法和请求头
CSRF	利用浏览器自动携带凭据发起非预期请求	CSRF Token、Origin 校验、SameSite、重新认证
XSS	不可信内容在页面中作为脚本执行	上下文编码、HTML 净化、安全 DOM API、CSP

三者可能互相影响，但不能相互替代。例如，修好 CORS 不代表没有 CSRF；HttpOnly 能降低 Cookie 被脚本直接读取的风险，但 XSS 仍可能调用站内接口。

Webhook 回调如何验真？

使用 HTTPS，并按第三方协议验证 HMAC 或数字签名。
签名覆盖原始请求体，避免 JSON 重新序列化后字段顺序和空白变化导致验签错误。
校验时间戳、事件 ID 和重放窗口。
以事件 ID 建立唯一约束或幂等记录，重复回调返回成功但不重复执行业务。
密钥支持轮换，轮换期可短暂同时接受新旧密钥。
不把来源 IP 白名单作为唯一验证方式；云平台出口地址会变化，代理头也可能被伪造。

接收成功与业务处理成功可以分开：先可靠落库或写入队列，再异步处理，避免第三方因超时反复重试放大压力。

密码、密钥与敏感数据

⭐️密码应该如何存储？

密码应使用专门的密码哈希算法，不使用可逆加密，也不直接使用 MD5、SHA-1 或 SHA-256 这类高速哈希。

OWASP 当前优先推荐 Argon2id；无法使用时可以选择 scrypt，遗留或兼容场景常用 bcrypt、PBKDF2。参数要根据服务器能力调到可接受的验证耗时，并为每个密码使用随机盐。成熟密码库通常会自动生成盐，并把算法、参数和盐编码进哈希结果。

可选的 Pepper 应与数据库分开保存在 KMS、HSM 或密钥管理系统中。Pepper 泄露后需要制定轮换方案；忘记密码只能重置，不能从密码哈希中还原原密码。

加密、哈希、编码和签名有什么区别？

手段	是否可逆	是否需要密钥	常见用途
编码	可逆	不需要	数据表示与传输，如 Base64
哈希	单向	通常不需要	完整性摘要、密码哈希的组成部分
对称加密	可逆	加解密共享密钥	大量数据保密，如 AES-GCM
非对称加密	可逆	公钥与私钥	密钥封装、小数据加密
数字签名	验证而非解密	私钥签名、公钥验证	身份和完整性证明
HMAC	验证而非解密	共享密钥	接口签名、消息完整性