ASP.NET代码审计做到SQL注入这一块，很多人是从“找单引号”开始的。但做过几个真实项目之后你会发现，单引号只是最表面的一层。尤其是面对ASP.NET WebForms、MVC、Web API混着来的老项目，真正耗时间的不是“找漏洞”，而是从几百个页面、几千个方法里把值得看的那几条数据流挑出来。这篇是SQL注入审计的第2篇，会直接跳过“什么是注入”这种基础概念，重点聊聊ASP.NET场景下那些容易漏掉的注入形态、参数化查询的盲区、审计时的搜索策略，以及几个我实际跟过的漏洞案例。适合已经懂SQL注入基本原理、开始上手做代码审计或想把自己系统的安全问题搞清楚的朋友。
1. 别只盯着单引号：ASP.NET环境下的高发注入形态
1.1 数字型参数：最容易被忽略的入口
很多做审计的人有个惯性：先搜字符串拼接，看到'+变量+'才觉得是注入点。但ASP.NET项目里最常见的漏洞入口其实是数字型参数，它根本没有单引号。
看这类代码：
int year = Convert.ToInt32(Request.QueryString["year"]); string sql = "SELECT * FROM Orders WHERE Year(OrderDate) = " + year;或者更隐蔽的：
string id = Request.QueryString["id"]; if (Regex.IsMatch(id, @"^\d+$")) { string sql = "SELECT * FROM Product WHERE ProductID = " + id; }第2个例子表面上有校验，但如果你把id的值传成1; DELETE FROM Orders--，这串字符根本不满足^\d+$，所以正则校验其实挡住了。真正的问题往往出在“看起来做了校验，实际上没覆盖到所有使用点”这种情况。比如同一个参数同时被两个页面使用，一个页面做了校验，另一个页面忘了。
数字型注入的审计关键是看变量从哪来、经过了什么处理、最终拼到哪。不要因为“它是数字”就放松警惕。很多时候Convert.ToInt32确实能挡掉非数字输入，但Request["id"]拿到的是字符串，只要中间有一步没有走强转换，而是直接拼接，漏洞就出来了。
我见过一个更绕的情况：开发人员在校验时用的是int.TryParse，但解析失败后没有return，而是让变量保留成默认值0，执行流继续往下走。这种情况下参数值虽然没被解析成目标类型，但原始字符串其实已经存在另一个变量里了，后面拼接用的还是原始字符串。这种代码逻辑上的小裂缝，静态扫描工具通常报不出来，只能靠人眼跟踪数据流。
1.2 编码与变换：两层解码造成的漏网之鱼
ASP.NET管线里，Request对象本身会做一次URL解码。但如果项目里手动调用了Server.UrlDecode、HttpUtility.HtmlDecode，或者用了自定义的加密解密、Base64、十六进制转换，就可能出现二次解码的问题。
举个实际例子。某个导出功能为了让参数在URL里更“美观”，前端把筛选条件做了一次Base64编码，后端拿到后解码再拼SQL：
string condition = Request.QueryString["filter"]; string decoded = Encoding.UTF8.GetString(Convert.FromBase64String(condition)); string sql = "SELECT * FROM Orders WHERE " + decoded;这种情况下，你在URL里传的filter是Base64之后的内容，看起来完全是一堆字母和数字，没有单引号、没有分号，很容易骗过粗放的关键字排查。但解码之后就变成了完整的拼接条件。审计的时候如果只搜SELECT、WHERE这些关键词，根本发现不了问题。
还有一种编码问题在老的WebForms项目里比较常见：页面用了ValidateRequest="false"，然后自己又做了HTML解码再拼SQL。ValidateRequest关闭之后，请求里的<script>、'等字符可以原样进入后端，如果后面又做了解码，原本被编码过的注入特征会被还原出来。审计这种代码时要特别留意“关闭了框架自带的防护”这个信号，同时再看有没有自定义的解码逻辑。
比较稳妥的审计习惯是：每到一个处理用户输入的方法，先列出这个输入经过了哪几层变换，画一条简单的数据流线，再判断最终落点。只盯着最终拼接的那一行，很容易漏掉中间的编解码环节。
1.3 存储过程内部：注入点藏在了SQL代码里
ASP.NET项目还有一个非常典型的情况：C#代码里用的是参数化调用SqlCommand，看着一点问题都没有，但漏洞藏在了存储过程内部的动态SQL里。这类问题在审计时最难发现，因为搜索C#代码根本找不到拼接点。
结构大概是这样的：
CREATE PROCEDURE GetOrders @OrderStatus NVARCHAR(50), @SortColumn NVARCHAR(50) AS BEGIN DECLARE @sql NVARCHAR(MAX); SET @sql = N'SELECT * FROM Orders WHERE Status = @Status'; IF @SortColumn IS NOT NULL SET @sql = @sql + N' ORDER BY ' + @SortColumn; EXEC sp_executesql @sql, N'@Status NVARCHAR(50)', @Status = @OrderStatus; END这里@OrderStatus是通过参数传入的，这部分是安全的。但@SortColumn直接拼进了SQL字符串。C#侧的调用代码如果写成：
cmd.Parameters.AddWithValue("@OrderStatus", status); cmd.Parameters.AddWithValue("@SortColumn", sortColumn);那么sortColumn传成Id; DROP TABLE Orders--之类的值时，存储过程里拼出来的SQL就成了ORDER BY Id; DROP TABLE Orders--，虽然sp_executesql里定义了@Status参数，但@SortColumn这一部分依然被执行了动态拼接。
这类问题的审计思路不能停在应用层代码。看到一个存储过程调用时，要顺藤摸瓜去看存储过程的定义。特别是存储过程里出现sp_executesql、EXEC、EXECUTE，且周围有字符串相加的情况，基本上都要拉出来细看。相关的审计检索词后面会专门列出来。
2. 参数化查询不是免死金牌
2.1 表名、列名仍然要拼接
很多人会形成一种思维定势：只要用了参数化查询就安全了。这在“值”的注入场景下是对的，但是SQL语句里有些位置是参数化覆盖不到的——表名、列名、排序方向、动态透视列。这些位置的共同特点是：它们必须是SQL语句结构的一部分，不能简单替换成@param。
看这段代码：
string table = Request.QueryString["table"]; string sql = "SELECT * FROM " + table + " WHERE ID = @id"; SqlCommand cmd = new SqlCommand(sql, conn); cmd.Parameters.AddWithValue("@id", id);@id是参数化的，但table直接拼进去。如果你传table为Orders; UPDATE Users SET IsAdmin = 1--，拼接结果就变成了：
SELECT * FROM Orders; UPDATE Users SET IsAdmin = 1-- WHERE ID = @id参数化只保护了@id那部分，对表名拼接无能为力。
审计这类代码时，要格外关注那些“前端可以影响表名/列名”的设计。比如后台系统提供“自定义导出字段”的功能，用户勾选要导出的列，前端把列名列表传回后端，后端直接拼接。这种功能简直是注入漏洞的天然温床。
2.2 ORDER BY排序注入的审计思路
排序注入和列名拼接是近亲。很多列表页为了支持点击列头排序，会把排序字段名直接拼到SQL里：
string sort = Request.QueryString["sort"]; string sql = "SELECT * FROM Products ORDER BY " + sort;看起来sort的取值应该来自前端固定的几个选项，但HTTP请求完全可以绕过前端下拉框，直接提交任意字符串。如果后端没有对sort做白名单校验，拼进去就是一个注入点。
审计时看到ORDER BY后面接变量，不要急着下结论说“只能排序不能注”。在SQL Server里，ORDER BY后面可以跟表达式，某些情况下还能配合CASE WHEN做条件判断，从而逐字符猜解数据。虽然利用条件比常规注入苛刻，但一旦成立，危害并不小。
我在实际项目里还遇到过一种变体：排序字段名本身放在一个隐藏字段HiddenField里，开发人员认为“用户看不到就不算用户输入”。但在WebForms里，Request.Form可以直接伪造隐藏字段的值，等于这个参数依然可控。这个认知误区要特别提醒一下。
2.3 模糊搜索LIKE与转义处理
模糊搜索是SQL注入审计里一个非常常见的“半安全”场景。
string keyword = Request.QueryString["kw"]; string sql = "SELECT * FROM News WHERE Title LIKE '%' + @kw + '%'"; cmd.Parameters.AddWithValue("@kw", keyword);这段代码参数化了，安全方面没什么大问题。但有些项目为了保证查询性能，会写成：
string kw = Request.QueryString["kw"].Replace("'", "''"); string sql = "SELECT * FROM News WHERE Title LIKE '%" + kw + "%'";开发者的思路是：把单引号替换成两个单引号，就能防止注入。这个思路在SQL Server的字符串字面量里的确能挡住一部分注入，但有一个致命的问题：如果输入包含了反斜杠或者项目用了ESCAPE子句，替换规则就不一定可靠。更常见的问题是，替换发生在拼接之前，但数据在数据库里经过了一次函数运算，比如LTRIM、RTRIM、REPLACE嵌套，原始输入可能在别的路径上被还原。
审计建议是：看到手写单引号转义的代码，先标记为“可疑”，然后确认这个变量是否只在这一处使用，有没有其他路径绕过转义。如果项目里同时用了HtmlEncode和SQL转义，还要考虑转义顺序是否一致，否则会出现双重编码或绕过问题。
2.4 Entity Framework的误用场景
现在的ASP.NET项目很多用Entity Framework或其它ORM，直接手写SQL的情况少了，但这不代表注入消失了。EF的FromSqlRaw、ExecuteSqlRaw、SqlQuery这些接口，就是参数化时代的“半裸奔”地带。
var data = db.Products .FromSqlRaw("SELECT * FROM Products WHERE CategoryId = " + categoryId) .ToList();FromSqlRaw就是说这段SQL按原始字符串执行，不做任何参数化处理。categoryId如果是用户可控的，这就是一个完整注入点。
EF还有一个容易被忽略的点：FromSqlInterpolated看起来像参数化，但如果字符串格式化部分的某个参数实际是字符串拼接出来的，那还是有风险。比如：
var sql = $"SELECT * FROM Products WHERE Name = '{keyword}'"; var data = db.Products.FromSqlRaw(sql).ToList();这段代码用了C#的字符串插值，看起来好像比传统的+拼接“现代”一点，但本质还是字符串拼接。EF并不会因为你用了插值语法就自动参数化，它会原样执行sql里的内容。
所以审计EF项目时，搜索范围要覆盖FromSqlRaw、ExecuteSqlRaw、SqlQuery、Database.ExecuteSqlCommand这些API，同时还要确认FromSqlInterpolated的格式化参数里面有没有二次拼接。很多新项目漏洞率低，不是开发人员安全意识好，而是EF封装程度高、手写SQL少，一旦出现手写SQL的位置，反而容易因为“少见”而被忽略。
3. 审计入手点：从请求入口追踪数据流
3.1 Source-Sink检索顺序
代码审计的大方向是找到“输入源”和“危险函数”之间的通路。在ASP.NET里，输入源主要围绕Request对象的几个属性：QueryString、Form、Cookies、ServerVariables、Headers。危险函数(也叫sink)则集中在SQL执行相关的调用上。
我习惯先列sink，再反推source。因为source数量太多，几千个页面每个都有参数，从source开始找效率太低。先把所有调用SQL执行的位置列出来，再逐个往回追数据流，这样排查范围能缩小很多。
一个相对完整的sink清单包括：
SqlCommand的CommandText赋值为变量SqlCommand构造函数的第一个参数为变量CommandType.Text且CommandText包含拼接ExecuteNonQuery、ExecuteReader、ExecuteScalar、ExecuteXmlReader前面跟着拼接SQLFromSqlRaw、ExecuteSqlRaw系列- 存储过程定义里的
sp_executesql、EXEC字符串拼接 DataAdapter的SelectCommand设置为拼接字符串SqlDataSource的SelectCommand属性来自控件属性或Request参数
拿到这个清单后，对每一项做数据流回溯，只关心那些最终能追溯到Request、Cookie、Form或者数据库存储值再回流的变量。这个过程比较费时间，但基本不会漏掉明显的问题。
3.2 常用检索特征词整理
在Visual Studio或代码搜索工具里，常用的检索模式大概有这些：
"SELECT " + "SELECT * FROM " "SELECT COUNT" "SELECT TOP" "WHERE " + "ORDER BY " + "LIKE '%" + " + Request" " + txt" " + tb" " + Hidden" CommandText = FromSqlRaw( ExecuteSqlRaw( sp_executesql EXEC(搜索+ Request这个模式非常有用，因为很多拼接SQL的代码会把Request对象直接或间接拼进字符串。但注意一下，直接拼Request的情况在新增代码里少了，更多的是先把值存到变量里再拼。所以第二层搜索可以跟+ 变量名配合，把变量的赋值语句拉出来看。
还有一个小技巧：搜索.Text属性作为SQL拼接源的代码。WebForms项目里TextBox.Text、HiddenField.Value、DropDownList.SelectedValue都是常见输入源，搜sql +或+ "这样的模式时，如果同时出现.Text或.Value，基本就可以标红了。
3.3 如何快速缩小排查范围
一个中型ASP.NET项目可能有几百个aspx页面、几十个处理程序，全量审计不现实。我一般按以下几个优先级排序：
- 管理后台优先于前台页面。后台功能通常操作核心业务表，注入后造成的影响更大。
- 导出、报表、统计类功能优先。这些功能经常拼复杂SQL，且表单参数多、逻辑复杂，容易出问题。
- 搜索、筛选、排序类功能次之。
LIKE、ORDER BY、多条件组合这些位置是拼接重灾区。 - 自定义字段、动态表单、模板配置类功能也要仔细看。凡是要“动态适应业务变化”的代码，十有八九会走拼接。
实际操作中，我习惯先用一个简单的脚本把所有aspx/cs文件里的sink关键词统计一遍，按文件出现次数排序，然后从高频文件开始人工审计。这个方法不能替代完整审计，但能在资源有限的情况下先把最危险的文件筛出来。
4. 典型漏洞案例复盘
4.1 案例一：后台导出模块的列名拼接
某个模拟项目的后台有一个“订单导出”功能，管理员可以选择导出哪些字段，前端通过复选框把字段名数组POST到后端。后端代码大致如下：
string[] fields = Request.Form.GetValues("fields"); string fieldList = string.Join(",", fields); string sql = "SELECT " + fieldList + " FROM Orders WHERE OrderDate BETWEEN @start AND @end"; SqlCommand cmd = new SqlCommand(sql, conn); cmd.Parameters.AddWithValue("@start", startDate); cmd.Parameters.AddWithValue("@end", endDate);日期范围是参数化的，但字段列表是前端控制的。审计时我先看到了string.Join和fieldList的拼接，然后追到Request.Form.GetValues，确认完全可控。
这里要说明一个问题：有些开发人员会觉得字段名选择是前端固定好的，可以通过checked属性限制。但HTTP请求本身可以随便构造，前端限制只影响用户正常操作，影响不了恶意请求。所以审计时千万不要因为“前端的控件限制了选项”就认为后端安全。
修复方式是对字段名做白名单映射。后端维护一个字典，把允许导出的字段名列出来，前端传上来的字符先查字典，查不到就丢弃或返回错误，而不是直接拼进SQL。这个方案能同时解决“非法字段名”和“SQL注入”两个问题。
4.2 案例二：存储过程内动态拼接引发的漏洞
另一个模拟项目里，业务逻辑大量使用存储过程。应用层代码调用存储过程时全部走参数，看起来非常规范。有一个存储过程用于查询客户列表，支持按不同状态筛选，同时支持排序。关键代码是这样的：
CREATE PROCEDURE usp_SearchCustomer @Status INT = NULL, @OrderColumn NVARCHAR(50) = 'CustomerId' AS BEGIN DECLARE @sql NVARCHAR(MAX); SET @sql = N'SELECT CustomerId, CustomerName, Status FROM Customer WHERE 1=1'; IF @Status IS NOT NULL SET @sql = @sql + N' AND Status = ' + CAST(@Status AS NVARCHAR(10)); SET @sql = @sql + N' ORDER BY ' + @OrderColumn; EXEC sp_executesql @sql; END这里有两个问题值得说。@Status先被CAST成字符串再拼接，表面上有类型转换保护。但如果调用方传入一个超长的@Status，CAST就能截断？不，这个细节要看数据库的截断规则。更重要的问题是@OrderColumn直接拼接进SQL，调用方传CustomerId; DROP TABLE Customer--就会变成两段SQL。
审计这类存储过程的思路是打开SQL Server Management Studio，搜索所有CREATE PROCEDURE包含sp_executesql或者EXEC的对象，然后逐个看字符串拼接位置。搜索SQL语句可以这样写：
SELECT DISTINCT o.name AS procedure_name FROM sys.sql_modules m JOIN sys.objects o ON m.object_id = o.object_id WHERE m.definition LIKE '%sp_executesql%' OR m.definition LIKE '%EXECUTE%' OR m.definition LIKE '%EXEC %'拿到存储过程清单之后，优先检查definition里的字符串拼接模式。存储过程内部的参数如果直接拼进动态SQL，和C#里拼接没有本质区别，唯一的差别是审计难度更大——因为调用方看起来是参数化调用的。
修复方案是把所有值都走sp_executesql的参数列表，包括@Status和@OrderColumn。但排序字段这个问题比较特殊，排序字段名即便参数化也不能直接传，因为SQL Server不允许参数化表名、列名。稳妥做法是为排序字段单独建一个白名单字典，排序方向也用ASC/DESC的枚举判断，而不是直接拼接。
4.3 案例三：查询参数被二次解码利用
第三个案例来自一个模拟的新闻系统，搜索功能接受了keyword参数。为了支持各种编码环境，开发人员在Global.asax的Application_BeginRequest里加了统一解码逻辑，把Request.QueryString里的值先做一次UrlDecode。然后搜索功能里又做了一次Server.HtmlDecode。
问题发生在两层解码中间。搜索功能的代码大概是这样：
string keyword = Request.QueryString["keyword"]; keyword = Server.HtmlDecode(keyword); string sql = "SELECT * FROM News WHERE Title LIKE '%' + @kw + '%'"; cmd.Parameters.AddWithValue("@kw", keyword);这看起来是参数化的，但中间多了一步HtmlDecode。如果参数化值在进入SQL Server之前经过了HtmlDecode，理论上不会造成注入，因为参数化不影响字符串内容。但存在一种利用思路是：让参数值里包含某种编码形式，经过两层解码后变成有特殊含义的SQL片段。虽然参数化不会让这个片段“执行”，但在某些数据库的隐式转换场景下，还是会触发非预期的行为。比如特定字符集下，宽字节注入的变体就可能绕过参数化。这里不展开具体利用方法，但审计时要记住一个原则：变量在进入SQL之前经过了额外的编码解码环节，就需要确认这个环节不会改变SQL语句的边界判定。
后来这个漏洞的修复是删除多余的二次解码，统一在框架层面完成一次标准解码，业务层直接使用Request.QueryString的结果，不再自行HtmlDecode。审计结论也提示了同类问题：项目里如果存在多个解码点，必须理清调用顺序，否则就会出现边界判定不一致的情况。
5. 修复与加固：补丁之外的系统思考
5.1 输入验证用白名单，不用黑名单
很多团队在修复SQL注入时会采用“过滤危险字符”的思路：拦截'、--、;、xp_cmdshell这些关键字。这个方案在对抗已知攻击模式时有效，但维护成本极高，而且总有未知绕过方式。
黑名单最大的问题是“默认信任”。只要输入里没出现已知的危险字符，就放行。这等于把安全判断建立在一份永远写不全的黑名单上。白名单的思路反过来：明确允许的范围（比如只允许数字、只允许字母、只允许特定枚举值），凡是超出范围的直接拒绝或丢弃。
对于SQL注入审计后的修复，我一般建议三步走：
- 对值的部分，一律使用参数化查询。能走参数不要拼接，这是最基础的一层。
- 对无法参数化的部分（表名、列名、排序），用白名单映射。前端传任何字符串都不直接拼，而是通过字典映射到固定的合法值。
- 对用户输入做长度、类型、范围的校验，越早拦截越好。校验放在DTO层或模型绑定阶段，可以减少后续业务逻辑里出现意外状态的机率。
这三步按顺序做完，即使中间有遗漏，攻击者能利用的空间也会大幅缩小。
5.2 数据库账户权限收缩
SQL注入审计不能只盯着代码，数据库层的权限配置也是加固的一部分。有些后台系统的数据库连接字符串用了sa账号，而且应用服务器和数据库服务器没有做网络隔离。这种情况下即使代码修得再干净，一旦某个被忽略的注入点被利用，攻击者能做的事情会非常多。
合理的做法是：应用使用的数据库账号只授予所需数据库的db_datareader和db_datawriter权限，不授予db_owner或sysadmin。如果确实需要执行存储过程，只授予EXECUTE权限，并限制能执行哪些存储过程。另外，不要给应用账号开放xp_cmdshell，这个扩展存储过程在正常业务中几乎没有使用场景，出现的意义基本就是被利用。
代码层面可以加一道保险：统一封装数据库访问入口，所有SQL执行都经过一个独立的仓储层，不允许业务代码直接newSqlCommand。这样的架构改造工程量不小，适合安全要求较高的系统，但能从根本上限制拼接SQL的散落范围。
5.3 编码层次的统一策略
前面提到编码解码可能带来二次解析风险，在整体加固时也应该统一编码策略。理想的方案是：框架层统一处理URL解码和表单解码，业务层不自行调用UrlDecode、HtmlDecode这类方法。
如果系统确实存在历史遗留的HtmlDecode、Base64解码、自定义加密解密，审计时要逐个确认解码后的数据流向。修复时尽量把解码收敛到一个专门的工具类里，在进入业务逻辑之前完成所有必要的解码，后续代码只拿到最终值，不再做二次变换。
这一步的意义不仅是修漏洞，也是降低后续审计的复杂度。数据在系统里流转的变换次数越少，追查数据流越容易，安全边界越清晰。
6. 工具与手工结合的排查实录
6.1 静态扫描工具怎么选、怎么用
ASP.NET代码审计常见的工具包括各种商业SAST工具和安全IDE插件。工具的作用是扩大搜索范围、标出可疑点，但它不能替代人工判断。我见过太多团队跑完工具之后直接拿着报告去问开发人员“这是不是漏洞”，开发人员回复一句“参数化了”，报告就被扔到一边。实际上工具标记的位置有相当一部分是误报，但也有漏报，关键还是人要对代码逻辑负责。
使用工具时有几条经验：
- 不要用默认规则集直接跑全仓库，输出量太大，没人看得完。先按模块或项目拆分扫描，逐个确认。
- 关注工具报的
source和sink的路径。如果工具能展示数据流走向，优先看路径上有没有转换函数，比如解码、加密、正则替换。这些位置往往决定了漏洞是否成立。 - 工具报出的高危项，还要在真实运行环境里做一次手工验证。验证不是让你去攻击自己的系统，而是通过构造简单的非破坏性输入，观察SQL执行行为是否出现异常，从而确认漏洞逻辑是否存在。
6.2 手工确认的技巧与注意事项
手工确认是代码审计里最考验经验的部分。一个比较稳妥的方法是：先在代码里找到数据流末端，然后在本地调试环境里给对应接口发送带特殊标记的请求，在数据访问层打日志，看最终执行的SQL语句长什么样。如果SQL里出现了你传入的标记且没有被参数化包裹，那就基本确认了。
这里要注意，不要在正式生产环境做这种验证。即使你认为只是无害的探测，生产环境的数据和执行路径都不适合做安全测试。代码审计过程中的验证，尽量在测试环境或本地环境完成。
对于存储过程的动态SQL，确认方式是在SQL Server Profiler里监控SP:StmtStarting事件，或者在存储过程开头加调试输出。这一步能直观看到拼出来的SQL语句全貌，比盯着代码猜要快很多。
与开发团队沟通时，建议把问题描述成“可修复的代码缺陷”，而不是“你的代码很烂”。给出具体的代码位置、数据流路径、修复建议，最好附一个修复后的代码片段。这样推动整改的效率会高很多。
6.3 写审计报告时容易遗漏的细节
审计报告不是简单的漏洞列表，它要能指导后续修复和预防。我习惯在每个漏洞条目里包含下面几项：
- 漏洞代码的文件路径和行号
- 触发漏洞的输入参数名和类型
- 从输入到漏洞点的完整数据流路径
- 漏洞可能的业务影响范围
- 修复建议，包括短期修复和长期加固两个层面
- 同类代码的其他位置（如果有，一并列出）
一个容易被忽略的点是“同类问题检查”。发现一个拼接型注入后，不要只修这一个位置，要全仓库搜一遍相同的写法。攻击者不会因为系统只修了已知漏洞就有耐心，总有下一批利用者在路上。审计报告里专门列一个“全局排查建议”章节，把搜索关键词和排查步骤写清楚，能帮开发团队把同一类问题一次性清干净。
还有一个细节是报告的语言。尽量少用纯攻击视角描述，多用“数据流不受控”、“输入未验证”这类中性的技术表达。安全团队和开发团队配合是长期的，良好的沟通方式比报告里每一个技术细节都重要。
最后说一点个人体会。SQL注入审计做到后面，拼的已经不是“知道多少注入技巧”，而是对业务逻辑和代码演进的理解深度。一个系统的漏洞往往不是某一行的失误，而是多个环节的宽松习惯叠在一起的结果。字段没校验、接口没鉴权、SQL习惯性拼接、错误信息回显给用户，单独看每个都不致命，但串起来就是一条完整的攻击路径。审计能做的就是把这些链条一条条理清楚，在它们变成事故之前修掉。这个工作越往后做，你越会发现，真正牢固的安全不是靠某个框架的某道屏障，而是代码里每一个本该考虑边界的细节都确实被考虑过了。
