后端安全防护：常见攻击与防御措施

在互联网应用日益复杂的今天，后端服务已成为攻击者的主要目标。作为开发者，理解常见攻击手段并掌握核心防御策略，是从源头保障系统安全的关键。本教程将系统梳理后端面临的主要安全威胁，并提供可落地的防御方案，适合后端初学者建立完整的安全知识框架。

一、注入类攻击（Injection）

注入攻击的本质是将不受信任的数据作为命令或查询的一部分发送给解释器，导致解释器执行了非预期的操作。

1. SQL 注入（SQLi）

攻击者通过在输入字段中插入恶意的 SQL 片段，操纵后端数据库查询，可能导致数据泄露、篡改甚至服务器被控制。

常见攻击场景：

• 登录绕过：' OR '1'='1' --
• 联合查询注入：利用 UNION SELECT 获取其他表数据
• 盲注：通过布尔或时间延迟推断数据库结构

防御措施：

• 使用参数化查询（预编译语句）：无论是 JDBC 的 PreparedStatement、Go 的 database/sql 占位符，还是 ORM 框架，都应确保 SQL 语句的结构与数据严格分离，绝不通过字符串拼接构建查询。
• 存储过程：虽然也能实现参数化，但仍需注意在存储过程内部避免动态拼接。
• 输入校验与白名单：对数字、日期等固定格式的参数进行严格类型校验；对于字符串类参数，可限定字符集和长度。
• 最小权限原则：应用连接数据库的账户只授予必要的 SELECT、INSERT 等权限，禁止 DROP、FILE 等高危权限。
• 错误信息脱敏：生产环境禁止向前端返回数据库原始错误，使用自定义通用错误页面。

2. 命令注入（Command Injection）

当应用通过系统调用来执行外部命令，并拼接了用户输入时，攻击者可以注入额外命令。例如 ; rm -rf / 或 | cat /etc/passwd。

防御措施：

• 尽量避免在应用代码中调用系统命令。如果无法避免，使用语言提供的安全函数如 exec.Command 并单独传递参数，不要使用 shell 模式拼接。
• 对允许执行的命令建立白名单，严格限制可执行的程序。
• 对输入进行严格过滤，移除或转义命令连接符（&&, ||, ;, | 等）。

3. LDAP 注入、XML 注入等

原理类似，都需对传递给解释器的数据进行净化。统一防御思路：参数化、转义特定语法、严格结构化输入。

二、跨站脚本攻击（XSS）与后端关联

虽然 XSS 通常表现为前端漏洞，但后端若未对存储或反射的内容进行处理，往往会成为 XSS 的源头。

后端防御重点：

• 输出编码：所有用户生成内容在输出到 HTML 页面时，必须根据上下文进行转义（HTML 实体编码、JavaScript 编码、URL 编码等）。
• 内容安全策略（CSP）：后端通过响应头 Content-Security-Policy 强制浏览器限制可执行的脚本来源、样式来源等，即使页面被注入恶意脚本也难以执行。
• HttpOnly 标记：将会话 Cookie 标记为 HttpOnly，使 JavaScript 无法读取，减少 XSS 窃取会话的可能。
• 输入验证：虽非核心 XSS 防御（因攻击可能绕过），但仍需对输入做结构、格式、长度验证，可作为第一道防线。

三、跨站请求伪造（CSRF）

攻击者诱导用户点击恶意链接或加载恶意页面，利用用户已登录的身份在目标站点上执行非本意的操作（如转账、改密）。

防御措施：

• 反 CSRF 令牌：后端在每个需要保护的表单中生成唯一、不可预测的令牌，并在提交时验证。令牌应与会话绑定，并设置有效期。
• SameSite Cookie 属性：将关键 Cookie 设置为 SameSite=Strict 或 SameSite=Lax，现代浏览器会阻止跨站请求携带该 Cookie。
• 验证 Referer / Origin 头：服务端校验请求来源是否被允许，但注意此头可能被篡改或缺失，不能作为唯一防御手段。
• 使用自定义请求头：对于 AJAX 请求，要求附带自定义头（如 X-Requested-With），简单跨域请求无法添加自定义头，可防御基本 CSRF。

四、服务端请求伪造（SSRF）

攻击者利用存在漏洞的 Web 应用作为代理，向内部网络发起请求，从而获取内网服务信息、云元数据，甚至实施远程代码执行。

常见攻击目标：

• 云环境的元数据接口（http://169.254.169.254/）
• 内部管理后台、数据库、Redis 等未授权服务
• 本地文件协议（file:///etc/passwd）

防御措施：

• URL 白名单与域名校验：严格限制可请求的协议（仅 HTTP/HTTPS）、域名和端口。禁止用户直接传入完整 URL 时，先解析域名，确保不在内网 IP 段内。
• 禁用危险协议：如 file://, gopher://, dict:// 等。
• 内网 IP 黑名单过滤：在 DNS 解析后再次检查 IP 是否为内网地址（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 等）。
• 网络隔离：将发起请求的服务放置于受限网络区域，本身无内网权限，从架构上切断风险。

五、认证与会话管理漏洞

认证与会话管理缺陷常年位居 OWASP Top 10 前列，直接影响账户安全。

常见问题与防御：

• 弱密码与暴力破解：实施强密码策略，限制登录尝试频率（账户锁定或验证码），应用多因素认证。
• 凭证存储：密码必须使用强哈希加盐存储（bcrypt, argon2），绝不明文保存或使用简单哈希如 MD5。
• 会话固定：用户登录成功后必须重新生成会话 ID，避免攻击者预先设置一个会话 ID 诱导用户登录。
• 会话超时与安全退出：设置合理的会话过期时间，提供有效的登出接口并销毁服务端会话数据。
• Cookie 安全属性：后端设置 Cookie 时必须添加 Secure（仅 HTTPS 传输）、HttpOnly 和 SameSite 属性。
• JWT 安全：如使用 JWT，应选用强算法（RS256/ES256），密钥严格保管，令牌有效期短，并实现失效机制（黑名单或版本号）。

六、文件上传漏洞

不受控的文件上传可导致服务器被植入 WebShell、恶意脚本被执行或存储型 XSS。

防御措施：

• 类型白名单检查：验证文件扩展名和 MIME 类型，但注意两者都可被伪造。真正安全的方法是检查文件的魔术字节。
• 文件内容扫描：对上传文件进行杀毒扫描或内容验证（如图片文件必须可被解析）。
• 存储路径与权限：将文件存放在非 Web 可执行目录，或通过专门的文件服务独立域名、无执行权限。
• 文件名重命名：使用 UUID 或时间戳加随机串生成文件名，防止路径遍历和保留恶意扩展名。
• 限制文件大小：防止拒绝服务攻击。

七、接口与数据安全

1. 不安全的直接对象引用（IDOR）

攻击者通过修改请求中的对象 ID 等参数，访问或修改不属于自己的资源。

防御：

• 服务端必须每次请求都进行权限校验，根据当前登录用户判断是否有权操作该对象。
• 使用不可预测的标识符（如 UUID）替代自增数字 ID，增加猜测难度，但这仅是安全隐匿，不能替代权限检查。

2. 批量分配（Mass Assignment）

攻击者通过请求中额外的字段去修改原本不应被修改的属性（例如通过注册接口传入 role=admin）。

防御：

• 后端接收数据时，明确列出允许接收的字段（白名单绑定），忽略未声明的字段。
• 永远不要直接将请求参数映射到数据模型并保存，应使用 DTO（数据传输对象）结合字段过滤。

3. 敏感数据暴露

包括通过 API 返回了过多字段（如密码哈希、内部备注）、日志中记录了敏感信息、错误消息泄露堆栈信息等。

防御：

• 对 API 响应进行数据过滤，仅返回业务所需字段。
• 对所有传输的敏感数据（密码、令牌、个人信息）使用 HTTPS 加密，最好结合 HSTS 头强制加密。
• 日志脱敏，避免记录原始请求体中的认证凭证。
• 生产环境关闭调试模式和详细错误输出。

八、基础设施与配置加固

1. 依赖与组件漏洞

使用过时的框架、库或中间件带有已知漏洞。必须建立持续依赖巡检流程，使用 SCA 工具（如 OWASP Dependency-Check）自动扫描，并及时修补。

2. 不当的跨域资源共享（CORS）

如果 CORS 配置为 Access-Control-Allow-Origin: * 且允许携带凭证，或反射来源未严格校验，则可能导致跨域攻击和数据窃取。

防御：

• 明确允许的源（白名单），不要使用 * 如果请求涉及凭证。
• 仔细审查 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，避免过度放宽。
• 验证 Origin 头的值必须完全匹配，而不是简单的包含反射。

3. 安全头配置

后端应统一设置关键安全响应头，创建坚实的外围防线：

• Strict-Transport-Security: 强制 HTTPS。
• X-Content-Type-Options: nosniff: 防止 MIME 类型嗅探。
• X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none': 防止点击劫持。
• X-XSS-Protection: 0（已废弃，现代浏览器依靠 CSP）。
• Referrer-Policy: 控制 Referer 传递的敏感程度。

4. 日志与监控

安全不仅是预防，还包括侦测与响应。应当记录所有关键操作（登录、权限变更、敏感数据访问），并对异常模式（如高频 403 错误、大量来自同一 IP 的失败登录）设置告警。确保日志本身受到保护，不被注入或覆盖。

总结

后端安全防护是一项系统工程，需要贯穿设计、编码、测试和运维的全生命周期。核心原则可以浓缩为以下几条：

• 永远不信任用户输入，一切输入在服务端进行严格验证、过滤和编码。
• 最小权限原则，不论是数据库账号、系统调用还是文件权限。
• 纵深防御，不依赖单一机制，组合使用验证、编码、防火墙、安全头和监控。
• 定期更新与审计，保持依赖项最新，进行安全代码审查和渗透测试。

将这些措施内化为团队开发规范，你就能构建出更加健壮的后端系统，有效抵御大多数已知的攻击手段。