📚 课程目录第3章安全编码基础

3. 安全编码基础：输入验证、输出编码与最小权限

各位同学，今天咱们聊点实在的。安全编码听起来高大上，说白了就是写代码的时候多留几个心眼。我做了十几年安全，见过太多漏洞其实就栽在几个基础原则上。今天这三个原则——输入验证、输出编码、最小权限——你要是吃透了，至少能防住 80% 的常见攻击。

3.1 输入验证原则

输入验证，顾名思义，就是别信用户给的东西。用户发来的数据，你都得当潜在炸弹处理。我见过最惨的一次，是某电商平台因为没做输入验证，被注入了恶意 SQL，整个用户表被拖走。嗯，那哥们后来被开了。

3.1.1 验证什么

所有外部输入都要验证，包括但不限于：

表单字段（用户名、密码、邮箱等）
URL 参数和路径
HTTP 头（Referer、User-Agent、Cookie）
文件上传内容
API 请求体

3.1.2 怎么验证

我个人习惯用「白名单」策略。什么意思？就是明确告诉系统：只允许这些格式的数据通过，其他一律拦截。黑名单永远防不住变种攻击。

验证类型	白名单示例	黑名单示例（不推荐）
用户名	只允许字母、数字、下划线，长度 3-20	禁止特殊字符（但总有遗漏）
年龄	必须是 0-150 的整数	禁止负数（但可能注入字符串）
邮箱	匹配标准邮箱正则	禁止某些域名（但可以伪造）

核心原则：拒绝所有不符合预期的输入，而不是试图过滤所有恶意输入。

3.1.3 代码示例

看一个简单的 Python 验证例子：

import re

def validate_username(username):
    # 白名单：只允许字母数字下划线，长度3-20
    pattern = r'^[a-zA-Z0-9_]{3,20}$'
    if re.match(pattern, username):
        return True
    return False

# 测试
print(validate_username("admin_123"))  # True
print(validate_username("<script>"))  # False

小技巧：验证最好在服务端做，客户端验证只是用户体验，不能替代安全防线。我曾经见过有人只在前端做验证，结果被直接 curl 请求绕过了。

3.2 输出编码原则

输出编码，说白了就是数据从系统出去的时候，要「穿上防弹衣」。你想想看，用户输入的数据如果原样输出到网页上，那不就是 XSS（跨站脚本攻击）的温床吗？

3.2.1 编码场景

不同上下文需要不同的编码方式：

HTML 上下文：将 < 转成 <，> 转成 >
JavaScript 上下文：转义引号、反斜杠、换行符
URL 上下文：对特殊字符进行 URL 编码
SQL 上下文：使用参数化查询，而不是拼接字符串

3.2.2 常见误区

我记得有一次代码评审，看到有人只对输入做了 HTML 编码，但输出到 JavaScript 变量时没处理。结果攻击者构造了一个 </script> 闭合标签，直接执行了恶意代码。所以，编码要针对输出上下文，不是输入。

警告：不要试图在输入阶段统一编码。输入应该保持原始数据，编码只在输出时按上下文处理。否则数据存到数据库里全是乱码，后续处理会非常痛苦。

3.2.3 代码示例

Java 中的输出编码示例：

import org.owasp.encoder.Encode;

public class SafeOutput {
    public String displayUserInput(String userInput) {
        // HTML 上下文编码
        return Encode.forHtml(userInput);
    }
    
    public String generateJavaScriptVar(String value) {
        // JavaScript 上下文编码
        return "var msg = '" + Encode.forJavaScript(value) + "';";
    }
}

3.3 最小权限原则

最小权限原则，核心思想就是：给够用的权限，不多给一分。我见过太多系统，一个普通用户居然有管理员权限，或者一个只读接口居然能写数据库。这不出事才怪。

3.3.1 应用场景

层面	最小权限示例	常见错误
操作系统	应用进程用非 root 用户运行	直接用 root 跑 Web 服务
数据库	只给 SELECT、INSERT 权限，不给 DROP	用 sa 或 root 账号连接数据库
文件系统	只读目录不给写权限	上传目录有执行权限
API 接口	用户只能访问自己的资源	未做水平权限校验

3.3.2 实践建议

我个人习惯这样落地：

默认拒绝：所有权限默认关闭，按需开放
按角色分配：不同角色有不同权限矩阵
临时提权：需要高权限操作时，临时提升，用完即收回
定期审计：每季度检查一次权限分配，清理僵尸账号

避坑指南：我曾经帮一家金融公司做安全审计，发现他们的备份脚本居然用 root 权限运行。结果攻击者通过一个文件上传漏洞，直接拿到了整个服务器的控制权。如果当时用最小权限，最多只能破坏备份文件，不至于全盘沦陷。

3.4 三者关系

这三个原则不是孤立的，它们互相配合，形成纵深防御：

输入验证是第一道门，挡住恶意数据
输出编码是最后一道墙，防止数据泄露时造成伤害
最小权限是保险丝，即使前两道都失效，也能把损失降到最低

下面这张图能帮你理清思路：

3.5 本章小结

好了，三个原则讲完了。总结一下：

输入验证：用白名单，别信用户
输出编码：按上下文编码，别在输入阶段处理
最小权限：给够用的，不多给

这三个原则看起来简单，但真正落地需要持续的意识培养。我建议你在每次写代码前，先问自己三个问题：这个输入验证了吗？这个输出编码了吗？这个权限给多了吗？养成习惯，安全漏洞自然就少了。