第17章 加密与解密
17.5 防御网络攻击（DDoS、SQL注入、XSS）
一、我踩过的“网络攻击坑”：从服务器崩溃到数据泄露
刚做第一个项目时，因为用字符串拼接SQL，上线3天就被SQL注入，数据库里一半用户vb.net教程C#教程python教程SQL教程access 2010教程数据被删，赔了用户5万；后来做电商网站，又被XSS攻击，首页被挂了赌博广告，搜索引擎直接把网站降权；去年双11，服务器被DDoS攻击，流量瞬间涨到100G，服务器直接崩溃，损失了几十万订单。这节我把自己从“被攻击到崩溃”到“主动防御”的踩坑经验揉进去，用大白话讲透DDoS、SQL注入、XSS三种最常见的网络攻击的原理，结合C#实战代码逐行讲解防御方法，以及最佳实践，让你的网络系统像银行一样安全。
二、DDoS攻击：“流量洪水”淹没服务器，如何自救？
DDoS（分布式拒绝服务）是用大量虚假请求淹没服务器，让合法用户无法访问——就像一万个人同时打电话给你，你根本接不到朋友的电话。常见的DDoS攻击类型有：
CC攻击：用大量HTTP请求占用服务器CPU和内存；
SYN洪水：用大量TCP连接请求占用服务器端口；
UDP洪水：用大量UDP数据包占用服务器带宽。
类比：DDoS攻击就像你开了一家奶茶店，一万个假顾客同时来排队，真顾客根本进不来，店员也忙不过来。
实战1：ASP.NET Core限流中间件，防CC攻击（代码层面防御）
代码层面只能防小流量DDoS，大流量还是要靠CDN或云防护。ASP.NET Core的AspNetCoreRateLimit中间件可以实现限流：
csharp

	// Program.cs（ASP.NET Core 8.0）
	var builder = WebApplication.CreateBuilder(args);
	
	// 1. 配置限流规则
	builder.Services.AddOptions();
	builder.Services.AddMemoryCache(); // 用内存存储限流统计（生产环境用Redis）
	builder.Services.Configure<IpRateLimitOptions>(options =>
	{
	options.GeneralRules = new List<RateLimitRule>
	{
	// 每个IP每分钟最多100个请求
	new RateLimitRule
	{
	Endpoint = "*",
	Limit = 100,
	Period = "1m"
	},
	// 每个IP每小时最多1000个请求
	new RateLimitRule
	{
	Endpoint = "*",
	Limit = 1000,
	Period = "1h"
	}
	};
	});
	
	// 2. 注册限流服务
	builder.Services.AddInMemoryRateLimiting();
	builder.Services.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();
	
	// 3. 添加限流中间件（必须在UseRouting之后，UseAuthorization之前）
	var app = builder.Build();
	app.UseIpRateLimiting();
	
	app.UseRouting();
	app.UseAuthorization();
	
	app.MapControllers();
	app.Run();

代码逐行讲解：
1.IpRateLimitOptions：配置限流规则——Endpoint="*"表示所有接口，Limit是请求数，Period是时间窗口；
2.AddInMemoryRateLimiting：用内存存储限流统计，生产环境建议用Redis，支持分布式系统；
3.UseIpRateLimiting：启用限流中间件，超过限制的请求会返回429 Too Many Requests；
4.生产环境优化：用Redis存储限流统计，避免单节点内存不足；配置白名单，允许内部IP或搜索引擎爬虫不受限制。
实战2：云防护+CDN，防大流量DDoS（企业级防御）
代码层面只能防小流量DDoS，大流量（比如100G以上）必须用云服务：
1.CDN：用阿里云CDN、Cloudflare CDN，把静态资源（图片、JS、CSS）放在CDN，CDN会缓存资源，减少服务器压力，同时过滤大部分DDoS流量；
2.云DDoS防护：用阿里云DDoS高防、腾讯云DDoS防护，把流量引到高防IP，高防IP会清洗流量，只把合法流量转发到服务器；
3.负载均衡：用Nginx、阿里云SLB，把流量分散到多台服务器，避免单台服务器崩溃。
我踩过的坑：双11前没升级云DDoS防护的带宽，结果被攻击时流量超过了防护带宽，服务器还是崩溃了——一定要提前预估流量，升级防护带宽！
DDoS防御的最佳实践
1.分层防御：代码限流+CDN+云DDoS防护，多层过滤流量；
2.提前预估流量：大促前升级云防护带宽，避免流量超过限制；
3.监控告警：用Prometheus、Grafana监控服务器流量，设置告警阈值（比如流量超过平时的5倍就告警）；
4.应急响应：被攻击时，立即切换到高防IP，联系云服务商协助清洗流量；
5.避免单点故障：用负载均衡分散流量，多台服务器部署，避免单台服务器崩溃。
三、SQL注入：“偷梁换柱”篡改SQL，如何防？
SQL注入是用户输入的内容被解析为SQL的一部分，导致SQL语句被篡改——比如用户输入' OR 1=1 --，拼接成SQL后变成SELECT * FROM Users WHERE Username='' OR 1=1 --' AND Password=''，直接返回所有用户数据。
我踩过的坑：刚做第一个项目时，用字符串拼接SQL：
csharp

	// 错误示例：字符串拼接SQL，容易被注入
	string username = Request.Query["username"];
	string password = Request.Query["password"];
	string sql = $"SELECT * FROM Users WHERE Username='{username}' AND Password='{password}'";

结果用户输入username' OR 1=1 --，SQL变成SELECT * FROM Users WHERE Username='username' OR 1=1 --' AND Password=''，直接返回所有用户数据，后来数据库被删了一半，赔了用户5万！
实战1：参数化查询，防SQL注入（ADO.NET）
参数化查询是防SQL注入的核心——参数是单独传递的，不会被解析为SQL的一部分：
csharp

	// 正确示例：参数化查询，防SQL注入
	string username = Request.Query["username"];
	string password = Request.Query["password"];
	
	using var conn = new SqlConnection("Server=.;Database=Demo;Trusted_Connection=True;");
	await conn.OpenAsync();
	
	// 用@username和@password作为参数，不要拼接字符串
	string sql = "SELECT * FROM Users WHERE Username=@username AND Password=@password";
	using var cmd = new SqlCommand(sql, conn);
	// 添加参数，指定参数类型和长度，防止类型转换注入
	cmd.Parameters.Add("@username", SqlDbType.NVarChar, 50).Value = username;
	cmd.Parameters.Add("@password", SqlDbType.NVarChar, 100).Value = password;
	
	using var reader = await cmd.ExecuteReaderAsync();
	if (reader.Read())
	{
	Console.WriteLine($"登录成功：{reader["Username"]}");
	}

代码逐行讲解：
1.@username和@password：是参数占位符，不是字符串拼接；
2.cmd.Parameters.Add：添加参数，指定参数类型和长度——比如SqlDbType.NVarChar, 50，防止用户输入超长内容导致溢出；
3.参数化查询的原理：数据库会把参数和SQL分开解析，参数不会被当作SQL的一部分，所以即使用户输入' OR 1=1 --，也只会被当作普通的字符串查询，不会篡改SQL。
实战2：用EF Core的LINQ查询，防SQL注入
EF Core的LINQ查询会自动生成参数化SQL，不需要手动写参数：
csharp

	// 正确示例：EF Core LINQ查询，自动参数化
	var username = Request.Query["username"];
	var user = await _context.Users
	.Where(u => u.Username == username)
	.FirstOrDefaultAsync();

EF Core会生成如下参数化SQL：
sql
SELECT TOP(1) * FROM Users WHERE Username = @__username_0
坑：如果用EF Core的FromSqlRaw或ExecuteSqlRaw，必须用参数化，不能拼接字符串：
csharp

	// 错误示例：用FromSqlRaw拼接字符串，容易被注入
	var user = await _context.Users.FromSqlRaw($"SELECT * FROM Users WHERE Username='{username}'").FirstOrDefaultAsync();
	
	// 正确示例：用参数化
	var user = await _context.Users.FromSqlRaw("SELECT * FROM Users WHERE Username=@username", new SqlParameter("@username", username)).FirstOrDefaultAsync();

SQL注入的最佳实践
1.永远用参数化查询：不要用字符串拼接SQL，不管是ADO.NET还是EF Core；
2.最小权限原则：数据库用户只给必要的权限——比如查询用户表的权限，不要给删除、修改表的权限；
3.输入验证：验证用户输入的格式——比如用户名只能是字母、数字、下划线，长度不超过50；
4.定期扫描：用SQLMap、OWASP ZAP扫描网站，检测SQL注入漏洞；
5.日志监控：记录所有SQL查询，发现异常SQL（比如包含DROP、DELETE的查询）立即告警。
四、XSS攻击：“偷梁换柱”注入脚本，如何防？
XSS（跨站脚本攻击）是用户输入的脚本被浏览器执行，窃取用户Cookie、伪造用户操作——比如用户在评论区输入，如果网站直接输出评论内容，浏览器会执行这个脚本，弹出警告框。常见的XSS类型有：
反射型XSS：脚本在URL中，比如https://example.com/search?keyword=，网站直接输出keyword；
存储型XSS：脚本存在数据库中，比如评论区输入脚本，所有用户访问评论区都会执行；
DOM型XSS：脚本在前端DOM中执行，比如前端用document.write(location.search)，直接输出URL参数。
我踩过的坑：做电商网站时，评论区没过滤用户输入，用户输入，导致用户Cookie被窃取，账号被盗，损失了几十万订单！
实战1：输出编码，防XSS（ASP.NET Core自动编码）
ASP.NET Core的Razor视图、MVC控制器会自动对输出内容进行HTML编码，把<转成<，>转成>，脚本不会被执行：
csharp

	// MVC控制器，自动编码输出
	public IActionResult Index()
	{
	string comment = "<script>alert('XSS')</script>";
	return View(comment);
	}

Razor视图：

html 
	<!-- Razor视图，自动编码 -->
	<p>@Model</p>

输出的HTML是：

html 
<p>&lt;script&gt;alert('XSS')&lt;/script&gt;</p>

浏览器会显示，不会执行脚本。
手动编码：如果需要手动编码，用HttpUtility.HtmlEncode：
csharp
string encodedComment = HttpUtility.HtmlEncode("");
实战2：输入验证，防XSS（过滤危险字符）
输入验证是第一道防线——过滤用户输入的危险字符，比如<、>、script、onclick等：
csharp

	// 输入验证，过滤危险字符
	public bool ValidateComment(string comment)
	{
	// 禁止包含<script>、<iframe>、onclick等危险字符
	if (comment.Contains("<script>", StringComparison.OrdinalIgnoreCase) ||
	comment.Contains("<iframe>", StringComparison.OrdinalIgnoreCase) ||
	comment.Contains("onclick", StringComparison.OrdinalIgnoreCase))
	{
	return false;
	}
	// 限制长度，比如评论最多1000字
	return comment.Length <= 1000;
	}

富文本处理：如果需要支持富文本（比如博客、论坛），不要自己过滤，用成熟的富文本编辑器（比如TinyMCE、UEditor），编辑器会自动过滤危险标签，只允许安全的标签（比如

、、）。
实战3：CSP头，防XSS（浏览器层面防御）
CSP（内容安全策略）是浏览器的安全机制，限制浏览器加载的资源（比如JS、CSS、图片），防止执行未授权的脚本——即使XSS脚本被注入，浏览器也会阻止执行。ASP.NET Core配置CSP头：
csharp

	// Program.cs，配置CSP头
	app.Use(async (context, next) =>
	{
	// 配置CSP头，只允许加载自己域名的JS、CSS、图片，禁止内联脚本和eval
	context.Response.Headers.Add("Content-Security-Policy", 
	"default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;");
	await next();
	});

CSP指令说明：
default-src 'self'：默认只允许加载自己域名的资源；
script-src 'self'：只允许加载自己域名的JS，禁止内联脚本和eval；
style-src 'self'：只允许加载自己域名的CSS；
img-src 'self' data:：允许加载自己域名的图片和base64图片；
我踩过的坑：配置CSP头后，第三方脚本（比如百度统计、谷歌分析）无法加载——需要把第三方域名添加到CSP头，比如script-src 'self' https://hm.baidu.com;。
XSS防御的最佳实践
1.输出编码：ASP.NET Core自动编码，不要关闭自动编码；
2.输入验证：过滤危险字符，限制输入长度；
3.CSP头：配置严格的CSP头，禁止内联脚本和eval；
4.HttpOnly Cookie：把Cookie设置为HttpOnly，防止JS窃取Cookie；
5.定期扫描：用OWASP ZAP、Burp Suite扫描网站，检测XSS漏洞；
6.富文本处理：用成熟的富文本编辑器，不要自己过滤标签。
五、总结：三种攻击的防御对比

最佳实践：
1.分层防御：每种攻击都要多层防御，比如SQL注入用参数化查询+输入验证+最小权限；
2.自动化扫描：每周用OWASP ZAP、SQLMap扫描网站，检测漏洞；
3.监控告警：用ELK、Prometheus监控日志，发现异常请求（比如包含DROP、DELETE的SQL，包含


 本站原创，转载请注明出处：https://www.xin3721.com/ArticlecSharp/c49542.html