文章总结: 本文系统阐述常见Web框架的代码审计方法论,核心思路是通过识别框架类型、理解安全机制、寻找开发者绕过标准写法的差异点来发现漏洞。重点分析ThinkPHP、Laravel、Spring、Django、Flask、Express等主流框架的审计要点,指出原生查询、未过滤输入、禁用安全配置等高风险场景,并提供具体审计工具和正则搜索关键词。文档强调框架审计需聚焦路由文件、中间件配置、数据库操作层等关键位置,实战指导性强。 综合评分: 85 文章分类: 代码审计,WEB安全,安全工具,实战经验,技术标准
代码审计篇——常见框架审计
原创
这小子嘴硬 这小子嘴硬
一己之见安全团队
2026年5月11日 08:48 广西
在小说阅读器读本章
去阅读
前两章我们讲了正则匹配和变量追踪,学会了这两个,原生PHP代码基本能看懂一些了。但是,实际工作中其实很难碰见这类,我最早听到学校老师说的时候也是,实战中基本碰见的都是框架,尤其是现在大家都懒,全部外包出去,那自然用框架的多,成型快、抄作业。
框架这东西吧,成也萧何败也萧何。
一、为什么要单独讲框架审计
框架本身其实不是漏洞的代名词,虽然大家好像手里很多框架的nday,当过家家一样刷着玩,但其实从安全设计角度恰相反,主流框架通常内置了很多安全机制,比如:
- ThinkPHP的
I函数、Laravel的Request会自动过滤输入 - 参数化查询是ORM的默认行为
- CSRF保护、XSS过滤开箱即用
但是——框架的安全机制不是万能的。开发者绕过框架的安全封装、使用原生函数、禁用默认防护,漏洞就出来了。
更重要的是,很多漏洞是框架特有的。比如ThinkPHP的历史RCE漏洞、Shiro的硬编码密钥、FastJson的反序列化。不明白框架机制,根本不知道漏洞在哪儿。
二、框架审计的核心思路
框架审计和原生代码审计,思路不太一样。原生代码的漏洞往往散落在各个文件里,框架项目的漏洞则集中在几个关键位置。
框架审计的三步法:
第一步:认框架
先搞清楚项目用了什么框架、什么版本。不同框架的写法不同,审计重点也不同。
识别方法:
- 看
composer.json(PHP)或package.json(Node.js)里的依赖 - 看目录结构(ThinkPHP有
Application/、Laravel有app/Http/Controllers) - 看配置文件(
.env、config/database.php) - 看HTTP响应头(
X-Powered-By有时会泄露)
第二步:知机制
搞懂这个框架是怎么处理请求的:路由怎么定义?参数怎么获取?数据库操作用什么方法?模板引擎怎么叔出?
第三步:找差异
绝大多数漏洞出现在开发者绕过框架安全机制的地方。
比如框架推荐用$request->input('name')获取参数,但开发者用了$_GET['name']。为什么危险?因为$_GET不会被框架的全局过滤函数处理。
这类“非标准写法”是审计的重点。
三、PHP框架审计要点
3.1 ThinkPHP
ThinkPHP是国内使用最广泛的PHP框架,历史漏洞也不少。
安全机制:
I函数和Request类会对输入进行htmlspecialchars过滤- 数据库操作默认使用参数化查询
- 路由定义控制访问权限
审计要点:
| 关注点 | 原因 | 正则/搜索关键词 |
| — | — | — |
| 直接使用$_GET/$_POST | 绕过框架自带的过滤 | \$_GET 、\$_POST |
| 使用query()、execute()原生查询 | 可能产生SQL注入 | ->query\( 、->execute\( |
| 使用fetchSql获取SQL而不执行 | 信息泄露风险 | fetchSql |
| 控制器未继承基类 | 可能缺少权限校验 | class\s+\w+\s+(implements|extends) |
| 使用Model::where()->select()但未验证输入 | 参数过滤不严 | ->where\( |
重点关注:ThinkPHP 3.2和5.0版本有多个公开RCE漏洞,如果版本较老,优先查已知漏洞是否已修复。
3.2 Laravel
Laravel是目前最流行的PHP框架,安全机制相对完善。
安全机制:
- 通过
Request对象获取参数,自动进行输入过滤 - Eloquent ORM默认使用参数化查询
- Blade模板引擎默认转义输出(
{{ }})防XSS - CSRF令牌默认开启
审计要点:
| 关注点 | 原因 | 正则/搜索关键词 |
| — | — | — |
| 使用DB::select()原生查询 | 绕过ORM防护 | DB::select\( 、DB::statement\( |
| 使用raw()方法 | 产生SQL注入 | ->raw\( 、\braw\( |
| Blade中使用{!! !!} | 不转义,可能产生XSS | \{\!\! |
| 控制器未使用auth中间件 | 权限校验缺失 | 检查路由文件中的middleware |
| 使用env()在非配置文件位置 | 敏感信息泄露风险 | env\( |
Laravel专用审计工具:Checkpoint可以通过一条php artisan checkpoint:scan命令扫描Laravel应用,检查SQL注入、XSS、CSRF、硬编码密钥等。
四、Java框架审计要点
4.1 Spring框架
*重中之重!
Spring是Java最主流的框架,生态庞大,安全机制也相对成熟。
安全机制:
- Spring Security提供认证授权
- 参数绑定自动完成类型转换
- 内置XSS防护
审计要点:
| 关注点 | 原因 | 审计方法 |
| — | — | — |
| @RequestBody 直接绑定对象 | 可能产生Mass Assignment | 检查是否有字段过滤 |
| 使用${}表达式拼接SQL(MyBatis) | SQL注入风险 | 检查mapper.xml |
| SpEL表达式注入 | 用户输入进入表达式求值 | 搜索#{、${在表达式中 |
| 禁用CSRF保护 | 跨站请求伪造风险 | 检查Security配置 |
| @Secured 注解缺失 | 权限校验遗漏 | 检查Controller方法 |
Spring审计时重点关注:配置文件(application.yml、application.properties)中是否关闭了默认安全配置;Interceptor是否对所有需要认证的接口生效。
4.2 常见Java组件审计
Java项目通常依赖大量第三方组件,这些组件自身的漏洞是审计重点。
| 组件 | 常见漏洞 | 审计要点 |
| — | — | — |
| FastJson | 反序列化RCE | 检查JSON.parse()的调用,输入是否可控 |
| Shiro | 硬编码密钥导致RCE | 检查rememberMe密钥是否修改 |
| Log4j2 | JNDI注入(Log4Shell) | 检查版本是否低于2.17.0 |
| Jackson | 反序列化漏洞 | 检查enableDefaultTyping()配置 |
五、Python框架审计要点
Python在Web开发中主要使用Django和Flask。
5.1 Django
安全机制:默认开启CSRF保护、XSS过滤、SQL注入防护(ORM)。
审计要点:
| 关注点 | 原因 | 审计方法 |
| — | — | — |
| 使用extra()或RawSQL | 绕过ORM防护 | 搜索extra\(、RawSQL |
| mark_safe() 的使用 | 禁用自动转义,可能产生XSS | 搜索mark_safe |
| settings.DEBUG = True | 生产环境开启会泄露敏感信息 | 检查配置文件 |
| 使用@csrf_exempt装饰器 | 禁用CSRF保护 | 搜索csrf_exempt |
5.2 Flask(见的比较多)
安全机制:轻量级框架,自带安全机制较少,主要依赖扩展。
审计要点:
| 关注点 | 原因 | 审计方法 |
| — | — | — |
| 使用@app.route但未加认证 | 接口未授权 | 检查路由装饰器 |
| 使用request.args.get()直接拼接SQL | SQL注入 | 变量追踪到数据库操作 |
| 使用render_template_string() | 模板注入风险 | 检查输入是否可控 |
六、Node.js框架审计要点
6.1 Express框架
Express是Node.js最流行的Web框架,生态以轻量级中间件著称。
审计要点:
| 关注点 | 原因 | 审计方法 |
| — | — | — |
| 缺少身份验证中间件 | 接口未授权 | 检查路由定义 |
| 使用req.body直接更新对象 | Mass Assignment | 检查字段过滤 |
| 使用cors()无配置 | 允许任何跨域请求 | 检查CORS配置 |
| 使用eval()或Function() | 代码注入 | 搜索eval\( |
| 使用exec()拼接命令 | 命令注入 | 检查child_process调用 |
Express审计工具:express-sec-audit可以自动扫描Express应用的静态代码,检测SQL注入、命令注入、硬编码密钥等。
七、框架审计的通用思路
不管什么框架,有几个位置是必须看的:
7.1 路由文件
路由文件定义了URL和控制器的映射关系。看路由文件有三个作用:
- 搞清楚系统有哪些入口
- 检查哪些路由没有加权限校验中间件
- 找到隐藏的、未在文档中的接口
7.2 全局中间件/过滤器
中间件是框架统一处理请求的地方。看中间件的配置:
- 全局过滤器/拦截器是否生效
- CSRF保护是否开启
- 认证校验是否遗漏路径
7.3 配置文件
配置文件揭示了系统的运行状态。重点检查:
APP_DEBUG是否开启(调试模式泄露信息)- 数据库密码、API密钥是否硬编码
- 是否使用了不安全的默认配置
7.4 数据库操作层
框架项目的数据库操作,90%以上应该用框架封装的方法。审计时要关注那不到10%的“原生查询”。这类代码通常有明显的特征。
7.5 用户输入获取
不同框架获取参数的方式不同。审计时需要知道哪些方式会经过框架过滤、哪些不会。直接使用原生方法($_GET、request.args.get()通常是最危险的。
八、小结
框架审计和原生代码审计,本质上是一回事——都是追踪用户输入到危险函数的路径。
区别在于:框架是存在所谓的“标准写法”的,审计框架不是看原来有什么,或者说原来长什么样,而是要去找去存在“违和感” 的差异点。
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:一己之见安全团队 这小子嘴硬 这小子嘴硬《代码审计篇——常见框架审计》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论