后端代码审计不是“找茬”，而是把应用在攻击者眼里过一遍。很多团队做代码审计时最容易犯的错误是只盯着业务逻辑漏洞，却忽略了语言特性本身带来的安全隐患。不同后端语言在内存管理、类型系统、反序列化机制、模板渲染和数据库交互上的差异，会直接决定漏洞的类型和利用方式。审计要做的第一件事，是明确当前语言最常出现的高危模式，然后沿着数据流从入口到出口逐层排查。

输入验证与类型混淆是动态语言的重灾区

PHP、Python、Node.js这类动态类型语言，最大的问题往往不是语法错误，而是类型在运行时被意外改变。审计时首先要检查所有外部输入是否经过了严格的类型校验。比如PHP中常见的松散比较问题：

if ($_GET['password'] == $stored_password) {
    // 登录成功
}

如果存储的密码是数字0，而攻击者传入字符串“abc”，在PHP 7及更早版本中这种比较可能因类型转换产生意外结果。正确做法是使用恒等比较符“===”并配合hash_equals进行哈希比较。Python的Flask和Django项目中，要检查路由参数是否被直接用于数据库查询或文件路径拼接，尤其是当参数可能为None、空字符串或数组时。Node.js的Express框架中，req.body、req.query、req.params默认都是对象或字符串，但攻击者可以传入嵌套对象或数组，如果后端直接将其传入MongoDB查询，就可能触发NoSQL注入。

反序列化漏洞比SQL注入更隐蔽

Java、PHP、Python和Node.js都广泛使用序列化来传递对象状态。审计时凡是看到unserialize、json.loads配合自定义解码器、ObjectInputStream、pickle.loads、node-serialize等函数，都要高度警惕。Java的反序列化漏洞尤其危险，因为攻击者可以通过构造恶意对象链触发任意代码执行。审计Java应用时，要检查所有readObject方法是否对输入来源做了白名单校验，是否使用了SerialKiller或ObjectInputFilter来限制可反序列化的类。PHP的unserialize如果接收用户可控数据，攻击者可以借助已有类中的魔术方法如__destruct、__wakeup构造POP链。Python的pickle模块官方文档明确警告不要对不可信数据使用，但很多项目仍将其用于缓存或会话存储。审计时如果发现pickle.loads的输入来自Cookie或请求参数，必须立即标记为严重漏洞。

SQL注入的变种：ORM和查询构建器并非绝对安全

很多人认为使用ORM就可以完全避免SQL注入，这是错误的。审计时要重点检查ORM中是否使用了原生SQL拼接、字符串格式化或动态排序字段。例如在Django中：

User.objects.raw("SELECT * FROM users WHERE name = '%s'" % username)

这种写法依然存在注入风险。更隐蔽的是动态order_by和group_by，很多ORM允许传入字段名字符串，如果该字符串来自前端且未做白名单校验，攻击者可以构造报错注入或时间盲注。在Java的MyBatis中，要检查XML映射文件里的${}和#{}使用情况，${}是字符串替换，存在注入风险，而#{}是预编译占位符。Node.js的Sequelize中，要检查where条件是否使用了Op.like配合用户输入，以及attributes和order参数是否允许任意字符串。

命令执行与文件操作中的路径穿越

后端语言经常需要调用系统命令处理文件转换、图片压缩或备份任务。审计时要检查所有exec、system、popen、subprocess、child_process等函数的参数是否包含用户输入。即使参数经过过滤，也要确认过滤是否可绕过。例如PHP中escapeshellcmd和escapeshellarg的配合使用顺序不当，仍可能被绕过。Python的subprocess如果使用shell=True且参数未做处理，风险极高。Node.js的child_process.exec与execSync同样存在命令拼接问题。文件操作方面，要检查文件读取、写入、删除、重命名功能是否对路径做了规范化处理。攻击者常用../进行目录穿越，或者使用绝对路径读取敏感文件。审计时要确认代码是否使用path.resolve、realpath或白名单目录限制，并且要检查Windows和Linux路径分隔符差异是否被正确处理。

模板注入与XSS的根源在于输出编码缺失

服务端模板注入在Python的Jinja2、Java的FreeMarker和Velocity、PHP的Smarty中都有出现。审计时要检查模板中是否直接渲染了用户输入，尤其是当模板字符串本身由用户控制时。例如Jinja2中如果render_template_string的参数包含用户输入，攻击者可以注入{{ config }}或{{ 7*7 }}来探测模板引擎环境。即使模板文件固定，也要检查变量输出时是否使用了自动转义。很多框架默认开启自动转义，但开发者可能使用safe过滤器或| raw标记关闭转义，这就为XSS打开了口子。审计时要搜索所有关闭转义的地方，确认输出内容是否经过白名单清洗。对于API返回JSON的场景，要检查Content-Type是否设置为application/json，避免浏览器将JSON当作HTML解析导致XSS。

身份认证与会话管理中的薄弱环节

审计后端代码时，登录、注册、密码重置、令牌刷新这些功能必须逐行检查。常见问题包括：密码使用弱哈希算法如MD5或SHA1且未加盐；JWT令牌使用弱密钥或未验证签名算法；会话ID在URL中传递；密码重置令牌可预测或未设置过期时间；API密钥硬编码在源码中。JWT审计要特别注意alg字段是否允许none，以及是否使用RS256但公钥可被替换为攻击者自己的密钥。在Node.js的jsonwebtoken库中，要检查verify方法是否明确指定了算法。在Java的Spring Security中，要检查是否禁用了CSRF保护但同时又使用了Cookie会话。对于多租户系统，还要检查每个查询是否都带上了租户ID过滤条件，防止越权访问。

日志与错误处理中的信息泄露

很多后端应用在调试模式下会输出详细的堆栈信息、数据库表结构、框架版本和文件路径。审计时要检查生产环境的错误处理中间件是否统一捕获异常并返回通用错误信息。PHP中要确认display_errors是否关闭，Python的Flask要检查DEBUG模式是否在生产环境被误开，Node.js的Express要检查错误处理中间件是否将err.stack直接返回给客户端。日志方面，要检查是否记录了敏感信息如密码、令牌、身份证号、银行卡号。日志注入也是一个容易被忽视的问题，攻击者可以在用户输入中插入换行符伪造日志记录，审计时要确认日志输出前是否对换行符做了过滤。

依赖与配置中的安全盲区

代码审计不能只看业务代码，还要检查依赖库版本和配置文件。很多漏洞并非来自开发者自己写的代码，而是来自过时的第三方库。审计时要生成依赖清单，对比已知漏洞数据库，重点检查那些被广泛使用的库如fastjson、log4j、lodash、requests、urllib3等。配置文件方面，要检查数据库连接字符串、Redis密码、消息队列凭证是否硬编码在配置文件中，配置文件是否被正确排除在版本控制之外。对于微服务架构，还要检查服务间通信是否启用了TLS，内部API是否暴露在公网，以及Docker镜像中是否包含不必要的调试工具。

并发与竞态条件导致的逻辑漏洞

后端代码在并发场景下可能出现数据不一致或权限绕过。审计时要关注那些先检查后操作的逻辑，例如先检查用户余额是否足够再扣款，如果两个请求同时到达，可能都通过检查然后重复扣款。在数据库中，这类问题需要依靠事务隔离级别或行级锁来解决。文件上传功能中，要检查文件名是否使用时间戳加随机数生成，避免并发上传时文件名冲突导致文件覆盖。在Node.js中，要特别注意异步回调中的变量作用域问题，循环中使用var声明变量可能导致闭包捕获错误的变量值。

代码审计的落地方法：从数据流到危险函数

实际审计时，不要从第一行代码顺序往下看，而是先画出数据流图。标记所有外部输入入口，包括HTTP参数、请求头、Cookie、文件上传、消息队列消息、Webhook回调。然后追踪这些数据经过哪些函数处理，最终到达哪些危险操作。危险操作包括数据库查询、文件读写、命令执行、模板渲染、反序列化、URL跳转、日志写入。对于每个危险操作，检查数据在到达前是否经过了充分的校验、过滤和编码。这种方法比盲目搜索危险函数更有效，因为很多漏洞是多个看似安全的步骤组合而成的。审计完成后，要按严重程度分级输出报告，每个漏洞都要给出复现步骤和修复建议，而不是只列出一堆代码位置。