四种关键Web漏洞：SQL注入、XSS、CSRF与SSRF的攻防实战

1. 为什么偏偏是这四种漏洞做Web安全测试这几年我见过太多“看起来没毛病”的系统被打穿。有人问我如果只学四种漏洞应该先学哪些我每次给的答案都差不多SQL注入、XSS、CSRF、SSRF。这四个家伙覆盖了Web安全里最典型的四个维度——数据被篡改、前端被污染、请求被冒用、服务端被当枪使。SQL注入打的是数据库信任XSS打的是浏览器信任CSRF打的是会话信任SSRF打的是服务端自身的网络信任。把这四种吃透你就基本理解了Web攻击的主流套路攻击者永远在找“输入”和“信任”之间的缝隙。这篇文章没有高深的理论堆砌就是把我实际测过、踩过、修复过的经验拆开揉碎讲清楚。不管你是刚接触安全的新人还是写了几年代码想补安全课的后端工程师照着这篇文章的思路把每个漏洞的成因、判断方法、利用过程和修复方案过一遍都能建立起一套自己的排查脑图。2. SQL注入当参数变成代码2.1 先搞清楚漏洞到底怎么来的SQL注入的根源就一句话开发者把用户输入直接拼进了SQL语句让输入变成了代码的一部分。举个最典型的登录场景SELECT * FROM users WHERE username admin AND password 123456如果开发者图省事直接写$sql SELECT * FROM users WHERE username . $_POST[username] . AND password . $_POST[password] . ;攻击者在用户名里输入admin --拼出来的SQL就变成了SELECT * FROM users WHERE username admin -- AND password 123456注释符把后面的密码校验直接干掉了这就是最基础的万能密码绕过。很多新手以为SQL注入就是“在输入框塞个单引号”其实真正的核心是理解你在SQL语句解析之前改变了语句的语法结构。手动判断注入点的时候我一般走三步。第一步在参数后面加单引号看页面是否报错或者返回异常第二步加1 AND 11和1 AND 12对比两次返回内容是否不同第三步如果页面无回显就用时间盲注比如MySQL里输入1 AND SLEEP(5)看响应时间是否明显延迟。这里要特别提醒一点时间盲注的sleep时间别设太长。我见过有人用SLEEP(10)结果数据库连接池满了一半把自己测试环境搞挂了。常规情况下5秒足够判断而且对目标系统的影响也相对可控。2.2 参数化查询为什么能根治处理SQL注入的标准答案就是参数化查询Prepared Statement。它的原理很朴素先把SQL的骨架交给数据库编译之后传进来的参数永远只是“数据”不会被当作SQL代码解析。以Java为例正确写法是String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password);相当于先把“查询用户”这个动作固定下来用户名和密码只是填进表格里的内容哪怕填的是 OR 11 --数据库也只会把它当成一串字符去比对不会当代码执行。不过参数化查询也不是万能钥匙。表名、列名、排序字段ORDER BY因为无法用占位符替代仍然需要白名单校验。我就踩过这个坑——某次测试一个排序功能参数是sortprice开发者用参数化处理了值但排序列名是直接拼接的攻击者传了sort(SELECT...一样被注入。所以规则很简单凡是能参数化的数据一律参数化凡是不能参数化的结构部分必须白名单校验。2.3 细节里藏着翻车点SQL注入的利用大多建立在数据库报错或者页面回显上如果目标把报错信息全吞了就得靠盲注慢慢猜。猜解数据库版本、当前用户、表名、字段名这些过程网上教程很多我想重点说的是两个容易忽略的地方。第一个是编码问题。某些中间件对GBK编码处理不当攻击者输入%bf%27时宽字节会把%bf%27转成两个字节能识别的字符反而让转义函数失效。早年很多asp站点就是这么被打穿的。现在虽然少了但遇到老旧系统时还是要留个心眼。第二个是注入点不一定在参数里。Cookie、Referer、X-Forwarded-For这些请求头都可能被拼接进SQL。某次测试一个系统登录后的欢迎页把User-Agent存进了数据库用于展示我以为这是个存储型XSS点结果一测发现它直接拼进了后台查询语句——一个SQL注入藏在最不像参数的地方。所以排查时必须把所有输入都在心中过一遍哪些会被拼进SQL。修复建议其实不复杂参数化查询 最小权限数据库账号 隐藏报错信息。应用层做好了再给数据库账号按需授权只读账号就别给INSERT权限层层设防才算闭环。3. XSS前端防线为何频频失守3.1 先分清三类XSS再谈防御XSS的核心是“把恶意脚本塞进别人的浏览器”。我在实际测试中习惯先把目标分成三类反射型、存储型、DOM型。反射型最直观——恶意脚本放在URL参数里服务器把参数原样返回到页面浏览器就执行了。典型场景是搜索框搜索关键词没过滤就回显输入scriptalert(1)/script直接弹出弹窗。这类漏洞的危害看起来不大但结合过短链接伪装成正规站内链接钓鱼命中率非常高。存储型是这三类里危害最大的——恶意脚本被存在服务器上评论区、昵称、个人简介所有访问该页面的用户都会中招。我在某次测试中往一个公网论坛的签名档里塞了段脚本管理员登录后台时Cookie直接被偷走整个后台沦陷。存储型XSS最狠的地方在于不需要诱导用户点击特定链接只要他打开了正常页面就中招。DOM型XSS最隐蔽因为服务端完全不知情脚本在前端DOM操作时直接执行了。比如document.write(location.hash)这类代码一看就知道要出事——location.hash里的内容没经过任何过滤就塞进了DOM。检测这类XSS光靠看服务端返回的HTML是不够的得打开浏览器控制台观察前端JS怎么处理URL参数。3.2 输出编码与CSP才是正经防御防御XSS有个著名原则不要相信任何用户的输入。但实际落地时我更看重两个动作输出编码和CSP。输出编码的核心是区分“数据”和“代码”。用户提交的内容进入HTML上下文就做HTML实体编码变成lt;进入JavaScript上下文就做JS编码进入URL就做URL编码。很多开发者只做了入库过滤结果前端在script标签里直接内联输出参数照样被利用。下面是一个简单的编码示例function encodeHTML(str) { return str.replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;); }CSP内容安全策略是一道非常强的前端防线用响应头告诉浏览器“该加载哪些资源”。一个比较合理的初始配置是Content-Security-Policy: default-src self; script-src self; object-src none; base-uri none这几条规则的意思是资源默认只能从同源加载脚本也只在同源下执行禁止插件对象禁止修改页面基地址。配合HttpOnly的Cookie属性让JavaScript读不到Cookie即便脚本执行了攻击者也拿不到会话凭证危害直接降一个等级。我在自己测试的项目里见过太多CSP配置成script-src unsafe-inline的案例。这样等于告诉浏览器可以执行任意内联脚本前面写的CSP全白搭。如果业务确实需要内联脚本建议用nonce值每次响应生成随机值脚本标签带上对应nonce才能执行比直接放开安全得多。3.3 绕过的思路要提前摸清XSS的绕过手段五花八门但核心思路就一个绕过你设下的过滤规则。过滤了script标签就试img标签的onerror事件过滤了字符串就用编码和拼接变着法子还原。比如img srcx onerroralert(1)svg/onloadalert(1)a hrefjavascript:alert(1)点击/a我在排查时不会只搜script、alert这些关键词而是把所有“可以被浏览器当作代码执行”的标签和事件都列一遍。语义化的过滤解析HTML DOM后按白名单标签放行比字符串匹配要靠谱得多但也复杂得多——这就是为什么现在很多团队直接上第三方富文本过滤库不要自己造轮子。4. CSRF一个请求引发的“代下单”4.1 攻击原理与Token防线CSRF跨站请求伪造利用的是服务器“无法分辨请求是谁发起的”。你在浏览器里登录了A银行浏览器带着你的Cookie去访问A银行的转账接口服务器看到Cookie有效就认为是你在操作——但如果这个请求来自某个恶意网站呢攻击者构造一个自动提交的表单或img标签让受害者浏览器去请求A银行的转账接口。Cookie会自动带上服务器照样信任钱就转走了。整个攻击过程中攻击者不需要拿到你的Cookie他只需要一个“会携带你Cookie的请求”。防御CSRF最常见的手段是Token校验服务端在渲染表单时生成一个随机Token存在Session里提交时校验Token是否一致。因为Token藏在页面里跨站请求无法获取自然就校验不过。但这里有个容易踩的坑Token一定要绑定Session不能放在Cookie里而且要设置好有效期。我见过某个系统把Token写在Cookie里攻击者虽然读不到Cookie内容但通过某些手段把Token值“反射”到请求参数中照样绕过了校验。正确的做法是Token放在表单隐藏域或请求头里每次会话生成新值服务端对比Session中的副本。此外现在主流浏览器支持的SameSite Cookie属性也很有用。设置SameSiteLax或SameSiteStrict可以限制Cookie在跨站请求中携带。不过这个属性依赖浏览器支持而且对老版本浏览器无效所以不能完全取代Token机制只能作为辅助防线。4.2 从检测到修复的完整动作检测CSRF时我通常先找“状态改变型”接口修改密码、转账、改邮箱、发帖删除。只要这些接口的请求参数里没有不可预测的Token基本就能判定存在CSRF风险。一个简单的验证方法在浏览器无痕窗口登录目标站点打开开发者工具找到敏感接口的请求用Burp Suite生成一个跨站请求的PoC把PoC放到自己的测试服务器上用另一个浏览器访问测试服务器上的页面看目标站点是否被触发。如果触发了就说明防护缺失。修复CSRF的正确姿势是“多层防御”最重要的一层是同步Token校验其次是SameSite Cookie作为兜底再配合关键的Referer校验但不能完全依赖因为Referer有时会为空或可伪造。这三个一起上CSRF基本就废了。实际修复时还有一个细节容易被忽略所有状态改变请求都必须用POST。GET请求不能产生副作用这是HTTP规范里的基本要求但很多团队为了图省事用GET调删除接口这在CSRF面前等于城门大开。某次看到一个后台的导出功能用GET请求导出全量用户数据攻击者只需要诱导管理员点击一个图片链接数据就发走了。5. SSRF服务端出了趟不该出的门5.1 利用点在哪儿SSRF服务端请求伪造是我测评时最头疼也最兴奋的漏洞类型因为它的影响范围太不可控了。核心成因是服务端接收了用户可控的URL然后以服务端的身份去请求这个URL。也就是说攻击者借了服务器的“网络身份”去访问服务器本身无法直接访问的内网资源。典型的触发点有这些图片上传时填远程URL、导入功能支持URL、Webhook回调地址、PDF生成器抓取网页、各种网页截图服务。你在这些功能里填一个http://127.0.0.1:8080如果服务器真的去请求了SSRF就有戏了。我遇到过一个挺经典的案例某个在线文档功能支持“通过URL导入图片”我填了http://192.168.1.1:22虽然没直接连上但通过响应时间差异摸清了内网网段里哪些主机在线。更进一步如果目标存在HTTP服务还能配合其他已知漏洞直接打进内网。SSRF的利用分好几层。第一层是内网探测——用不同IP和端口试看响应时间、错误页面的差异画出内网资产地图。第二层是直接访问云元数据服务。在云环境里服务端通过http://169.254.169.254/latest/meta-data/这个地址可以获取实例的临时凭据拿到凭据就相当于拿到了云账号的一部分权限。第三层是利用file://、dict://等非HTTP协议读取本地文件或探测端口信息。不同语言和环境支持的协议差异很大测试的时候多试几种总没错。5.2 防绕过的关键点SSRF修复的难点在于“看似防了其实一绕就开”。常见的错误操作是只过滤了127.0.0.1和localhost但攻击者换0.0.0.0、[::1]、十进制IP2130706433或者加个符号http://evil.com127.0.0.1就绕过去了。这些绕法我都实测过——单纯的黑名单根本堵不住。正确的思路是白名单 解析校验。白名单只允许请求指定域名或IP其他一律拒绝同时一个可靠的SSRF防护应当做到解析最终IP、判断是否内网地址、限制端口、限制协议。我在某次测试中看到开发做了内网IP判断但是拿用户传入的URL直接正则匹配压根没解析DNS——传http://127.0.0.1.nip.io这种域名直接解析到127.0.0.1匹配的是域名后缀放行了。比较扎实的做法是先解析出真实的IP地址再判断IP是否属于内网段10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.0/8端口用白名单只允许80/443协议只准HTTP/HTTPS最后要留意DNS重绑定的问题——第一次解析是公网IP通过了校验第二次解析变成内网IP攻击就这么进来了。解决方式是二次解析并对两次IP做一致性校验或者直接跟随重定向时再次校验。6. 手把手梳理你的排查流程6.1 信息收集决定了一半的成功率很多人拿到目标就急着测漏洞结果测了半天发现连参数都没找齐。我自己的习惯是先花30%的时间做信息收集先把功能点枚举完整再逐项测试。具体动作是抓全所有请求包括静态资源和接口文档按功能模块分类列出所有参数尤其是隐藏参数和可控请求头标注出用户输入会进入什么后端逻辑SQL查询、页面渲染、外部请求、文件操作。这张清单做完漏洞面基本就在眼前了。比如看到一个URL导入功能先记下来“此处可能SSRF”看到一个搜索接口先记下来“此处可能SQL注入或XSS”。后面测试时直接从清单挑效率高得多。信息收集时我特别建议留意Web目录下方的备份文件、测试接口、Swagger文档。某次渗透测试中我直接在目标根目录找到了开放的API文档页面接口定义写得清清楚楚连鉴权字段都标注了“暂未启用”。这不比盲猜高效多了但要注意这类接口通常需要在授权范围内测试别越界。6.2 工具能加速但替代不了判断工欲善其事必先利其器。我常用的测试工具大概三类抓包工具有Burp Suite我主力用的、Charles扫描器有AWVS、Xray或者更轻量的漏扫脚本辅助工具有SQLMap注意SQLMap的检测能力很强但要谨慎使用避免对目标造成过大负载、Nuclei模板扫描。我个人会把扫描器当“穷举员”来用让它先把常见漏洞筛一遍然后针对可疑点做手工验证。完全依赖扫描器是不可取的——扫描器漏报太常见了尤其是逻辑漏洞和需要上下文判断的漏洞类型。日常测试时我会先开抓包工具保持流量可视再跑扫描器做广撒网最后手工验证。遇到可疑参数就逐个尝试先试语法类错误SQL注入、XSS的基本payload再试逻辑类绕过越权、参数篡改最后才是更复杂的组合利用。每一步都记得观察响应变化做好记录——测试记录完整写报告的时候才知道当时为什么这么操作。还有一个心得测试过程中的问题排查不能只靠单一的调试工具。比如盲注时响应时间不稳定可能不是注入了而是网络波动。这时候就要多次测、取平均甚至画个时间分布曲线来判断。谨慎和耐心是渗透测试的基本功。最后说两句我的体会四种漏洞聊完了最后分享一点个人经验。我入行这几年最大的感触是漏洞的本质往往不是“代码写错了”而是“信任关系放错了位置”。SQL注入是错信了用户输入不会变成代码XSS是错信了用户内容不会变成脚本CSRF是错信了Cookie带上的请求就是用户本人在操作SSRF是错信了服务端发出的请求一定安全无害。理解了这一层再看任何代码都会有一种“挑毛病”的直觉。新手建议先啃SQL注入和XSS因为这两类漏洞的靶场多、资料全、反馈直接比较容易建立正反馈等有手感了再攻CSRF和SSRF这两类更考验综合理解能力。测试的时候一定要记得记录每一个判断依据踩坑越多记性越深。保持好奇保持动手这些套路你总会摸透的。