看到这个标题我就知道这又是一位在真实项目里被注入攻击折磨过的兄弟写的。说实话我在过往的工作里接手过太多号称“稳如老狗”的Web系统结果安全测试一上来搜索框里塞个单引号直接报错输入框里贴段脚本就弹窗数据库差点没被拖走。输入验证和防注入这个话题理论谁都会背但真正落地到C#代码里坑多得能把你埋了。这篇文章我打算换个写法不念PPT直接站在攻击者的角度拆解套路再站在防御者的角度把C#里能用的武器一件件摆出来从参数化查询到数据注解从EF Core的隐蔽陷阱到Razor的自动编码一次性聊透。全文会比较长但每段都是实操里能用上的东西配套的代码你直接抄走改改就能用适合正在写Web API或MVC项目的.NET开发者哪怕你刚入门看完也能让你的接口健壮一大截。1. 威胁模型先行先拆解攻击者是怎么打进来的1.1 注入攻击的本质永远不要相信任何输入我在代码评审时最爱问一句话“你觉得这个输入框会老老实实只传你想要的格式吗”答案永远是否定的。攻击者往参数里塞的东西可能是一段拼接后的SQL语句、一条JavaScript脚本、一个换行符加系统命令甚至是一串精心构造的路径遍历符。注入攻击之所以屡禁不止核心原因就是开发者把“用户的输入”当成了“可信任的业务数据”直接扔给了解释器。C# Web应用最常见的注入入口包括查询字符串、表单字段、JSON请求体、请求头里的Cookie、文件上传时的文件名和内容、甚至Excel/CSV导入时藏在单元格里的公式。每一个入口都是一道门你关上了一扇攻击者就会去撬另一扇。我之前遇到过一个系统所有文本框都做了校验结果导出报表的文件名参数没过滤攻击者把文件名改成../../../../etc/passwd配合路径拼接缺陷差点把服务器上的内容读走。所以威胁模型的第一步就是站在攻击者视角把应用的所有边界列出来逐个检查哪些输入会流向后端解释器、数据库、文件系统或浏览器。这里我要强调一个设计原则输入验证不是“防非法数据”的过滤器而是“允许合法数据”的白名单。默认拒绝一切不符合预期格式的内容而不是默认放行再逐一拦截。这个思想看起来简单但在真实代码里绝大多数团队都做反了。1.2 攻击者最常用的四板斧SQL注入、XSS、命令注入、路径遍历常见的注入攻击面可以按目标解释器分类。我在安全测试中总结了四类出现频率最高的攻击类型目标典型特征危害等级SQL注入数据库引擎单引号闭合、UNION查询、时间盲注、报错回显严重XSS浏览器引擎script标签、事件属性、javascript:伪协议高危命令注入操作系统Shell;、、、反引号拼接路径遍历文件系统../、绝对路径、编码混淆绕过高危SQL注入之所以排第一是因为它直接对着数据库说话拿到数据就是拿到一切XSS对C#后端来说同样要命因为你用Razor输出时如果没有正确编码等于在用户浏览器里开了个后门命令注入在很多企业内网系统里尤其常见比如调第三方工具时直接把文件名拼了进去路径遍历则经常出现在文件下载、图片预览、日志查看这些功能里。理解这四类攻击的特性后再去设计防线就清晰了SQL注入用参数化查询解决XSS用输出编码加CSP解决命令注入用白名单校验加禁止拼接Shell解决路径遍历用规范化路径再校验前缀解决。每个方案我都会在后面的章节展开讲包括代码和踩坑点。2. 输入验证的工程化把校验做进架构里而不是散落在业务代码中2.1 ModelState与DataAnnotations第一道防线的正确用法ASP.NET Core MVC和Web API自带了一套模型验证体系核心就是DataAnnotations。很多人用得很随意比如在实体类上挂几个特性就完事了结果在控制器里连ModelState.IsValid都没判或者判了但没做统一处理。这等于给门上了锁但钥匙一直插在锁孔里。我推荐的做法是请求实体Request Model和数据库实体Entity严格分离在请求实体上做完整的验证声明。一个比较齐全的示例长这样public class UserRegisterRequest { [Required(ErrorMessage 用户名不能为空)] [StringLength(20, MinimumLength 4, ErrorMessage 用户名长度应为4-20个字符)] [RegularExpression(^[a-zA-Z0-9_]$, ErrorMessage 用户名只能包含字母、数字和下划线)] public string UserName { get; set; } [Required(ErrorMessage 邮箱不能为空)] [EmailAddress(ErrorMessage 邮箱格式不正确)] public string Email { get; set; } [Required(ErrorMessage 手机号不能为空)] [RegularExpression(^1[3-9]\d{9}$, ErrorMessage 手机号格式不正确)] public string Phone { get; set; } }有人会问RegularExpression对UserName的限制会不会太严格要的就是严格。用户名允许各种特殊字符数据库里虽然参数化查询没问题但如果在日志里记录、在后台管理页输出给管理员看就可能在LTSV日志里搞出注入或者反射型XSS。白名单策略虽然牺牲了一点灵活性但换来了整个链路的安心。控制器端除了检查ModelState.IsValid我建议引入一个ActionFilter做全局统一验证避免每个接口重复写判断逻辑。public class ValidateModelAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext context) { if (!context.ModelState.IsValid) { var errors context.ModelState .Where(e e.Value.Errors.Count 0) .ToDictionary( k k.Key, v v.Value.Errors.Select(x x.ErrorMessage).ToArray() ); context.Result new BadRequestObjectResult(new { code 400, errors }); } } }在Program.cs里注册全局过滤器后所有接口自动生效新来的同事写接口时忘了手动判断也能兜底。builder.Services.AddControllers(options { options.Filters.AddValidateModelAttribute(); });这样输入验证从“每个接口自己管”变成了“框架统一管”开发效率和安全水位一起提升。2.2 进阶FluentValidation与自定义验证特性的适用场景DataAnnotations的强项是简单直观弱项是复杂的条件验证很难表达。比如“创建订单时收货人和会员ID二选一必填”“优惠券金额不能超过订单金额的30%”这类规则单纯靠特性写起来非常别扭。我的经验是简单约束用DataAnnotations跨字段的复杂规则就上FluentValidation。public class OrderCreateRequest { public string CouponCode { get; set; } public decimal CouponAmount { get; set; } public decimal OrderAmount { get; set; } } public class OrderCreateValidator : AbstractValidatorOrderCreateRequest { public OrderCreateValidator() { RuleFor(x x) .Must(x !string.IsNullOrEmpty(x.CouponCode) || x.CouponAmount 0) .WithMessage(使用优惠券时必须填写优惠码); RuleFor(x x.CouponAmount) .GreaterThanOrEqualTo(0) .LessThanOrEqualTo(x x.OrderAmount * 0.3m) .WithMessage(优惠金额不能超过订单金额的30%); } }注册方式builder.Services.AddValidatorsFromAssembly(typeof(Program).Assembly);调用时同样可以放进过滤器一旦校验失败就返回统一的错误结构。FluentValidation的链式API可读性极好出错信息也精确强烈推荐在订单、支付、用户中心这类业务规则复杂的模块中使用。至于自定义验证特性我有两个高频场景。第一个是枚举值校验很多人用[Range(0, 2)]但枚举中间如果有新增值Range就管不住了不如写一个[EnumValue]特性校验类型是否为合法枚举。第二个是日期范围比如“开始时间不能早于今天”直接在特性里实现语义清晰还能复用。自定义特性的核心逻辑就是继承ValidationAttribute并重写IsValid注意要返回ValidationResult而不是只返回布尔值这样能给出更友好的错误提示。2.3 正则表达式好用但要防重防误防灾难正则表达式是输入验证里的双刃剑。用它做白名单校验非常方便但有两个坑必须警惕灾难性回溯ReDoS和匹配逻辑错误。所谓灾难性回溯典型例子是^(\d)$这种嵌套量词遇到超长数字串时正则引擎会进行指数级回溯直接把CPU跑满。攻击者只需要一个很长很长的参数就能把服务器拖死这本身就是一种拒绝服务攻击。所以我给自己定了一条规矩写进生产代码的正则必须用更确定性的写法避免嵌套量词比如^\d{1,20}$就比^(\d)$安全得多。匹配逻辑错误则常见于把“验证输入”和“匹配内容”混为一谈比如用IndexOf或Contains判断是否含有关键字然后拒绝请求。这种黑名单思路遇到大小写混写、URL编码、Unicode等价字符就会轻松绕过。正确做法仍然是白名单正则加Trim和规范化例如对URL先Uri.TryCreate再检查IsAbsoluteUri而不是用string.Contains(http://)来判断。我在上一家公司做过一次安全加固发现同事用了一个网上的“邮箱正则”看起来巨复杂实测却把testgmail.com这种正常地址判成非法原因是.的量词在长域名上触发了回溯。后来我把邮箱验证换成了[EmailAddress]特性加运行时MailAddress解析问题彻底消失。正则用于严格格式校验时务必在测试用例里覆盖正常值、边界值和恶意值三类样本再上生产线。3. SQL注入专题这是C#开发者必须攻下的高地3.1 经典攻击演练从报错回显到拖库的完整链条先看一段反面教材这是我在代码审计中见过最多的写法string sql $SELECT * FROM Users WHERE UserName {input} AND Password {password};攻击者在input里输入 OR 11拼接后的SQL变成SELECT * FROM Users WHERE UserName OR 11 AND Password 任意这个OR一出现等于告诉数据库“用户名是空的也行或者1等于1就行”于是查询条件恒真攻击者不需要密码就能登录系统。更狠的是堆叠注入比如传入; DROP TABLE Users;--在SQL Server里如果连接字符串开启了MultipleActiveResultSets或某些特殊配置甚至可以执行多条语句。就算不堆叠UNION注入也能把其他表的敏感字段带出来配合报错回显等于数据库裸奔。这套流程我经常在内部培训里现场演示每次都能看到学员倒吸一口凉气。危险不在注入本身而在“拼接字符串”这个动作它等于把解释器的权限交给了用户输入。预防办法不是过滤单引号——过滤单引号是最低效的方式因为攻击者会尝试编码、宽字节、运算符替代——而是从根上放弃拼接SQL的想法全面使用参数化查询。3.2 参数化查询ADO.NET、Dapper与EF Core的正确姿势C#生态里主流的三类数据访问方式参数化查询都是标配关键是有人用错了。先看ADO.NETusing (var cmd new SqlCommand( SELECT * FROM Users WHERE UserName userName AND Password password, connection)) { cmd.Parameters.AddWithValue(userName, input); cmd.Parameters.AddWithValue(password, password); // 执行... }参数化后传入的值只当作“数据”数据库引擎不会再把它们当成SQL语法的一部分解析。哪怕输入的就是 OR 11对数据库来说它只是某个字符串变量的值无法改变查询结构。AddWithValue有个隐性坑就是可能导致隐式类型转换让索引失效进而引发性能问题。更稳的是用Add(userName, SqlDbType.NVarChar, 50).Value input显式声明类型和长度。实际遇到过一次传日期参数时AddWithValue把SQL Server的隐式转换坑了一整晚查询慢到超时后来改成显式类型瞬间解决。Dapper的做法更简洁var user connection.QueryFirstOrDefaultUser( SELECT * FROM Users WHERE UserName UserName AND Password Password, new { UserName input, Password password });Dapper会把匿名对象的属性自动映射为参数不需要手动拼字符串天然防注入。只要你的SQL文本里没有变量拼接Dapper这条线就是安全的。EF Core这边要特别小心两个APIFromSqlRaw和ExecuteSqlRaw。名字里带Raw就说明它支持原生SQL但只要你在SQL字符串里拼接用户输入注入风险立刻回归。安全用法是FromSqlInterpolated它在编译时会把插值转换成参数化查询var users await context.Users .FromSqlInterpolated($SELECT * FROM Users WHERE UserName {input}) .ToListAsync();注意FromSqlInterpolated本质是用FormattableString把值作为参数传递而不是把字符串拼进去所以是安全的。如果你坚持用FromSqlRaw就绝不能让SQL文本里嵌入任何未经参数化的外部字符串。这里有一个我见过很多次的误用案例同事为了“统一管理查询文本”把整段SQL写进配置文件再用FromSqlRaw读出来执行同时又把用户输入用Replace填进占位符结果等于手动拆掉了参数化防线攻击面瞬间打开。凡是想手动“过滤”或“替换”用户输入再进SQL的行为都属于反面教材。3.3 场景排序字段、表名、批量导入的防注入策略有一个特殊场景经常让人头疼用户可以选择按“更新时间”“点击量”“价格”排序代码写成ORDER BY {sortColumn}这里也敢参数化吗答案是参数化只能处理值不能处理标识符表名、列名。列名如果来自白名单映射就还安全var allowedSortColumns new Dictionarystring, string { [time] UpdateTime, [hot] ClickCount, [price] Price }; if (!allowedSortColumns.TryGetValue(sortKey, out var column)) { throw new ValidationException(非法的排序字段); } var sql $SELECT * FROM Products ORDER BY {column};排序方向同理只允许ASC和DESC两个字面量进入SQL其他一律拒绝。这种白名单映射比任何过滤都可靠因为可选项是固定的根本没有注入空间。另一个高频场景是SqlBulkCopy批量导入标题热词里也有“c# sqlbulkcopy 表变动有影响”。SqlBulkCopy本身不走SQL拼接路线但它的数据来源如果是Excel或CSV上传就会面临数据内容和列映射两个风险。数据内容方面即使某个单元格里写的是; DROP TABLE Users;--它也会乖乖作为字符串写进目标列不会变成SQL语句。真正的问题在于列名映射DataTable的列名如果来自文件头拼进SqlBulkCopy.ColumnMappings时就必须先做白名单校验否则有列名注入的风险。我建议在批量导入前先做完整的数据清洗包括去重、格式校验、长度截断再交给SqlBulkCopy。批量导入是高风险路径因为数据量大、覆盖表多一旦出事就是大面积污染。3.4 存储过程参数化之外权限最小化同样关键很多老项目喜欢用存储过程做数据访问想法是“存储过程能防止注入”。这句话对一半如果存储过程内部也拼SQL字符串注入照样发生。SQL Server的sp_executesql接收拼接语句时外部传入参数如果不经过类型校验和直接拼接没有本质区别。CREATE PROCEDURE dbo.GetUser UserName NVARCHAR(50) AS BEGIN DECLARE sql NVARCHAR(4000); SET sql NSELECT * FROM Users WHERE UserName UserName N; EXEC sp_executesql sql; END这种存储过程形同虚设。正确做法是存储过程内部使用参数化语句CREATE PROCEDURE dbo.GetUser UserName NVARCHAR(50) AS BEGIN SELECT * FROM Users WHERE UserName UserName; END同时要设置数据库账号的最小权限比如只给EXECUTE权限不给SELECT、INSERT、UPDATE、DELETE的Direct权限。这样即便注入成功攻击者能触达的范围也被锁死在一组过程里。权限最小化属于纵深防御中最容易被忽略但性价比极高的一环我在案例中见过不止一次应用账号用的是sa一旦注入成功攻击者直接拿到整个数据库的管理权限系统彻底沦陷。权限上能降多少就降多少永远不要图省事给高权限账号。4. 不止SQLXSS、命令注入、路径遍历的C#防线4.1 输出编码与CSP让脚本在浏览器里跑不起来C#后端对XSS的防御核心是“输出编码”。Razor视图默认对Model.Name这样的输出做HTML编码所以你模型里如果存了scriptalert(1)/script页面渲染时会显示原文而不是执行脚本。但问题出在几个隐蔽路径一是Html.Raw()二是[AllowHtml]特性的滥用三是在JavaScript字符串里嵌入输出四是在href、src属性里插入动态值。Html.Raw之所以危险是因为它跳过了编码把内容直接当作HTML注入页面。很多人用它渲染富文本编辑器的内容但不是只做一次净化就安全了。富文本场景下我建议用白名单HTML净化器只允许p、strong、ul这类安全标签剥离onclick、onload等事件属性和javascript:协议。自己做正则杀危险标签属于下策我见过不止一个项目用正则清理后被scrscriptipt双重编码绕过。JavaScript上下文的编码另有一套规则。Razor的HTML编码并不能保护你插入到script里的值var userName Model.Name;如果Model.Name里包含/scriptscriptalert(1)/scriptHTML编码后的引号不转译JavaScript语义照样能逃逸出字符串。正确做法是把值序列化成JSON再赋值var user Html.Raw(Json.Serialize(Model));这样键值结构完整JS解析器不会把内容当作代码执行。当然不管后端再怎么编码前端也绝不能把不可信数据直接用InnerHTML插入。加一道CSP内容安全策略响应头作为兜底能让内联脚本和外部脚本来源都受限即使有漏网之鱼也执行不了app.Use(async (context, next) { context.Response.Headers.ContentSecurityPolicy default-src self; script-src self; object-src none; base-uri self; await next(); });这套组合拳下来XSS几乎无路可走。有人觉得麻烦但在安全攻防里“编码 CSP 输入白名单”三重纵深才是对付XSS的正解。4.2 命令注入再也不要把用户输入传给Process.Start在C#里执行外部命令时最常见的错误是这样的string cmd ping ipAddress; Process.Start(cmd.exe, /c cmd);如果ipAddress是127.0.0.1 whoami系统就会先执行ping再执行whoami攻击者可以串联任意命令。命令注入的可怕之处在于它不仅执行一句话还可以借助下载器比如powershell -command Invoke-WebRequest把恶意软件拖进服务器。防御思路有两条一是垂直的能不用外部命令就不用能用.NET自带库比如System.Net.NetworkInformation.Ping就绝不调用系统命令。二是横向的实在要调外部命令必须严格过滤参数并确保证不会被Shell解释。Process.Start传参时参数数组的形态本身不会走Shell但如果你拼接进cmd.exe或/bin/bash -c就等于主动把控制权交给了Shell解析器。一个相对稳的做法var psi new ProcessStartInfo(ping) { RedirectStandardOutput true, UseShellExecute false }; psi.ArgumentList.Add(ipAddress); using var process Process.Start(psi);ArgumentList能让参数原样传递不经过Shell同时校验ipAddress必须匹配IPv4格式正则。双保险之下命令注入基本堵死。4.3 路径遍历Path.Combine不是你想象的安全文件上传和下载功能是路径遍历的重灾区。下面这段代码看起来没什么问题string fullPath Path.Combine(_webRootPath, fileName); File.ReadAllText(fullPath);如果fileName是..\..\..\Windows\win.iniPath.Combine会老老实实拼接出包含..的路径只要拼接后的路径在服务器文件系统里存在读取就成功。Path.Combine只是拼接工具不做防逃逸处理。防御方式是先获取完整路径再进行规范化最后校验是否落在允许的根目录内string fullPath Path.GetFullPath(Path.Combine(_webRootPath, fileName)); var allowedRoot Path.GetFullPath(_webRootPath); if (!fullPath.StartsWith(allowedRoot, StringComparison.OrdinalIgnoreCase)) { throw new SecurityException(非法的文件路径); }Path.GetFullPath会把..解析成实际路径再和根目录前缀对比凡是跳出根目录的请求一律拒绝。文件名本身也要做白名单校验只允许字母数字、下划线、点、中划线拒绝/、\和控制字符。我之前收到过一个安全报告漏洞就是下载接口拿用户提交的相对路径直接读取对方用URL编码后的..%2f..%2f绕过了简单关键词过滤后来加上规范化校验才彻底修复。文件上传方面除了路径校验还要做文件类型校验。很多人只检查扩展名那是换皮就能绕过的。正确做法是读取文件头魔数判断真实类型再重新生成随机文件名存储不让用户控制最终落盘的文件名。像“c# rembg库提取图像前景移除图像背景”这种图像处理类应用如果接收用户上传图片再输出处理结果同样要小心路径和文件名注入处理接口千万别把用户给的原始文件名直接拼到输出路径上。5. 纵深防御与实操落地从接口到日志构建Web应用的全链路防线5.1 防重放、防枚举、限流给接口再加几把锁输入验证和注入防护主要集中在“内容”维度但攻击者还会在“频率”和“语义”维度上下手。比如登录接口如果不做限流攻击者可以用字典跑密码验证码接口如果不做防重放同一个验证码可以反复提交订单查询接口如果不做归属校验用户改个订单号就能看别人的数据。所以一套完整的防线至少要包含这几层层级手段目的内容层参数化查询、编码、白名单校验堵住注入、XSS逻辑层防重放、防越权检查资源归属堵住逻辑漏洞频率层限流、验证码、IP封禁堵住暴力破解响应层统一错误码、安全响应头、CSP降低信息泄露和攻击效率观测层安全日志、告警及时发现问题、溯源我见过太多团队把全部安全预算押在“防注入”上结果逻辑漏洞被挖穿。比如用C#写教务管理系统、考勤系统这类带账号体系的场景接口必须校验“当前登录用户是否有权操作这个资源”否则登录用户传一个别人的ID就能改数据。这个校验和注入无关但杀伤力一点不比SQL注入小。把这些都写进项目的安全检查清单从开发第一天就按清单自查能省掉后面大量返工。5.2 统一异常处理与日志既别泄露也别留死角异常处理有双重标准面向用户的响应里绝不能暴露堆栈、SQL语句、数据库表名等细节否则等于给攻击者递地图。但面向开发者的日志里又必须记录足够多的上下文方便排查和溯源。简单做法是用全局异常中间件app.UseExceptionHandler(errorApp { errorApp.Run(async context { var exception context.Features.GetIExceptionHandlerFeature()?.Error; // 记录完整异常到日志 _logger.LogError(exception, Unhandled exception for {Path}, context.Request.Path); context.Response.StatusCode 500; await context.Response.WriteAsJsonAsync(new { code 500, message 服务器内部错误 }); }); });里面返回给客户端的message必须是无害的通用文案。在日志里记录请求路径、用户ID、IP、UserAgent、异常堆栈和关联的数据库操作但不要把密码、支付卡号、令牌等敏感字段写进去。SQL参数值如果能暴露在日志里攻击者通过日志注入也能搞事。所以日志框架里对敏感字段要做脱敏替换。安全日志专门记录异常特征比如同一IP短时间大量请求、请求参数里出现单引号或UNION SELECT等特征、未登录用户访问受保护接口等等。这些日志接入告警系统后即使防线被突破也能在第一时间发现动作然后止损。5.3 安全发布与组件依赖别让第三方库成为后门C#项目引用的第三方库越来越多其中任何一个组件出现已知漏洞整个应用都暴露在危险下。NuGet有自带的安全审计器dotnet list package --vulnerable但这个命令需要配合NuGetAudit配置才能稳定输出。建议在CI流水线里加一步依赖检查dotnet list package --vulnerable --include-transitive更完整的方案是配合OWASP Dependency-Check或Defender for DevOps这类工具把供应链风险纳入自动化扫描。有一次我接手一个老旧项目发现引用的Newtonsoft.Json版本是12.0.1里面有几个高危漏洞攻击者能构造特殊JSON触发拒绝服务。升级到13.0.3后问题解决但要小心接口的序列化行为变化升级前跑一遍全量回归测试。另外发布环境要保持干净关闭不必要的开发调试功能。比如appsettings.Development.json里的开发者异常页如果误发布到了生产环境攻击者访问不存在的路由时就能看到完整堆栈。我在安全检查时第一件事就是看生产响应头有没有X-Powered-By字段、有没有开发者工具泄漏。这些细节看起来不起眼但攻击者就是靠这些信息拼出你的技术栈再找对应的漏洞。6. 常见问题与排查技巧把踩过的坑整理成速查表6.1 上线前必过的安全自检清单我把自己做项目安全自查的清单简化成了十个必检项照着过一遍能解决大部分低级别漏洞所有控制器入口都加了ValidateModel过滤器吗所有数据库操作都是参数化或经过ORM安全API了吗有没有地方直接拼SQL字符串搜索整个解决方案里的SqlCommand和FromSqlRaw确认没有拼接用户输入。前端页面所有输出位置Razor、JavaScript、URL属性都做了编码处理吗文件上传是否有扩展名、文件头、大小、路径四重校验文件下载是否做了路径规范化与目录白名单校验接口返回的异常信息是否不包含堆栈和SQL细节登录、验证码、短信接口是否有限流和防重放敏感字段密码、Token、身份证号是否加密存储或至少是哈希存储生产环境是否禁用了开发者异常页和调试模式每一条的背后都有真实事故。项目时间紧我通常先跑这个清单把高危项优先修复再通过自动化安全扫描确认没有遗漏。安全检查不是“做一次就完事”需求每变一次攻击面就多一条清单就得重跑一遍。6.2 排查实录从“参数无效”到“数据库死锁”的五个案例案例一明明参数传了值ModelState.IsValid却始终为false。排查发现请求实体里的属性是DateTime前端传的却是空字符串绑定失败引发验证失败。解决办法是改用DateTime?并在自定义验证特性里单独判空。案例二用FromSqlInterpolated执行带参数的搜索结果极慢。排查发现EF Core生成了WHERE Name LIKE p0但因为写法是$LIKE %{keyword}%参数值本身带了通配符索引失效。这不算注入问题但放大了性能风险。改成让用户输入不带通配符匹配逻辑在后端拼接%查询就能走索引。案例三Dapper执行多行插入时报“传入的表格格式数据流TDS远程过程调用RPC协议流不正确”。原因是在CommandType.Text模式下传了DataTable参数需要换成CommandType.StoredProcedure配合表值参数才行。这种错误虽然不直接和安全相关但一旦出现类似提示先怀疑参数类型不匹配别一头扎进SQL语法里。案例四搜索框输入带引号的商品名时页面直接爆500。原因是底层用了SqlCommand且拼接了搜索关键字的LIKE条件里的引号。修复方式改成参数化LIKE查询同时给搜索参数加最长长度限制避免超长输入触发数据库排序缓冲溢出。案例五用户反馈文件下载功能偶尔能下载到其他用户的文件。原因是下载路径直接用数据库里的相对路径拼接攻击者遍历ID就能绕过前缀校验。修复后每次下载前会校验文件归属并且把文件存储在带随机ID的子目录下枚举成本大幅提升。这些案例的共同点问题的根源大多不是“没做安全”而是“只做了一层安全且这层刚好被绕过”。实战中行之有效的思路永远是“层层设防、彼此独立”而不是指望某一道防线挡下所有攻击。6.3 测试注入攻击能用什么工具、要注意什么写完代码后强烈建议做一轮自动化注入测试。SQLMap是业内常用的SQL注入检测工具使用前必须确认你拥有目标环境的授权仅在本地测试环境或你自己搭建的靶机上运行。用法基本如下sqlmap -u http://localhost:5000/api/products?category1 --batch --level2 --risk2其中--level和--risk会决定测试用例深度越高越彻底但也越容易产生大量请求可能触发限流或者把测试环境打挂。建议先在测试环境按level 1跑一遍确认无注入后再加参数跑深度检测。XSS方面可以用浏览器的开发者工具手工验证也可以借助OWASP ZAP的Active Scan做自动扫描针对参数反射和DOM输出点做检测。需要提醒的是自动化工具是辅助不能替代人工代码评审。SQLMap只能测出你能不能注入却测不出你的业务逻辑有没有越权、你的日志有没有泄露Token、你的第三方库有没有高危CVE。所以我的工作流是先人工走一遍安全自检清单再上自动化扫描两者结果合并成缺陷清单按危害级别排期修复。工具测完没问题不代表系统100%安全但至少能干掉99.9%的脚本小子式攻击。写在最后说一点我自己的实操体会做了这么多年应用安全我最大的感受是安全不是某个版本的功能而是编码习惯本身。参数化查询、输入验证、输出编码这些技巧单独拎出来都不复杂难的是在每一行代码里都保持这个意识。我也犯过把用户名拼进SQL的错也踩过Html.Raw导致XSS的坑正是在这些事故里才慢慢形成了一套固定的防御套路。这篇文章里的代码全部来自我实际维护过的项目你可以直接参考但更希望你能理解背后的思路默认不信任所有输入明确区分数据和解释器在每一层边界都设立独立的检查点。你的系统当然不可能做到100%绝对安全但当你把输入验证和防注入变成肌肉记忆后你所写的代码离“99.9%的注入攻击都打不进来”这个目标真的没有想象中那么远。