Data-only 攻击不改一行代码、不劫持一次函数跳转，只改程序运行时的数据，就能让服务执行攻击者想要的操作。它让程序跑完原本的全部合法代码，只是参数被换成了恶意值。传统防护把 DEP、CFI、CPI 这类机制叠上去，挡住的主要是改控制流的做法。Data-only 攻击从侧面绕开这套体系。同样的内存漏洞，用它重打一遍，成功率反而更高。做安全评估、维护网络服务的工程师和管理者都会遇到这个问题。
Data-only 攻击到底是什么
这种攻击只篡改内存中的数据字段，不去覆盖返回地址、虚表指针这些控制数据。目标进程照旧走完自己的正常流程，只是读到被改过的配置项或请求参数。一个典型例子是把 Web 服务器里 CGI 目录的路径变量从正常目录改成 /bin，再发一条指向 /sh 的 POST 请求，服务就执行了 shell。攻击全程没有注入任何外部代码。
它为什么能绕过 DEP、CFI 这些防护
DEP 挡住的是数据页里的可执行代码，CFI 检查的是间接跳转目标是否合法，CPI 护的是代码指针。这些机制有个共同前提，攻击者想改控制流。Data-only 攻击不改控制流，它改的是普通变量、配置值、请求处理用的路径串。程序自身的每一条指令都合法，每个跳转都符合预期。防护自然无从告警。
哪些服务容易被盯上
现代评测覆盖了 httpd、lighttpd、nginx、postgres、redis 这几类常见服务。攻击面集中在系统调用参数上，尤其是 execve、openat、write、connect、sendmsg 这几项。路径、文件名、目标地址这类参数，只要被攻击者请求污染，就可能被直接利用。静态分析先把候选利用点列出来，再重启服务、覆写指定内存、发正常负载验证副作用。两步就能确认一条可行路径。
防御上该做哪些取舍
缓解方案可以分成两类。内存安全和完整数据流完整性检查覆盖面大。代价是性能开销高，线上服务普遍扛不住。系统调用过滤、选择性污点跟踪、针对性扫描更实用，但挡不住所有路径。运维侧可以先从敏感系统调用入手做过滤，研发侧则该把内存安全语言、越界读写检测排进长期改造计划。想两头兼顾的团队，多半两头都顾不上。
实际落地有什么风险
最大的坑是把 data-only 攻击当成理论威胁。评测里 nginx 一个服务就确认出九百多条可行利用，覆盖代码执行、任意写、任意发送数据多种形态。只盯着控制流做检测，等于把侧门敞着。另一个误区是以为加个 WAF 就能解。WAF 看不懂内存里的参数污染。没有源码做污点分析的服务，排查成本会高出一截。
不同团队该怎么选
安全预算充足、能改代码的团队，优先上内存安全组件和完整数据流完整性检查。只能做加固的存量服务，把系统调用白名单、最小权限、只读文件系统先铺起来。两头都缺的中间状态，先用动态污点工具摸清攻击面，再按风险排修补顺序。
FAQ
代码审计能发现 data-only 利用点吗。静态审计能列出可疑参数流，但确认可行利用需要动态验证，两步缺一不可。
CFI 已经部署了还需要担心吗。需要。CFI 只管跳转目标，管不了程序带着脏数据走完全部正常流程。
什么信号提示可能遇到这种攻击。服务日志里出现配置项被异常修改、系统调用参数和请求内容高度一致，都值得往这个方向查。
小团队从哪一步开始。先把对外服务的敏感系统调用列出来，做最小权限和调用过滤，成本最低，收益最直接。