接手一个遗留的C#企业级项目，最让人头皮发麻的不是业务逻辑复杂，而是打开代码仓库后发现SQL语句全靠字符串拼接、用户密码明文存储、接口没有任何访问限制。这类代码一旦上线，无异于在互联网上裸奔。企业级安全编码不是锦上添花，而是决定项目生死的基础设施。下面直接进入具体场景，给出可落地的防护方案。

参数化查询与SQL注入的彻底杜绝

字符串拼接SQL是数据泄露的第一大元凶。即便使用了ORM框架，仍可能在原生SQL执行环节留下漏洞。绝对不能信任任何来自用户输入的数据，无论它来自表单、URL参数、HTTP头部还是上传的文件名。

使用Dapper或ADO.NET时，必须采用参数化查询。参数化查询让数据库引擎明确区分SQL指令与数据，从根本上杜绝注入可能。以下是一个反面案例和正面案例的对比：

// 危险写法：字符串拼接
string query = "SELECT * FROM Users WHERE Username = '" + username + "' AND Password = '" + password + "'";
var user = connection.Query<User>(query).FirstOrDefault();

// 安全写法：参数化查询
string query = "SELECT * FROM Users WHERE Username = @Username AND Password = @Password";
var user = connection.Query<User>(query, new { Username = username, Password = password }).FirstOrDefault();

如果使用Entity Framework Core，尽量避免使用FromSqlRaw拼接字符串。当必须执行动态排序或动态表名时，不要直接拼接用户输入，而应建立白名单映射。例如用户请求按某字段排序，后端维护一个允许排序的字段列表，用户传入的参数必须在此白名单内才拼入SQL，否则使用默认排序。动态表名同理，绝不可将前端传来的表名直接插入SQL语句。

存储过程并不能天然防注入。如果在存储过程内部使用EXEC或sp_executesql拼接字符串执行动态SQL，同样存在注入风险。存储过程内部也必须使用参数化方式处理输入。

身份认证与密码存储的硬性规范

密码绝不能明文存储，也不能使用MD5、SHA1等快速哈希算法。企业级应用必须使用专门的密码哈希算法，如bcrypt、PBKDF2或Argon2。这些算法内置盐值且计算速度慢，能有效抵御彩虹表攻击和暴力破解。

在C#中使用bcrypt非常简单，通过BCrypt.Net-Next库即可实现：

// 注册时哈希密码
string passwordHash = BCrypt.Net.BCrypt.HashPassword(plainTextPassword);

// 登录时验证密码
bool isValid = BCrypt.Net.BCrypt.Verify(loginPassword, storedHash);

如果使用ASP.NET Core Identity框架，它默认使用PBKDF2算法，安全性已经满足要求，不要擅自修改为更低成本的算法。密码策略方面，企业级应用应强制最小长度至少8位，并鼓励使用密码短语。不要强制要求大小写字母、数字和特殊符号的复杂组合，这种策略已被证明会促使用户创建可预测的密码模式，反而降低安全性。真正有效的策略是检测用户密码是否出现在已知泄露密码库中，可以在注册或修改密码时调用Have I Been Pwned的API进行离线k-anonymity检查。

多因素认证（MFA）应作为企业级应用的标配。TOTP（基于时间的一次性密码）实现成本低，用户接受度高。后端实现时，密钥必须加密存储，不能以明文形式保存在数据库中。

访问控制与权限校验的层层设防

身份认证确认了用户是谁，访问控制决定了用户能做什么。企业级系统必须实现最小权限原则，默认拒绝所有访问，只对经过授权的请求放行。

在ASP.NET Core中，基于策略的授权比基于角色的授权更灵活。不要只在Controller层做权限校验，Service层和Repository层同样需要权限检查，防止因Controller层疏漏导致越权操作。特别注意水平越权和垂直越权。水平越权是指用户A访问了用户B的数据，比如通过修改URL中的ID参数查看他人订单。防范方法是在数据查询时强制带上当前用户的身份标识，而不是仅依赖传入的资源ID：

// 危险写法：仅根据传入ID查询
var order = db.Orders.Find(orderId);

// 安全写法：同时校验归属
var order = db.Orders.FirstOrDefault(o => o.Id == orderId && o.UserId == currentUserId);

对于垂直越权，即低权限用户执行高权限操作，需要为每个API端点明确标注所需的权限策略，并在中间件层面统一拦截。使用JWT令牌时，令牌中应包含用户角色或权限声明，后端每次请求都验证令牌有效性和权限声明，不信任任何客户端传来的角色信息。

敏感数据保护与加密最佳实践

敏感数据在传输层必须使用TLS 1.2及以上版本加密，且服务端应配置仅允许强密码套件。在应用层，敏感配置如数据库连接字符串、第三方API密钥绝不能硬编码在代码或配置文件中。开发环境使用Secret Manager工具，生产环境使用Azure Key Vault、AWS Secrets Manager或HashiCorp Vault等密钥管理服务。

数据库中存储的个人身份信息、财务数据等敏感字段应进行应用层加密。使用AES-256-GCM算法，它同时提供加密和完整性验证。密钥管理是加密体系中最薄弱的环节，主密钥必须存储在硬件安全模块或云密钥管理服务中，绝不能与密文存放在同一位置。以下是使用AES-GCM加密的示例：

public static byte[] Encrypt(byte[] plaintext, byte[] key)
{
    byte[] nonce = new byte[12]; // 96位随机数
    RandomNumberGenerator.Fill(nonce);
    byte[] ciphertext = new byte[plaintext.Length];
    byte[] tag = new byte[16]; // 128位认证标签
    
    using var aes = new AesGcm(key);
    aes.Encrypt(nonce, plaintext, ciphertext, tag);
    
    // 将nonce、tag和ciphertext组合存储
    byte[] result = new byte[nonce.Length + tag.Length + ciphertext.Length];
    Buffer.BlockCopy(nonce, 0, result, 0, nonce.Length);
    Buffer.BlockCopy(tag, 0, result, nonce.Length, tag.Length);
    Buffer.BlockCopy(ciphertext, 0, result, nonce.Length + tag.Length, ciphertext.Length);
    return result;
}

日志记录中必须过滤敏感信息。用户的密码、身份证号、银行卡号、手机号等数据绝不能以明文形式出现在日志中。可以在日志框架层面实现脱敏中间件，对敏感字段自动进行掩码处理，例如手机号显示为1385678。

CSRF与跨域安全防护

基于Cookie的认证场景下，CSRF攻击仍然有效。ASP.NET Core的防伪令牌机制能有效防御此类攻击。对于SPA应用，使用Anti-Forgery中间件并在每个状态变更请求中携带防伪令牌。更现代的做法是使用SameSite Cookie属性，将其设置为Strict或Lax，能在浏览器层面阻止跨站请求携带Cookie。

CORS配置必须精确，不能图省事将AllowAnyOrigin和AllowAnyMethod同时开放。生产环境中应明确列出允许的源、方法和头部。如果API需要支持多个子域名，可以动态校验请求的Origin是否在白名单域名列表中，而不是直接返回通配符。

安全响应头与基础设施加固

HTTP安全响应头是性价比极高的防护手段。Content-Security-Policy头能有效防御XSS攻击，限制页面可以加载的资源来源。对于一个纯API后端，可以设置default-src 'none'，对于需要返回HTML页面的后端，应详细指定script-src、style-src等指令。Strict-Transport-Security头强制浏览器使用HTTPS连接，max-age建议设置为至少一年并包含includeSubDomains。X-Content-Type-Options设置为nosniff防止MIME类型嗅探。

在ASP.NET Core中添加安全响应头可以通过中间件统一实现：

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
    context.Response.Headers.Add("X-Frame-Options", "DENY");
    context.Response.Headers.Add("Referrer-Policy", "strict-origin-when-cross-origin");
    context.Response.Headers.Add("Permissions-Policy", "camera=(), microphone=(), geolocation=()");
    await next();
});

依赖项管理同样关键。定期扫描NuGet包中的已知漏洞，使用dotnet list package --vulnerable命令可以快速检查。在CI/CD流水线中集成漏洞扫描步骤，发现高危漏洞立即阻断构建。对于不再维护或存在严重漏洞的第三方库，必须制定替换计划。

输入验证的纵深防御

除了SQL注入防护，所有外部输入都需要在服务端进行严格验证。前端验证仅用于提升用户体验，不能作为安全措施。使用FluentValidation或Data Annotations进行模型验证，但要注意Data Annotations的默认错误消息可能泄露实体结构信息，生产环境应使用自定义错误消息。

文件上传是高风险功能。必须验证文件类型，不能仅依赖文件扩展名或MIME类型，而应检查文件头部的魔数。文件大小必须在服务端限制，存储时使用随机生成的文件名，避免使用用户提供的文件名。如果可能，将文件存储在Web根目录之外，通过专门的处理器来提供文件访问，并在提供访问前进行权限校验。

对于富文本输入，需要使用成熟的HTML净化库如HtmlSanitizer，基于白名单机制只允许安全标签和属性通过，彻底过滤script标签、事件处理属性和javascript伪协议。

异常处理与信息泄露防护

生产环境绝不能向客户端返回详细的异常堆栈信息。全局异常处理中间件应捕获所有未处理异常，记录完整堆栈到日志系统，向客户端只返回通用的错误响应。对于API，返回标准的ProblemDetails格式，但其中的Detail字段不应包含数据库错误、表名、字段名等内部信息。自定义异常类可以携带面向用户的安全消息和面向开发者的调试信息，中间件根据环境变量决定返回哪些内容。

安全审计与监控

安全事件的可追溯性要求关键操作必须记录审计日志。审计日志应包含操作时间、操作人、操作类型、操作对象、操作结果和客户端IP等信息。审计日志存储在与业务数据库隔离的存储中，并设置严格的只写权限，防止日志被篡改。登录失败、权限变更、敏感数据访问等事件应触发实时告警。在C#中可以使用Serilog或NLog的结构化日志功能，将审计事件输出到集中式日志平台进行分析和告警。

实现请求频率限制防止暴力破解和资源滥用。ASP.NET Core内置的Rate Limiting中间件支持固定窗口、滑动窗口、令牌桶和并发限制等多种算法。对于登录接口，应设置严格的频率限制，如每分钟不超过5次尝试，并在连续失败后要求输入验证码或暂时锁定账户。

企业级安全编码是一个持续的过程，每个环节的疏漏都可能导致整体防线崩溃。将这些实践融入日常开发流程，通过代码审查和安全测试不断加固，才能构建起真正可信赖的系统。