文章总结： 文章指出20年前的SQL注入payload在2026年仍能绕过近四成系统，根源在于开发层拼接SQL、无WAF防护及测试缺失。建议实施纵深防御：开发层强制参数化查询，边界层部署WAF，账号层最小权限，认证层加强验证码与锁定机制，流程层落实上线前安全测试。
综合评分： 85
文章分类： WEB安全,安全加固,应用安全,安全建设,实战经验
20年前的老漏洞， 2026年为什么还能秒穿四成系统
宝十八
宝十八
网络安全老宋
2026年9月30日 12:00
山东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
导语： 你好，我是网络安全老宋。安全攻防干货准时送达！
网络安全老宋// 安全加固 · 甲方运维
// 安全加固 · 甲方运维
20年前的老漏洞， 2026年为什么还能秒穿四成系统
一个 1998 年就写进教科书的 payload，今年还能打开近四成的登录框——不是攻击变强了，是防守这二十年没跟上。
安全加固甲方运维SQL注入
🔑 一句话精华
一个 1998 年就写进教科书的 payload，今年还能打开近四成的登录框——不是攻击变强了，是防守这二十年没跟上。
目录 · Table of Contents
01你测的和我要守的，不是同一批系统
02登录框被”一句话”撬开，根子不在 payload
03别急着自证清白，先翻这三处
04想真正堵住，得一层层叠起来
05老宋说
前阵子看到一家 AI 安全实验室做了个测试：挑 37 个授权范围内的目标，清一色是中小企业的业务系统，CRM、OA、ERP、小程序后台都有，然后拿那个火了二十年的注入串 ' or '1'='1 挨个试。
结果挺难看。37 个里 14 个直接跳进后台，7 个报数据库错，说明注入点还在、只是被 WAF 拦了一半，真正顶住的只有 16 个。
也就是说，接近四成的系统，一个二十年前的 payload 就能秒穿。
那篇原文是从攻击视角写的，教人怎么继续用这个老古董挖 SRC 赚钱。老宋今天换个方向——从防守这头看同一件事：为什么 2026 年了，这种事还在天天发生，以及你的系统，会不会正躺在那四成里面。
01你测的和我要守的，不是同一批系统
很多做安全的兄弟会本能反驳：预编译不是早就普及了吗，WAF 不是早就上了吗，怎么还这样？
问题恰恰出在这个”早”字上。你在自己公司、在大厂 SRC 上看到的，是那批有人维护、有安全团队、年年做渗透的系统；而真正脆的，是水面下那几百万个中小企业的业务系统，它们的开发水平，停在了 2016 年甚至更早。
这批系统的画像很一致，四条几乎全中。一是用老框架，Struts2、Spring MVC 3.x、ThinkPHP 3.2、DedeCMS、帝国 CMS，这些东西本身不一定有洞，但围绕它们长出来的写法，天生爱拼接；二是开发外包，一个项目几万块，周期两周，能跑就行，安全不在交付清单里；三是没有 WAF，企业主压根不知道 WAF 是个啥，更不会为它单独掏钱；四是上线前只测功能、不测安全，登录能进去就算完事。
把这几条摞在一起，你会发现这不是”某几个倒霉蛋中招”，而是一整片长尾攻击面。更要命的是，这片长尾不会随技术进步自动消失——只要系统还能用，企业主就不愿意花钱重做，于是老系统一年年堆积，洞也就一年年留着。攻击者要的从来不是最先进的系统，而是最省事的那个。
02登录框被”一句话”撬开，根子不在 payload
说到底，注入登录绕过这件事，原理朴素得不像个高危漏洞。正常的登录，后端应该这样问数据库：用户名等于”你输的”，并且密码等于”你输的”，两个条件都得满足，才放行。而脆弱的写法，是把用户输入当成句子的一部分，直接拼进去。
拼出来的语句大致长这样：
⏺ SQL · 拼接式登录查询
SELECT * FROM users WHERE username = ‘$user’AND password = ‘$pwd’
你输一个正常用户名，它就是个正常查询。可一旦你在用户名里塞进 ' or '1'='1，那句判断就变成了”用户名等于空，或者 1 等于 1″——后半句永远为真，密码校验形同虚设，后台大门就这么开了。
所以真正的问题，不是这个 payload 太狡猾，而是后端把”用户输入”和”SQL 语法”混在了同一个字符串里。输入即代码，是这类漏洞的万恶之源。
到 2026 年，形态还在翻新，但内核一个字没变。比如现在的应用大量用 JSON 传参，有的后端图省事，把 JSON 字段的值直接拼进 SQL，登录接口照样一穿到底；再比如一些廉价 WAF 只会匹配固定的关键词，遇到大小写混写、注释符号拼接、关键字双写这类花活，拦截规则就瞎了。这些手法原文讲得很细，老宋不展开——你只需要记住一件事：WAF 是补丁，不是地基；地基没打牢，补丁总有漏的那天。
▲ 一把二十年前的老钥匙，2026 年依然能拧开登录框——根子是”拼接”，不是钥匙
03别急着自证清白，先翻这三处
知道了原理，判断自己危不危险就有章法了。不用上来就买工具，翻三个地方，基本能看出个七八分。
第一处，翻代码，找拼接。重点看数据库访问层，搜那些把变量直接塞进 SQL 字符串的写法——用加号拼的、用插值符套的、用格式化占位符套的，都是嫌疑对象。健康的写法长什么样？长这样：... WHERE username = ?，问号占位，参数单独传，数据库自己保证它只是数据、不是语法。如果一家系统里，占位符和拼接混着用，那拼接的那部分就是洞。
第二处，翻日志，找痕迹。翻登录接口和查询接口的历史日志，搜那些反常的输入——单个引号、or、双横线、斜杠星号，尤其是出现在用户名这种本该规规矩矩的字段里的。自己系统被扫过、被试过，日志里一定留过脚印，只是以前没人看。
第三处，翻 WAF 规则，找盲区。别只确认”我们买了 WAF”，要确认它到底管没管登录接口、用的是不是出厂默认的那几条规则。默认规则挡不住默认以外的攻击，这是常识。
要提醒一句：上面这些动作，都只在你自己负责的、或者客户明确授权的资产上做，越界就是另一回事了。自查是为了补漏，不是为了越线。
04想真正堵住，得一层层叠起来
单点防御在这类老漏洞面前基本没用，得几层一起上。
开发层，是地基。一句话，凡是 SQL，必须走参数化查询，占位符写死，永不拼接。这一条做到位，七成的注入当场消失。顺带把用户输入的校验也加上，白名单优先，能不收的字符就不收。
边界层，是减速带。部署 WAF，哪怕是开源的 ModSecurity 加几条像样的规则，也能把绝大多数自动化扫描挡在门外。它的价值不是全防住，而是把攻击成本从”复制粘贴”抬高到”得动脑子”，而你换来的是发现它的时间。
账号层，是保险丝。应用连数据库的账号，只给它必要的表权限，明确禁止它去查元数据表。这样即便被注入，攻击者能摸到的信息也被箍在一个小圈子里，跑不出去。
认证层，是门禁。验证码必须动态生成、一次性使用、提交即失效——原文里那 14 个被秒穿的案例，好几个就栽在”验证码能复用”上；再加登录失败锁定和异常登录告警，把暴力尝试也摁住。
流程层，是免疫系统。上线前跑一遍安全测试，登录接口必须有针对性的用例，别让”能跑就行”成为上线标准。这一层不产生直接收益，但它决定了下一批系统还会不会重蹈覆辙。
▲ 单层挡不住，五层叠起来才叫纵深防御
| | | |
| — | — | — |
| 层级 | 要做什么 | 防的是哪一类 |
| 开发层 | 强制参数化查询，输入白名单 | 注入的根因 |
| 边界层 | WAF + 覆盖登录接口的规则 | 自动化扫描与批量尝试 |
| 账号层 | 数据库最小权限，禁元数据查询 | 注入成功后的横向扩展 |
| 认证层 | 动态一次性验证码 + 失败锁定 | 暴力破解与验证码复用 |
| 流程层 | 上线前安全测试，登录接口必测 | 系统性重蹈覆辙 |
这五层叠起来，才叫”纵深防御”。任何一层单拿出来，都挡不住一个肯多试两次的人。
05老宋说
// 老宋说：注入能活过二十年，靠的不是技术难度，而是开发者对用户输入那份根深蒂固的信任——总觉得”这个字段是给正常人填的”。可攻击者从来不按正常人出牌。行业里有个错觉，以为安全投入要砸在最新最炫的东西上；但真实世界里，绝大多数损失，发生在我们早已知道怎么防、只是没去防的地方。新漏洞需要天赋，老漏洞只需要偷懒。所以别急着追下一个零日，现在就去翻你们系统的登录接口，看它是用问号占位，还是用加号拼接。
来聊一聊
你的系统做过登录接口的安全自查吗？留言告诉我：
A. 查过，用的是参数化，心里有底
B. 没查过，也不知道从哪查起
C. 老系统一堆，想查但没人手
D. 我就是那被秒穿的一批……
留言区见 👇
要是觉得有用，转发给还在用老系统扛业务的那位同事，他可能最需要看到。
我是老宋，下期见 👋
网络安全老宋 · 转载请注明出处
防御，不是在演练期间发现攻击，而是在演练开始前就把攻击面收敛到最小。
end
不想错过文章内容？读完请点一下“在看”，加个“关注”，您的支持是我创作的动力
期待您的一键三连支持（点赞、在看、分享~）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网络安全老宋 宝十八
宝十八《20年前的老漏洞， 2026年为什么还能秒穿四成系统》