04. 网络安全基础：认证、加密、接口安全与常见攻击（深挖版）¶

网络安全题在很多后端 / 基础设施岗位里，问法通常不会像安全岗那么偏攻防细节，但它很容易成为判断你有没有工程边界感的一道题。

很多候选人谈到安全时，只会说：

HTTPS 更安全

JWT 做登录

防 SQL 注入

但真正的面试官往往会继续追问：

HTTPS 到底解决了哪些问题，哪些问题它根本没解决？

认证和授权为什么不是一回事？

Token 为什么会被重放？

接口为什么会被刷？

为什么内部 RPC 也要做权限和凭证控制？

这一章的目标，不是把安全讲成攻防大全，而是把后端工程最常见、最容易被问到的安全主线讲清楚。

先把这一章的知识骨架搭起来¶

网络安全基础题在后端岗位里，核心不是炫攻击手法，而是证明你知道 身份如何确认、数据如何保密、请求如何被滥用、接口如何被保护。所以认证、鉴权、加密、签名、重放攻击、防刷、防注入这些点，本质上都在回答“系统怎样在不可信网络里安全地提供服务”。

建议按四条线去理解：第一条是确认“你是谁”，也就是身份认证；第二条是决定“你能干什么”，也就是授权；第三条是保护“传输和存储的数据不被窃听篡改”，也就是加密、签名、证书；第四条是限制“恶意输入和异常流量”，也就是接口安全、防重放、防注入、限流风控。

这样回答安全题时，才不会只停在“HTTPS 更安全”这种空句子上。

进入问答前，先把最小前置知识补齐¶

安全这章最容易答空的地方，是把所有问题都混成“安全要做好”。更稳的方式是先分层：传输层风险、身份风险、权限风险、输入风险、流量风险。HTTPS 主要解决传输过程的窃听和篡改，认证解决“你是谁”，授权解决“你能做什么”，接口安全则继续处理重放、刷接口、注入和越权问题。

只有先把这几个风险面分开，后面说 JWT、证书、签名、限流、防注入时，才不会像在报菜名。

1. 后端面试里的“网络安全基础”到底在考什么？¶

标准回答¶

后端面试里的网络安全基础，主要考的是你是否理解：

数据传输过程中的风险
身份认证与权限控制
常见 Web / API 攻击面
敏感信息如何存储与管理
内外部服务调用如何做安全边界控制

更深入的理解¶

很多后端候选人会觉得“安全不是安全岗的事”，这是一个很常见的误区。实际上，后端系统一旦上线，最直接暴露在外的就是：

API
登录系统
鉴权逻辑
数据库访问入口
服务间调用链路

所以后端面试考安全，重点不是让你做渗透，而是想确认：

你有没有基本的攻击面意识、边界意识和最小防护能力。

一句总结¶

后端安全题最核心的不是攻击技巧，而是理解“数据和请求在流经系统时，在哪些地方会暴露风险，以及应该如何做基本防护”。

2. HTTPS / TLS 到底解决什么问题？¶

标准回答¶

HTTPS 通过 TLS 协议在应用层之下建立安全通道，主要解决：

机密性：防窃听
完整性：防篡改
身份认证：确认你连接的是正确服务

更深入的理解¶

很多人会把 HTTPS 简化成“加密传输”，这只说对了一部分。真正完整的理解应该是：

1）防窃听¶

攻击者即使截获了链路数据，也无法直接读懂内容。

2）防篡改¶

数据传输过程中如果被中间人修改，完整性校验会失败。

3）服务端身份认证¶

客户端通过证书和 CA 信任链判断：

这个公钥是不是这个域名对应的公钥
自己是不是连到了正确的服务

高分点¶

HTTPS 不只是“把内容加密”，它本质上是在解决链路上的三类问题：窃听、篡改和身份伪造。

3. 对称加密和非对称加密有什么区别？¶

标准回答¶

对称加密：加密和解密使用同一把密钥，速度快，适合大数据量传输
非对称加密：加密和解密使用公钥 / 私钥对，速度较慢，适合密钥交换和身份认证

为什么 HTTPS 同时需要它们？¶

因为两者各有优缺点：

对称加密¶

优点：

快
适合后续大规模数据传输

缺点：

双方如何安全共享密钥是难点

非对称加密¶

优点：

适合安全交换信息
可用于身份验证和签名

缺点：

计算成本高

所以 HTTPS 通常做法是¶

握手阶段用非对称机制做密钥协商 / 认证
数据传输阶段用对称密钥提高效率

一句总结¶

非对称加密负责把“怎么安全建立信任和共享密钥”这件事解决掉，对称加密负责把后续大流量传输做得足够高效。

4. 什么是数字证书？为什么需要 CA？¶

标准回答¶

数字证书用于把“某个域名 / 实体”和“某个公钥”绑定起来，由受信任的证书颁发机构（CA）签名背书。

为什么光有公钥还不够？¶

因为如果没有可信第三方背书，攻击者完全可以：

自己生成一对公私钥
假装这是目标服务的公钥

客户端就无法确认：

这个公钥到底属于谁

CA 的价值是什么？¶

CA 相当于在说：

我验证过这个证书持有者
这个公钥确实属于这个域名 / 实体

客户端信任 CA，于是间接信任证书里的公钥绑定关系。

高分点¶

数字证书解决的核心问题不是“传公钥”，而是“证明这个公钥属于你声称的那个服务”。

5. HTTPS 已经很安全了，为什么还不够？¶

标准回答¶

HTTPS 只解决链路安全问题，不自动解决：

业务越权
接口滥用
重放攻击
数据库泄露后的数据暴露
内部服务凭证滥用
逻辑漏洞

为什么这题很重要？¶

因为很多人会把“用了 HTTPS”误以为“系统就安全了”。其实 HTTPS 保护的是：

传输过程

但系统还可能在别处出问题：

权限校验写错
token 设计不合理
密码明文存储
内部服务没做鉴权

一句总结¶

HTTPS 是链路安全的基础设施，不是系统安全的全部答案。

6. 认证（Authentication）和授权（Authorization）有什么区别？¶

标准回答¶

认证：确认你是谁
授权：确认你能做什么

为什么很多人会混？¶

因为登录后看起来像“一步完成”，但实际上这是两层问题：

认证¶

系统确认：

这个请求发起者是不是用户 A
身份凭证是否有效

授权¶

系统进一步确认：

用户 A 能不能访问这个资源
能不能执行这个操作

一个典型例子¶

你登录成功，只说明认证通过；但你能不能看某条订单、修改某个配置、访问某个管理接口，是授权问题。

高分点¶

很多安全事故不是“没登录就能进”，而是“登录了但权限校验做错了”，这说明认证和授权必须分开理解。

7. Session、Cookie、Token、JWT 怎么理解？¶

1）Session¶

服务端保存会话状态，客户端通过 session id 关联。

优点¶

状态集中，易控制吊销

缺点¶

扩展时要考虑共享存储或 session 同步

2）Cookie¶

浏览器端保存的小块数据，经常用于：

携带 session id
保存部分客户端状态

注意： Cookie 不是认证方案本身，而是一种载体。

3）Token¶

服务端签发给客户端的令牌，客户端请求时带上它作为身份凭证。

4）JWT¶

JWT 是一种 token 格式，通常包含：

header
payload
signature

高分点¶

JWT 的常见误区是：

以为 JWT 天然安全
以为用了 JWT 就不需要服务端状态管理

实际上它仍然取决于：

签名算法
密钥保护
过期时间
刷新机制
吊销策略

一句总结¶

Session 和 Token 是会话管理思路，Cookie 和 JWT 更像承载方式或格式；真正安全与否取决于整个认证设计，而不是某个名词本身。

8. 什么是重放攻击？为什么 API 容易中招？¶

标准回答¶

重放攻击是指攻击者截获一段合法请求后，在之后重复发送，以伪造重复操作。

为什么会发生？¶

因为很多请求即使内容合法，系统如果不判断：

这个请求是不是过期了
这个请求是不是已经用过了

就可能把重复请求当成新请求执行。

常见风险场景¶

支付请求
短信发送接口
签名请求
登录换取 token 的接口

常见防护手段¶

时间戳（timestamp）
随机数（nonce）
请求签名
一次性 token
幂等号 / request id

高分点¶

重放攻击本质上不是请求内容非法，而是系统无法判断“这是不是一份旧的、被重复利用的合法请求”。

9. 为什么密码不能明文存储？¶

标准回答¶

因为一旦数据库泄露，明文密码会直接暴露用户真实凭证，风险会迅速扩散到用户在其他系统复用的密码。

正确思路是什么？¶

不是“加密存一下”这么简单，而是：

使用专门密码哈希算法
加盐
提高暴力破解成本

常见方案¶

bcrypt
scrypt
Argon2

为什么不能直接用普通哈希（如裸 MD5 / SHA）？¶

因为：

太快
容易被撞库和彩虹表攻击
抗暴力破解能力差

一句总结¶

密码存储的核心目标不是“以后还能解出来”，而是“即使数据库泄露，也尽量无法恢复原密码”。

10. SQL 注入是什么？为什么预编译能防？¶

标准回答¶

SQL 注入是攻击者把恶意 SQL 片段拼进输入中，使服务端执行了非预期 SQL。

为什么会发生？¶

本质上是：

程序把“数据”当成了“SQL 语句的一部分”

比如把用户输入直接拼接成 SQL 字符串。

为什么参数化查询 / 预编译能防？¶

因为它把：

SQL 结构
参数值

分开处理。数据库会把参数当成数据，而不是 SQL 语法片段去解析。

高分点¶

SQL 注入的本质不是输入里有特殊字符，而是系统没有把“代码”和“数据”隔离开。

11. XSS 和 CSRF 是什么？后端要怎么理解？¶

XSS（跨站脚本）¶

攻击者把恶意脚本注入页面，在其他用户浏览页面时执行。

后端需要知道什么？¶

输出到页面前要做转义
不信任用户输入
合理设置 CSP 等安全策略

CSRF（跨站请求伪造）¶

攻击者诱导已登录用户在不知情情况下向目标站点发起请求。

后端需要知道什么？¶

CSRF token
SameSite Cookie
Referer / Origin 校验

一句总结¶

XSS 更偏“恶意脚本执行”，CSRF 更偏“利用用户已登录状态发请求”，后端虽然不一定写前端，但必须理解其防护边界。

12. 为什么接口会被刷？怎么防刷？¶

标准回答¶

接口被刷通常是因为攻击者或脚本利用接口无频控、低门槛、收益高的特点，进行暴力调用或资源消耗攻击。

常见被刷场景¶

短信验证码
登录接口
优惠券接口
注册接口
搜索接口
评论 / 点赞 / 投票接口

防刷手段¶

限流
验证码 / 人机校验
IP / 账号 / 设备维度频控
风控规则
请求签名
黑白名单

高分点¶

防刷问题本质上不是“把一个 IP 挡掉”这么简单，而是识别异常行为模式，并限制低成本高频滥用。

13. 为什么内部服务调用也需要安全控制？¶

标准回答¶

因为内部网络不等于可信网络，内部服务如果缺少鉴权、凭证和权限边界，一旦某个节点被攻破或凭证泄露，就可能横向扩散风险。

常见误区¶

很多系统觉得：

内网环境就安全
RPC 不需要鉴权
服务之间默认互信

这其实是很危险的。

应考虑的能力¶

服务身份认证
mTLS
接口权限控制
凭证轮换
最小权限原则

一句总结¶

内部服务安全的核心不是“防外部人进来”，而是防止内部凭证滥用和横向移动把局部问题升级成系统性问题。

14. 什么是最小权限原则？为什么重要？¶

标准回答¶

最小权限原则指每个用户、服务、进程只拥有完成当前任务所必需的最小权限。

为什么重要？¶

因为权限越大，一旦：

凭证泄露
接口越权
某服务被攻破

造成的破坏范围就越大。

典型应用¶

数据库账号按读写权限拆分
不同服务只开放必要 API
管理后台分角色授权
Secret 按命名空间 / 环境隔离

高分点¶

最小权限原则的价值，不在平时，而在事故发生时能不能把损失限制在局部范围内。

15. 敏感信息管理为什么是后端安全的一部分？¶

标准回答¶

敏感信息管理包括：

密钥
token
数据库密码
私钥
用户隐私数据

它们如果被日志、配置文件、代码仓库或错误页面泄露，会造成严重后果。

常见错误¶

把密钥写进代码
在日志里打出完整 token
测试环境沿用生产账号
错误页面返回内部堆栈与配置

正确思路¶

Secret 专门管理
日志脱敏
按环境隔离配置
定期轮换凭证

一句总结¶

很多系统不是被“攻破”，而是自己把密钥、token 和内部信息泄露出去了。

16. 一组典型追问链¶

HTTPS 到底解决了什么问题？
对称加密和非对称加密为什么要一起用？
数字证书和 CA 在证明什么？
为什么 HTTPS 不是安全的全部？
认证和授权为什么必须分开理解？
JWT 为什么不是天然安全？
重放攻击为什么会发生？怎么防？
密码为什么不能明文存，为什么普通哈希也不够？
SQL 注入为什么参数化查询能防？
XSS 和 CSRF 分别是什么？
接口为什么会被刷？如何防刷？
内部 RPC 为什么也要鉴权？
最小权限原则为什么重要？
敏感信息管理为什么是安全基础设施的一部分？

17. 一份更像面试现场的总结回答¶

后端安全题最重要的不是攻击技巧，而是安全边界意识。HTTPS 解决的是链路上的机密性、完整性和身份认证问题，但它不替代认证授权、权限控制和业务安全设计；Token 和 JWT 是凭证机制，不等于天然安全；重放、注入、防刷、越权、密钥泄露这些问题都更接近真实后端事故。真正成熟的回答，应该能把“数据在传输、认证、授权、存储、日志和服务间调用链路中分别面临什么风险、对应有哪些基础防护手段”讲清楚。

18. 复习建议¶

至少做到：

能完整说清 HTTPS 的三类核心价值
能区分认证和授权
能解释重放攻击和接口防刷
能说明密码安全存储为什么不能只靠普通哈希
能说清 SQL 注入、XSS、CSRF 的基本防护思路
能理解内部服务安全和最小权限原则

做到这里，网络安全这一章就已经足够覆盖绝大多数后端岗位的基础追问。