1. 项目概述从两个“请求伪造”说起在Web安全领域有两个名字听起来很像原理却截然不同的“兄弟”漏洞CSRF和SSRF。CSRF跨站请求伪造和SSRF服务器端请求伪造它们都利用了“请求伪造”这一核心概念但攻击的发起点和目标对象完全不同。对于刚入门安全测试、开发或者运维的朋友来说很容易被这两个缩写搞混。我见过不少项目开发团队知道要防CSRF却对SSRF的威胁一无所知直到内网被渗透了才追悔莫及。这篇文章我们就来一次彻底的“解剖式”对比。我不会只给你干巴巴的定义而是会结合我这些年做渗透测试和代码审计的实际案例把这两个漏洞的产生原理、利用场景、挖掘手法、修复方案掰开揉碎了讲清楚。你会发现理解它们的关键不在于死记硬背概念而在于搞清楚“请求”的源头和目的地究竟是谁。无论你是想加固自己的应用还是准备投身安全研究这份对比指南都能帮你建立起清晰的认知框架避免在实战中踩坑。2. 核心原理与攻击视角深度对比要真正理解CSRF和SSRF必须从攻击者的视角来看待一次完整的HTTP请求。一个请求包含几个关键要素谁发的来源、发给谁目标、内容是什么请求体。这两个漏洞的差异就藏在这几个要素的错位之中。2.1 CSRF欺骗用户的浏览器“代劳”CSRF的本质是攻击者欺骗用户的浏览器让浏览器以用户的名义向目标网站发送一个恶意请求。我们来还原一下攻击场景前提用户已经登录了银行网站bank.com浏览器里保存了有效的登录会话Cookie。陷阱用户在不经意间访问了攻击者控制的恶意网站evil.com。攻击evil.com的页面上隐藏着一个自动提交的表单或者一个img src...标签其指向的地址是bank.com/transfer?toattackeramount10000。结果用户的浏览器在访问evil.com时会自动向bank.com发起这个转账请求。由于浏览器会自动携带bank.com的Cookie服务器看到这个带有合法会话的请求便认为是用户本人的操作从而执行转账。核心要点攻击发起端用户的浏览器。攻击者无法直接拿到用户的Cookie而是利用浏览器自动携带Cookie的机制。请求目标用户已经认证过的其他网站如bank.com。攻击者能控制什么主要是请求的URL包括参数和部分Header如Referer、Origin但无法控制Cookie。攻击者像一个“导演”编写了“剧本”恶意请求诱骗“演员”用户的浏览器去执行。类比这就像你用户的秘书浏览器认得你的签名Cookie。攻击者伪造了一份有你签名的文件恶意请求然后骗你的秘书把这份文件送到了银行。银行看到签名就执行了秘书和银行都不知道文件内容被调包了。2.2 SSRF把服务器变成攻击跳板SSRF的本质是攻击者诱使应用服务器后端自身向一个内部或外部的指定地址发起一个恶意请求。同样还原一个典型场景前提一个Web应用提供了一个功能让用户输入一个URL应用会去抓取这个URL的内容并显示例如一个“转码/下载”功能一个“设置头像来自网络URL”的功能。攻击攻击者不输入一个正常的外网图片地址而是输入http://169.254.169.254/latest/meta-data/这是一个AWS云平台元数据服务的内部地址通常只有云服务器自身能访问。结果应用服务器后端代码执行了这个请求去访问了内部的元数据接口并将获取到的敏感信息如临时密钥返回给了攻击者。核心要点攻击发起端受害的Web应用服务器本身。攻击者的输入被服务器当成指令执行了。请求目标服务器能够访问到的任何网络资源。这包括服务器本机127.0.0.1,localhost内部网络的其他系统192.168.1.1,10.0.0.1云服务的元数据接口169.254.169.254外部互联网上的任意地址攻击者自己的服务器用于数据回传。攻击者能控制什么整个请求的目标地址和部分内容。由于请求是从服务器网络环境发起的它可以访问到浏览器无法直接触及的内网服务。攻击者像一个“傀儡师”控制了“傀儡”服务器的手臂让它去触碰一些本不该碰的东西。类比这就像你用户给公司的前台Web应用打电话说“请帮我把会议室里那份标着‘机密’的文件传真到这个外部号码攻击者控制”。前台服务器照做了因为它有权限进入会议室内网但它没意识到这个指令是恶意的。2.3 一张图看清本质区别为了更直观我们可以用下面的表格来总结对比维度CSRF (跨站请求伪造)SSRF (服务器端请求伪造)攻击英文全称Cross-Site Request ForgeryServer-Side Request Forgery漏洞存在位置存在业务逻辑缺陷的Web应用存在不安全网络请求的Web应用后端攻击发起者被诱骗的用户浏览器被利用的Web应用服务器攻击目标用户已登录的另一个Web应用服务器能访问的任何内网/本地服务或特定外网地址利用条件1. 用户已登录目标站点2. 目标站点存在可预测/未防护的敏感操作端点3. 用户访问了恶意页面1. 应用提供从用户输入发起服务器请求的功能2. 对用户输入的URL未做严格过滤与限制攻击者视角“我如何让用户的浏览器帮我发请求”“我如何让对方的服务器帮我发请求”危害核心以用户身份执行非授权操作转账、改密、发帖。穿透网络边界探测或攻击内网服务读取本地文件、攻击数据库、获取云元数据。注意一个关键区别在于网络位置。在CSRF中攻击者、用户浏览器、目标网站通常都在互联网上。而在SSRF中攻击者在外网他利用的“跳板”服务器和内网目标可能处于同一个受信任的网络区域。3. 漏洞挖掘与利用手法实战拆解知道了原理我们来看看在实战中如何发现并利用这两种漏洞。这部分我会结合常见场景和我的测试经验给出具体的思路和案例。3.1 CSRF漏洞的挖掘与利用CSRF的挖掘核心是寻找那些执行了敏感操作却没有足够防护机制的HTTP端点。1. 漏洞点寻找关键操作关注所有会改变系统状态或数据的GET/POST请求。例如修改密码、修改邮箱、转账、发表评论、添加管理员、上传文件如果依赖Cookie认证等。请求特征这些请求通常只依赖会话Cookie进行身份认证没有其他不可预测的令牌Token并且参数是可猜测的。工具辅助使用Burp Suite等代理工具拦截所有请求重点筛选那些不含CSRF-Token、X-CSRF-TOKEN等自定义Header且不是multipart/form-data可能隐含Token的敏感操作请求。2. 利用POC构造一旦找到一个疑似漏洞点例如POST /change_email参数为new_emailattackerevil.com就可以构造攻击页面。示例一个最简单的自动提交表单POC!DOCTYPE html html body !-- 隐藏表单指向目标站点 -- form idcsrfForm actionhttps://vulnerable-site.com/change_email methodPOST input typehidden namenew_email valuehackerevil.com / /form script // 页面加载后自动提交表单 document.getElementById(csrfForm).submit(); /script /body /html攻击者将上述HTML托管在evil.com诱使已登录vulnerable-site.com的用户访问其邮箱就会被悄无声息地修改。3. 绕过常见防护的进阶技巧检查Referer Header有些应用会检查请求的Referer头是否来源于本站。可以尝试利用Flash、浏览器插件或特定JS技巧发起请求可能不发送或能篡改Referer。使用data:协议或about:blank作为攻击页面源某些浏览器的Referer行为可能不同。如果网站只检查Referer的“域名”部分可以尝试子域名攻击如attacker.vulnerable-site.com。简单的Token验证如果Token只是放在表单隐藏域且未与会话绑定攻击者可以先发起一个GET请求到表单页解析出Token再用于构造恶意POST请求。这需要攻击页面能发起AJAX并解析响应受同源策略限制但若目标站点存在JSONP接口或CORS配置错误则可能实现。实操心得在实际测试中不要只盯着“修改”操作。一些“获取”操作也可能造成危害比如“导出所有数据”功能如果通过GET请求触发且无防护攻击者可以构造一个img src/export_data标签导致用户浏览器在后台触发数据导出泄露敏感信息。3.2 SSRF漏洞的挖掘与利用SSRF的挖掘核心是寻找应用中所有将用户输入转换为后端网络请求的地方。1. 漏洞点寻找常见功能场景URL加载/预览/下载头像设置、文章封面图、富文本编辑器中的“插入网络图片”、文档/视频在线转码、URL缩短服务、爬虫分析服务。Webhook或回调功能支付回调、第三方登录回调、消息通知回调。攻击者可能控制回调的URL参数。内部接口代理某些应用为了前端方便会提供代理接口如/proxy?urlhttps://external-resource.com。文件处理相关从URL导入文档如word、excel、XML解析可能引发XXE进而导致SSRF、PDF生成器读取远程URL。社交媒体分享预览输入一个URL后端去抓取该URL的标题和缩略图。2. 利用手法与协议利用SSRF的威力很大程度上取决于后端服务器使用的网络请求库如curl、requests支持哪些URL协议。基础信息探测# 探测内网存活主机和端口 http://192.168.1.1:8080 http://10.0.0.1:22 # 读取本地文件file协议 file:///etc/passwd # 访问云元数据经典案例 http://169.254.169.254/latest/meta-data/ http://metadata.google.internal/computeMetadata/v1/利用Gopher/Redis协议攻击内网服务如果后端支持gopher://协议攻击者可以构造特殊的Payload直接与内网的Redis、Memcached、MySQL等未授权或弱密码服务进行交互实现命令执行或数据窃取。这是SSRF危害升级的关键。例如向内网Redis发送一条SET命令将计划任务crontab写入目标服务器从而获取shell。利用HTTP协议进行端口扫描和指纹识别通过观察请求的响应时间、错误信息、返回内容可以判断内网端口开放情况和服务类型。3. 绕过过滤技巧开发人员可能会对输入进行一些简单的过滤如黑名单127.0.0.1、localhost或要求必须以http://开头。IP地址变形十进制IPhttp://2130706433等价于127.0.0.1八进制IPhttp://0177.0.0.1等价于127.0.0.1十六进制IPhttp://0x7f.0x0.0x0.0x1省略部分http://127.1、http://127.0.1域名重定向攻击者控制一个域名evil.com将其A记录指向127.0.0.1然后提交http://evil.com。利用URL缩短服务或可设置重定向的网站如https://redirect.example.com?targethttp://127.0.0.1。利用URL解析差异在URL中加入符号http://expected-hostevil-host。某些旧库或错误配置可能只解析之前的部分作为认证信息实际请求evil-host。利用#片段标识符http://expected-host#evil-host。同样解析差异可能导致目标错误。实操心得测试SSRF时一定要用Burp Suite的Collaborator功能或自己搭建一个带公网IP的监听服务器如用nc -lvp 80。将Collaborator生成的域名作为Payload输入如果能收到来自目标服务器的DNS查询或HTTP请求就铁证如山地证明了SSRF漏洞的存在并且能了解到服务器出网的IP、User-Agent等信息。4. 防御方案设计与代码层面实现理解了攻击防御就有了方向。防御的核心思想都是“验证请求的真实意图”。4.1 CSRF的防御方案CSRF防御的核心是让攻击者无法构造出合法的请求。1. 同步令牌Synchronizer Token Pattern最有效原理在用户会话中生成一个随机、不可预测的Token如CSRF Token。在渲染任何包含状态修改表单的页面时将此Token放入表单的隐藏域。当表单提交时服务器验证提交的Token是否与会话中存储的Token一致。实现要点每个会话或每个请求一个Token推荐每个请求使用独立Token但需注意并发问题。至少保证每个会话的Token是唯一的。Token需保密且随机使用安全的随机数生成器如java.security.SecureRandom。Token绑定到会话将Token存储在服务器端Session中或使用加密的Cookie需防重放攻击。对敏感GET请求也需防护严格来说任何会改变状态的请求都应使用POST/PUT/DELETE并对它们实施Token验证。如果非要用GETToken可以放在URL参数中但存在被日志记录泄露的风险。代码示例Spring Security 视角 Spring Security默认就提供了CSRF防护。它会自动生成一个Token名为_csrf存储在Session和请求属性中。在Thymeleaf模板中表单会自动添加input typehidden name_csrf th:value${_csrf.token} /对于AJAX请求你需要将Token放在Header中通常是X-CSRF-TOKEN。2. 同源检测检查Referer/Origin Header原理服务器检查请求头中的Origin或Referer字段判断其来源是否与本站的域名一致。优点实现简单。缺点用户隐私设置或浏览器可能不发送这些头。Referer可能被篡改虽然浏览器层面较难。需要小心处理来源为空的情况比如从本地文件打开或HTTPS跳到HTTP时避免误杀合法请求。建议作为辅助手段与Token机制结合使用提供深度防御。3. 自定义请求头原理通过JavaScript在前端为所有异步请求如通过Fetch/Axios发起的添加一个自定义Header如X-Requested-With: XMLHttpRequest。由于浏览器同源策略的限制攻击者无法通过form或img标签来添加自定义Header。优点对于纯API的前后端分离应用实现方便。缺点仅能防护非简单请求CORS规范中的“非简单请求”。如果API允许简单请求GET、POST且Content-Type为application/x-www-form-urlencoded,multipart/form-data,text/plain此方法失效。因此不能作为唯一防御手段。注意事项千万不要使用GET请求来进行状态修改操作这是防御CSRF的最基本前提。同时要确保登录会话有合理的超时时间并提供明显的“退出登录”功能减少攻击窗口期。4.2 SSRF的防御方案SSRF防御的核心是对用户提供的URL进行严格的白名单控制和访问限制。1. 输入验证与过滤黑名单不足需结合白名单绝对不要仅用黑名单禁止127.0.0.1、localhost、192.168.*、10.*、172.(16-31).*、169.254.*等内网地址段是基础但如前所述有大量绕过手法。建立严格的白名单如果业务功能明确如只允许抓取指定几个图片CDN的图片则只允许这些域名或IP。域名白名单解析用户输入的URL得到主机名与白名单列表匹配。IP白名单将主机名解析为IP地址检查该IP是否在允许的公共IP范围内并拒绝任何私有IPRFC 1918、回环地址、链路本地地址等。代码示例Python - 使用urllib.parse和socketfrom urllib.parse import urlparse import socket import ipaddress def is_allowed_url(user_input_url, allowed_domains): try: parsed urlparse(user_input_url) hostname parsed.hostname # 1. 检查协议只允许http/https if parsed.scheme not in (http, https): return False, Protocol not allowed # 2. 解析主机名到IP ip socket.gethostbyname(hostname) # 3. 检查IP是否为内网地址 ip_obj ipaddress.ip_address(ip) if ip_obj.is_private or ip_obj.is_loopback or ip_obj.is_link_local: return False, Internal IP address not allowed # 4. (可选) 检查域名是否在白名单内 if allowed_domains and hostname not in allowed_domains: return False, Domain not in whitelist # 5. (可选) 检查端口是否在允许范围如只允许80, 443 if parsed.port and parsed.port not in (80, 443, None): return False, Port not allowed return True, OK except Exception as e: return False, fURL validation error: {e}2. 网络层访问控制出站防火墙规则在服务器或容器级别配置严格的出站防火墙规则。只允许应用服务器访问其业务必需的外部服务和特定的公网IP/端口禁止访问整个内网段如10.0.0.0/8和回环地址。使用独立的网络命名空间或容器将存在SSRF风险的服务部署在独立的、网络受限的容器或虚拟机中其网络访问能力被严格限制。3. 请求处理安全禁用危险的URL协议在发起请求的客户端库如curl、requests配置中显式禁用file://、gopher://、dict://、ftp://等非必要且高风险的协议。在PHP中注意curl和file_get_contents对协议的支持在Java中注意URLConnection和HttpClient的配置。设置请求超时和重定向限制避免攻击者利用请求进行端口扫描长超时或通过重定向链绕过过滤。# Python requests 示例 import requests from requests.packages.urllib3.exceptions import InsecureRequestWarning requests.packages.urllib3.disable_warnings(InsecureRequestWarning) session requests.Session() # 禁用重定向或严格限制重定向次数 session.max_redirects 2 # 设置超时 try: response session.get(validated_url, timeout(3, 10), verifyFalse) # 连接超时3秒读取超时10秒 except requests.exceptions.Timeout: # 处理超时 pass使用主机名而非IP发起请求如果业务允许强制使用域名并在解析后对IP进行严格的过滤这比直接处理用户输入的IP地址更安全。4. 响应处理安全不要将原始响应直接返回给前端对于“URL预览”类功能后端获取内容后应只提取需要的文本摘要和安全的缩略图经过二次处理而不是将整个HTTP响应体可能包含内网服务的敏感HTML/JSON原样返回。内容类型检查确保获取的内容是期望的类型如图片可以通过检查Content-TypeHeader和文件魔数magic number来实现。实操心得防御SSRF最有效的方法是“默认拒绝最小化允许”。在设计任何需要从用户输入发起网络请求的功能时都要问自己这个功能真的有必要吗能否用其他方式替代如果必须要有那么允许访问的范围必须缩小到业务绝对需要的最小集合。同时在代码审计时要重点关注所有调用了HttpClient、curl、requests、URLConnection等网络库的地方追踪其参数是否用户可控。5. 测试、排查与进阶思考5.1 如何系统性地测试这两种漏洞针对CSRF的测试清单枚举敏感操作使用爬虫如Burp的Scanner或手动浏览列出所有修改状态的请求POST/PUT/DELETE及危险的GET。检查防护令牌对于每个敏感请求检查其请求参数或Header中是否存在随机Token如csrf_token,_csrf。尝试移除或修改该Token看请求是否依然成功。验证Token绑定如果存在Token用两个不同的用户会话获取Token尝试交叉使用验证Token是否与会话绑定。检查同源策略尝试从不同的Origin或Referer发起请求观察是否被拒绝。自动化工具使用Burp Suite的CSRF Scanner插件或类似工具进行辅助扫描。针对SSRF的测试清单功能点枚举寻找所有接受URL作为输入的功能点。基础探测输入一个你控制的公网服务器地址或Burp Collaborator域名确认后端是否发起了请求。内部地址探测尝试http://127.0.0.1:80、http://localhost/admin、http://169.254.169.254/、http://192.168.1.1:8080等。协议尝试尝试file:///etc/passwd、gopher://、dict://等取决于后端环境。绕过尝试对存在基础过滤的点尝试使用前述的IP变形、域名重定向、URL解析差异等方法进行绕过。端口扫描通过观察响应时间差异或错误信息尝试探测内网常见端口22, 80, 443, 3306, 6379等。5.2 常见问题与排查实录Q1我们用了Spring Security是不是就高枕无忧了ASpring Security默认开启了CSRF防护但它主要防护的是基于Session和Thymeleaf/JSP表单的场景。对于纯REST API使用JSON无Session你需要明确配置CSRF防护策略或者根据业务情况考虑禁用并采用其他如JWT等无状态认证方案此时需评估CSRF风险。同时要确保你的登出接口、文件上传接口等也被正确防护。Q2SSRF漏洞似乎只能访问内网危害不大A这是非常危险的误解。SSRF的危害极大云环境杀手直接访问云元数据服务获取临时密钥接管整个云主机甚至整个账户资源。内网渗透跳板攻击内网的Redis、MySQL、Jenkins、Consul等管理界面若存在未授权或弱口令可导致远程代码执行RCE。攻击本地服务访问127.0.0.1上的管理接口如php-fpmstatus page,memcachedstats可能造成信息泄露或进一步利用。Q3我们的服务都在Kubernetes里SSRF是不是更危险A是的。Kubernetes Pod默认可以访问Kubernetes API Server通常位于https://kubernetes.default.svc。如果攻击者通过SSRF访问到API Server并且Pod挂载了Service Account Token攻击者可能拥有该Pod的权限从而在集群内进行横向移动危害整个集群。防御时必须为Pod配置最小权限的Service Account并限制其对API Server的访问。Q4CSRF Token放在Cookie里Double Submit Cookie安全吗A这是一种常见方案前后端分离时常用。将Token放在Cookie中前端JS读取后放入请求Header或参数。它的安全性基于攻击者无法读取或伪造Cookie受同源策略保护。但需注意必须设置Cookie为HttpOnlyfalse以便JS读取。必须防范XSS漏洞因为一旦存在XSS攻击者脚本可以轻易读取Cookie中的Token使CSRF防护失效。因此防御CSRF的前提是已经做好了XSS的防护。5.3 进阶思考漏洞的组合利用在实际渗透中漏洞很少单独存在。CSRF和SSRF常与其他漏洞形成“组合拳”XSS CSRF如果网站存在存储型XSS攻击者可以注入恶意脚本该脚本在所有访问该页面的用户浏览器中执行不仅能窃取数据还能直接发起CSRF请求因为脚本在同源下可以读取Token从而完全绕过CSRF防护。SSRF Redis未授权访问通过SSRF攻击内网的Redis利用Redis协议写入Webshell或计划任务是获取服务器权限的经典路径。SSRF 文件读取file协议如果后端支持file://协议SSRF可直接读取服务器上的敏感配置文件如/proc/self/environ、/etc/passwd、应用程序配置文件为后续攻击提供信息。理解这些关联性能帮助我们在防御时建立更立体的安全观。安全是一个链条最薄弱的一环决定了整体的强度。对于开发者和安全工程师而言透彻理解CSRF和SSRF这对“请求伪造”兄弟的原理与差异是构建健壮Web应用安全防线的必修课。从代码编写的第一行起就带着对用户输入的不信任对每一次网络请求都保持警惕才能从根本上减少这类漏洞的产生。
1. 项目概述从两个“请求伪造”说起在Web安全领域有两个名字听起来很像原理却截然不同的“兄弟”漏洞CSRF和SSRF。CSRF跨站请求伪造和SSRF服务器端请求伪造它们都利用了“请求伪造”这一核心概念但攻击的发起点和目标对象完全不同。对于刚入门安全测试、开发或者运维的朋友来说很容易被这两个缩写搞混。我见过不少项目开发团队知道要防CSRF却对SSRF的威胁一无所知直到内网被渗透了才追悔莫及。这篇文章我们就来一次彻底的“解剖式”对比。我不会只给你干巴巴的定义而是会结合我这些年做渗透测试和代码审计的实际案例把这两个漏洞的产生原理、利用场景、挖掘手法、修复方案掰开揉碎了讲清楚。你会发现理解它们的关键不在于死记硬背概念而在于搞清楚“请求”的源头和目的地究竟是谁。无论你是想加固自己的应用还是准备投身安全研究这份对比指南都能帮你建立起清晰的认知框架避免在实战中踩坑。2. 核心原理与攻击视角深度对比要真正理解CSRF和SSRF必须从攻击者的视角来看待一次完整的HTTP请求。一个请求包含几个关键要素谁发的来源、发给谁目标、内容是什么请求体。这两个漏洞的差异就藏在这几个要素的错位之中。2.1 CSRF欺骗用户的浏览器“代劳”CSRF的本质是攻击者欺骗用户的浏览器让浏览器以用户的名义向目标网站发送一个恶意请求。我们来还原一下攻击场景前提用户已经登录了银行网站bank.com浏览器里保存了有效的登录会话Cookie。陷阱用户在不经意间访问了攻击者控制的恶意网站evil.com。攻击evil.com的页面上隐藏着一个自动提交的表单或者一个img src...标签其指向的地址是bank.com/transfer?toattackeramount10000。结果用户的浏览器在访问evil.com时会自动向bank.com发起这个转账请求。由于浏览器会自动携带bank.com的Cookie服务器看到这个带有合法会话的请求便认为是用户本人的操作从而执行转账。核心要点攻击发起端用户的浏览器。攻击者无法直接拿到用户的Cookie而是利用浏览器自动携带Cookie的机制。请求目标用户已经认证过的其他网站如bank.com。攻击者能控制什么主要是请求的URL包括参数和部分Header如Referer、Origin但无法控制Cookie。攻击者像一个“导演”编写了“剧本”恶意请求诱骗“演员”用户的浏览器去执行。类比这就像你用户的秘书浏览器认得你的签名Cookie。攻击者伪造了一份有你签名的文件恶意请求然后骗你的秘书把这份文件送到了银行。银行看到签名就执行了秘书和银行都不知道文件内容被调包了。2.2 SSRF把服务器变成攻击跳板SSRF的本质是攻击者诱使应用服务器后端自身向一个内部或外部的指定地址发起一个恶意请求。同样还原一个典型场景前提一个Web应用提供了一个功能让用户输入一个URL应用会去抓取这个URL的内容并显示例如一个“转码/下载”功能一个“设置头像来自网络URL”的功能。攻击攻击者不输入一个正常的外网图片地址而是输入http://169.254.169.254/latest/meta-data/这是一个AWS云平台元数据服务的内部地址通常只有云服务器自身能访问。结果应用服务器后端代码执行了这个请求去访问了内部的元数据接口并将获取到的敏感信息如临时密钥返回给了攻击者。核心要点攻击发起端受害的Web应用服务器本身。攻击者的输入被服务器当成指令执行了。请求目标服务器能够访问到的任何网络资源。这包括服务器本机127.0.0.1,localhost内部网络的其他系统192.168.1.1,10.0.0.1云服务的元数据接口169.254.169.254外部互联网上的任意地址攻击者自己的服务器用于数据回传。攻击者能控制什么整个请求的目标地址和部分内容。由于请求是从服务器网络环境发起的它可以访问到浏览器无法直接触及的内网服务。攻击者像一个“傀儡师”控制了“傀儡”服务器的手臂让它去触碰一些本不该碰的东西。类比这就像你用户给公司的前台Web应用打电话说“请帮我把会议室里那份标着‘机密’的文件传真到这个外部号码攻击者控制”。前台服务器照做了因为它有权限进入会议室内网但它没意识到这个指令是恶意的。2.3 一张图看清本质区别为了更直观我们可以用下面的表格来总结对比维度CSRF (跨站请求伪造)SSRF (服务器端请求伪造)攻击英文全称Cross-Site Request ForgeryServer-Side Request Forgery漏洞存在位置存在业务逻辑缺陷的Web应用存在不安全网络请求的Web应用后端攻击发起者被诱骗的用户浏览器被利用的Web应用服务器攻击目标用户已登录的另一个Web应用服务器能访问的任何内网/本地服务或特定外网地址利用条件1. 用户已登录目标站点2. 目标站点存在可预测/未防护的敏感操作端点3. 用户访问了恶意页面1. 应用提供从用户输入发起服务器请求的功能2. 对用户输入的URL未做严格过滤与限制攻击者视角“我如何让用户的浏览器帮我发请求”“我如何让对方的服务器帮我发请求”危害核心以用户身份执行非授权操作转账、改密、发帖。穿透网络边界探测或攻击内网服务读取本地文件、攻击数据库、获取云元数据。注意一个关键区别在于网络位置。在CSRF中攻击者、用户浏览器、目标网站通常都在互联网上。而在SSRF中攻击者在外网他利用的“跳板”服务器和内网目标可能处于同一个受信任的网络区域。3. 漏洞挖掘与利用手法实战拆解知道了原理我们来看看在实战中如何发现并利用这两种漏洞。这部分我会结合常见场景和我的测试经验给出具体的思路和案例。3.1 CSRF漏洞的挖掘与利用CSRF的挖掘核心是寻找那些执行了敏感操作却没有足够防护机制的HTTP端点。1. 漏洞点寻找关键操作关注所有会改变系统状态或数据的GET/POST请求。例如修改密码、修改邮箱、转账、发表评论、添加管理员、上传文件如果依赖Cookie认证等。请求特征这些请求通常只依赖会话Cookie进行身份认证没有其他不可预测的令牌Token并且参数是可猜测的。工具辅助使用Burp Suite等代理工具拦截所有请求重点筛选那些不含CSRF-Token、X-CSRF-TOKEN等自定义Header且不是multipart/form-data可能隐含Token的敏感操作请求。2. 利用POC构造一旦找到一个疑似漏洞点例如POST /change_email参数为new_emailattackerevil.com就可以构造攻击页面。示例一个最简单的自动提交表单POC!DOCTYPE html html body !-- 隐藏表单指向目标站点 -- form idcsrfForm actionhttps://vulnerable-site.com/change_email methodPOST input typehidden namenew_email valuehackerevil.com / /form script // 页面加载后自动提交表单 document.getElementById(csrfForm).submit(); /script /body /html攻击者将上述HTML托管在evil.com诱使已登录vulnerable-site.com的用户访问其邮箱就会被悄无声息地修改。3. 绕过常见防护的进阶技巧检查Referer Header有些应用会检查请求的Referer头是否来源于本站。可以尝试利用Flash、浏览器插件或特定JS技巧发起请求可能不发送或能篡改Referer。使用data:协议或about:blank作为攻击页面源某些浏览器的Referer行为可能不同。如果网站只检查Referer的“域名”部分可以尝试子域名攻击如attacker.vulnerable-site.com。简单的Token验证如果Token只是放在表单隐藏域且未与会话绑定攻击者可以先发起一个GET请求到表单页解析出Token再用于构造恶意POST请求。这需要攻击页面能发起AJAX并解析响应受同源策略限制但若目标站点存在JSONP接口或CORS配置错误则可能实现。实操心得在实际测试中不要只盯着“修改”操作。一些“获取”操作也可能造成危害比如“导出所有数据”功能如果通过GET请求触发且无防护攻击者可以构造一个img src/export_data标签导致用户浏览器在后台触发数据导出泄露敏感信息。3.2 SSRF漏洞的挖掘与利用SSRF的挖掘核心是寻找应用中所有将用户输入转换为后端网络请求的地方。1. 漏洞点寻找常见功能场景URL加载/预览/下载头像设置、文章封面图、富文本编辑器中的“插入网络图片”、文档/视频在线转码、URL缩短服务、爬虫分析服务。Webhook或回调功能支付回调、第三方登录回调、消息通知回调。攻击者可能控制回调的URL参数。内部接口代理某些应用为了前端方便会提供代理接口如/proxy?urlhttps://external-resource.com。文件处理相关从URL导入文档如word、excel、XML解析可能引发XXE进而导致SSRF、PDF生成器读取远程URL。社交媒体分享预览输入一个URL后端去抓取该URL的标题和缩略图。2. 利用手法与协议利用SSRF的威力很大程度上取决于后端服务器使用的网络请求库如curl、requests支持哪些URL协议。基础信息探测# 探测内网存活主机和端口 http://192.168.1.1:8080 http://10.0.0.1:22 # 读取本地文件file协议 file:///etc/passwd # 访问云元数据经典案例 http://169.254.169.254/latest/meta-data/ http://metadata.google.internal/computeMetadata/v1/利用Gopher/Redis协议攻击内网服务如果后端支持gopher://协议攻击者可以构造特殊的Payload直接与内网的Redis、Memcached、MySQL等未授权或弱密码服务进行交互实现命令执行或数据窃取。这是SSRF危害升级的关键。例如向内网Redis发送一条SET命令将计划任务crontab写入目标服务器从而获取shell。利用HTTP协议进行端口扫描和指纹识别通过观察请求的响应时间、错误信息、返回内容可以判断内网端口开放情况和服务类型。3. 绕过过滤技巧开发人员可能会对输入进行一些简单的过滤如黑名单127.0.0.1、localhost或要求必须以http://开头。IP地址变形十进制IPhttp://2130706433等价于127.0.0.1八进制IPhttp://0177.0.0.1等价于127.0.0.1十六进制IPhttp://0x7f.0x0.0x0.0x1省略部分http://127.1、http://127.0.1域名重定向攻击者控制一个域名evil.com将其A记录指向127.0.0.1然后提交http://evil.com。利用URL缩短服务或可设置重定向的网站如https://redirect.example.com?targethttp://127.0.0.1。利用URL解析差异在URL中加入符号http://expected-hostevil-host。某些旧库或错误配置可能只解析之前的部分作为认证信息实际请求evil-host。利用#片段标识符http://expected-host#evil-host。同样解析差异可能导致目标错误。实操心得测试SSRF时一定要用Burp Suite的Collaborator功能或自己搭建一个带公网IP的监听服务器如用nc -lvp 80。将Collaborator生成的域名作为Payload输入如果能收到来自目标服务器的DNS查询或HTTP请求就铁证如山地证明了SSRF漏洞的存在并且能了解到服务器出网的IP、User-Agent等信息。4. 防御方案设计与代码层面实现理解了攻击防御就有了方向。防御的核心思想都是“验证请求的真实意图”。4.1 CSRF的防御方案CSRF防御的核心是让攻击者无法构造出合法的请求。1. 同步令牌Synchronizer Token Pattern最有效原理在用户会话中生成一个随机、不可预测的Token如CSRF Token。在渲染任何包含状态修改表单的页面时将此Token放入表单的隐藏域。当表单提交时服务器验证提交的Token是否与会话中存储的Token一致。实现要点每个会话或每个请求一个Token推荐每个请求使用独立Token但需注意并发问题。至少保证每个会话的Token是唯一的。Token需保密且随机使用安全的随机数生成器如java.security.SecureRandom。Token绑定到会话将Token存储在服务器端Session中或使用加密的Cookie需防重放攻击。对敏感GET请求也需防护严格来说任何会改变状态的请求都应使用POST/PUT/DELETE并对它们实施Token验证。如果非要用GETToken可以放在URL参数中但存在被日志记录泄露的风险。代码示例Spring Security 视角 Spring Security默认就提供了CSRF防护。它会自动生成一个Token名为_csrf存储在Session和请求属性中。在Thymeleaf模板中表单会自动添加input typehidden name_csrf th:value${_csrf.token} /对于AJAX请求你需要将Token放在Header中通常是X-CSRF-TOKEN。2. 同源检测检查Referer/Origin Header原理服务器检查请求头中的Origin或Referer字段判断其来源是否与本站的域名一致。优点实现简单。缺点用户隐私设置或浏览器可能不发送这些头。Referer可能被篡改虽然浏览器层面较难。需要小心处理来源为空的情况比如从本地文件打开或HTTPS跳到HTTP时避免误杀合法请求。建议作为辅助手段与Token机制结合使用提供深度防御。3. 自定义请求头原理通过JavaScript在前端为所有异步请求如通过Fetch/Axios发起的添加一个自定义Header如X-Requested-With: XMLHttpRequest。由于浏览器同源策略的限制攻击者无法通过form或img标签来添加自定义Header。优点对于纯API的前后端分离应用实现方便。缺点仅能防护非简单请求CORS规范中的“非简单请求”。如果API允许简单请求GET、POST且Content-Type为application/x-www-form-urlencoded,multipart/form-data,text/plain此方法失效。因此不能作为唯一防御手段。注意事项千万不要使用GET请求来进行状态修改操作这是防御CSRF的最基本前提。同时要确保登录会话有合理的超时时间并提供明显的“退出登录”功能减少攻击窗口期。4.2 SSRF的防御方案SSRF防御的核心是对用户提供的URL进行严格的白名单控制和访问限制。1. 输入验证与过滤黑名单不足需结合白名单绝对不要仅用黑名单禁止127.0.0.1、localhost、192.168.*、10.*、172.(16-31).*、169.254.*等内网地址段是基础但如前所述有大量绕过手法。建立严格的白名单如果业务功能明确如只允许抓取指定几个图片CDN的图片则只允许这些域名或IP。域名白名单解析用户输入的URL得到主机名与白名单列表匹配。IP白名单将主机名解析为IP地址检查该IP是否在允许的公共IP范围内并拒绝任何私有IPRFC 1918、回环地址、链路本地地址等。代码示例Python - 使用urllib.parse和socketfrom urllib.parse import urlparse import socket import ipaddress def is_allowed_url(user_input_url, allowed_domains): try: parsed urlparse(user_input_url) hostname parsed.hostname # 1. 检查协议只允许http/https if parsed.scheme not in (http, https): return False, Protocol not allowed # 2. 解析主机名到IP ip socket.gethostbyname(hostname) # 3. 检查IP是否为内网地址 ip_obj ipaddress.ip_address(ip) if ip_obj.is_private or ip_obj.is_loopback or ip_obj.is_link_local: return False, Internal IP address not allowed # 4. (可选) 检查域名是否在白名单内 if allowed_domains and hostname not in allowed_domains: return False, Domain not in whitelist # 5. (可选) 检查端口是否在允许范围如只允许80, 443 if parsed.port and parsed.port not in (80, 443, None): return False, Port not allowed return True, OK except Exception as e: return False, fURL validation error: {e}2. 网络层访问控制出站防火墙规则在服务器或容器级别配置严格的出站防火墙规则。只允许应用服务器访问其业务必需的外部服务和特定的公网IP/端口禁止访问整个内网段如10.0.0.0/8和回环地址。使用独立的网络命名空间或容器将存在SSRF风险的服务部署在独立的、网络受限的容器或虚拟机中其网络访问能力被严格限制。3. 请求处理安全禁用危险的URL协议在发起请求的客户端库如curl、requests配置中显式禁用file://、gopher://、dict://、ftp://等非必要且高风险的协议。在PHP中注意curl和file_get_contents对协议的支持在Java中注意URLConnection和HttpClient的配置。设置请求超时和重定向限制避免攻击者利用请求进行端口扫描长超时或通过重定向链绕过过滤。# Python requests 示例 import requests from requests.packages.urllib3.exceptions import InsecureRequestWarning requests.packages.urllib3.disable_warnings(InsecureRequestWarning) session requests.Session() # 禁用重定向或严格限制重定向次数 session.max_redirects 2 # 设置超时 try: response session.get(validated_url, timeout(3, 10), verifyFalse) # 连接超时3秒读取超时10秒 except requests.exceptions.Timeout: # 处理超时 pass使用主机名而非IP发起请求如果业务允许强制使用域名并在解析后对IP进行严格的过滤这比直接处理用户输入的IP地址更安全。4. 响应处理安全不要将原始响应直接返回给前端对于“URL预览”类功能后端获取内容后应只提取需要的文本摘要和安全的缩略图经过二次处理而不是将整个HTTP响应体可能包含内网服务的敏感HTML/JSON原样返回。内容类型检查确保获取的内容是期望的类型如图片可以通过检查Content-TypeHeader和文件魔数magic number来实现。实操心得防御SSRF最有效的方法是“默认拒绝最小化允许”。在设计任何需要从用户输入发起网络请求的功能时都要问自己这个功能真的有必要吗能否用其他方式替代如果必须要有那么允许访问的范围必须缩小到业务绝对需要的最小集合。同时在代码审计时要重点关注所有调用了HttpClient、curl、requests、URLConnection等网络库的地方追踪其参数是否用户可控。5. 测试、排查与进阶思考5.1 如何系统性地测试这两种漏洞针对CSRF的测试清单枚举敏感操作使用爬虫如Burp的Scanner或手动浏览列出所有修改状态的请求POST/PUT/DELETE及危险的GET。检查防护令牌对于每个敏感请求检查其请求参数或Header中是否存在随机Token如csrf_token,_csrf。尝试移除或修改该Token看请求是否依然成功。验证Token绑定如果存在Token用两个不同的用户会话获取Token尝试交叉使用验证Token是否与会话绑定。检查同源策略尝试从不同的Origin或Referer发起请求观察是否被拒绝。自动化工具使用Burp Suite的CSRF Scanner插件或类似工具进行辅助扫描。针对SSRF的测试清单功能点枚举寻找所有接受URL作为输入的功能点。基础探测输入一个你控制的公网服务器地址或Burp Collaborator域名确认后端是否发起了请求。内部地址探测尝试http://127.0.0.1:80、http://localhost/admin、http://169.254.169.254/、http://192.168.1.1:8080等。协议尝试尝试file:///etc/passwd、gopher://、dict://等取决于后端环境。绕过尝试对存在基础过滤的点尝试使用前述的IP变形、域名重定向、URL解析差异等方法进行绕过。端口扫描通过观察响应时间差异或错误信息尝试探测内网常见端口22, 80, 443, 3306, 6379等。5.2 常见问题与排查实录Q1我们用了Spring Security是不是就高枕无忧了ASpring Security默认开启了CSRF防护但它主要防护的是基于Session和Thymeleaf/JSP表单的场景。对于纯REST API使用JSON无Session你需要明确配置CSRF防护策略或者根据业务情况考虑禁用并采用其他如JWT等无状态认证方案此时需评估CSRF风险。同时要确保你的登出接口、文件上传接口等也被正确防护。Q2SSRF漏洞似乎只能访问内网危害不大A这是非常危险的误解。SSRF的危害极大云环境杀手直接访问云元数据服务获取临时密钥接管整个云主机甚至整个账户资源。内网渗透跳板攻击内网的Redis、MySQL、Jenkins、Consul等管理界面若存在未授权或弱口令可导致远程代码执行RCE。攻击本地服务访问127.0.0.1上的管理接口如php-fpmstatus page,memcachedstats可能造成信息泄露或进一步利用。Q3我们的服务都在Kubernetes里SSRF是不是更危险A是的。Kubernetes Pod默认可以访问Kubernetes API Server通常位于https://kubernetes.default.svc。如果攻击者通过SSRF访问到API Server并且Pod挂载了Service Account Token攻击者可能拥有该Pod的权限从而在集群内进行横向移动危害整个集群。防御时必须为Pod配置最小权限的Service Account并限制其对API Server的访问。Q4CSRF Token放在Cookie里Double Submit Cookie安全吗A这是一种常见方案前后端分离时常用。将Token放在Cookie中前端JS读取后放入请求Header或参数。它的安全性基于攻击者无法读取或伪造Cookie受同源策略保护。但需注意必须设置Cookie为HttpOnlyfalse以便JS读取。必须防范XSS漏洞因为一旦存在XSS攻击者脚本可以轻易读取Cookie中的Token使CSRF防护失效。因此防御CSRF的前提是已经做好了XSS的防护。5.3 进阶思考漏洞的组合利用在实际渗透中漏洞很少单独存在。CSRF和SSRF常与其他漏洞形成“组合拳”XSS CSRF如果网站存在存储型XSS攻击者可以注入恶意脚本该脚本在所有访问该页面的用户浏览器中执行不仅能窃取数据还能直接发起CSRF请求因为脚本在同源下可以读取Token从而完全绕过CSRF防护。SSRF Redis未授权访问通过SSRF攻击内网的Redis利用Redis协议写入Webshell或计划任务是获取服务器权限的经典路径。SSRF 文件读取file协议如果后端支持file://协议SSRF可直接读取服务器上的敏感配置文件如/proc/self/environ、/etc/passwd、应用程序配置文件为后续攻击提供信息。理解这些关联性能帮助我们在防御时建立更立体的安全观。安全是一个链条最薄弱的一环决定了整体的强度。对于开发者和安全工程师而言透彻理解CSRF和SSRF这对“请求伪造”兄弟的原理与差异是构建健壮Web应用安全防线的必修课。从代码编写的第一行起就带着对用户输入的不信任对每一次网络请求都保持警惕才能从根本上减少这类漏洞的产生。
)
