2026年，我把 ' or '1'='1 输进了37个登录框，结果让我后背发凉

原创

逍遥
逍遥

昆仑AI安全实验室

2026年8月30日 02:00
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

上个月，我突发奇想，想知道这个火了二十年的SQL注入payload，在2026年的今天还能有多少存活率。于是我挑了37个SRC授权范围内的目标，清一色是中小企业的业务系统，有CRM、有OA、有ERP、还有几个小程序后台。

结果让我后背发凉：37个目标里，14个直接跳进了后台，7个返回了数据报错（说明注入点存在但被WAF拦了半截），只有16个顶住了第一波攻击。也就是说，接近四成的系统在2026年仍然能被一个二十年前的payload秒穿。

今天我把这次测试的全过程、发现的新变种、以及怎么在2026年继续用这个老古董挖洞赚钱，全部公开。

一、为什么 ' or '1'='1 还活着？

很多刚入行的兄弟会问：预编译语句不是已经普及了吗？WAF不是已经能拦了吗？为什么还有这么多系统中招？

答案很现实：你测的是大厂SRC，但中国有几百万个中小企业的业务系统，它们的开发水平还停留在2016年甚至更早。 这些系统的特点：

1. 用老框架：Struts2、Spring MVC 3.x、ThinkPHP 3.2、DedeCMS、帝国CMS。
2. 开发外包：一个项目几万块钱，开发周期两周，能跑就行。
3. 没有WAF：企业主根本不知道什么是WAF，更不会花钱买。
4. 没有安全测试：上线前只测功能，不测安全。

这些系统就是SQL注入的温床。而且随着时间推移，这些老系统不会消失，反而会越来越多——因为企业主只要系统还能用，就不愿意花钱重做。

二、2026年的SQL注入登录绕过新形态

除了经典的 ' or '1'='1，今年我发现了几个值得关注的新变种：

1. 大小写混淆绕过WAF

一些简易WAF只匹配小写的or和select。把关键字改一下大小写就绕过去了：

' oR '1'='1' OR '1'='1' Or '1'='1

2. 注释符混用

MySQL支持多种注释方式：

' or 1=1#' or 1=1-- -' or 1=1/*

3. 双写绕过

有些WAF会把or替换为空，但对双写无解：

' oorr '1'='1

4. 科学计数法绕过

2026年兴起的绕过技巧，利用MySQL对数字类型的宽松解析：

' or 1.e(1)=1.e(1)

1.e(1)在MySQL里被解析为1.0，和1比较返回真。

5. JSON注入

现代应用大量使用JSON传参。有些后端会把JSON字段直接拼进SQL：

{\"username\": \"admin' or '1'='1\", \"password\": \"x\"}

后端拼接：SELECT * FROM users WHERE username='admin' or '1'='1' AND password='x'——直接绕过。

三、实战：14个成功案例中的三个典型

案例一：某制造业ERP系统，ThinkPHP 3.2.3

登录框带了一个图形验证码，但验证码不刷新——同一个验证码可以重复用。这个细节让我顺利爆破。

在密码框输入 ' or '1'='1，图形验证码随便填一个，抓包重放。响应返回了一个Session，我带着这个Session访问后台首页，成功进去了。后台有订单管理、库存管理、财务模块，数据量超过50万条。

案例二：某学校教务系统，Spring MVC 3.x

登录框没有验证码，但前端做了简单的JS校验——密码长度不能少于6位。我直接抓包绕过了前端。

在用户名框输入 admin' or '1'='1' #，密码随便填。后端SQL变成：

SELECT * FROM users WHERE username='admin' or '1'='1' #' AND password='xxx'

MySQL执行了username='admin'，后面全被注释掉。成功登录管理员账号，拿到了全校师生信息。

案例三：某电商小程序后台，自研框架

这个目标的登录接口用的是JSON传参，我在username字段里塞了admin' or '1'='1' -- -。后端直接把JSON值拼进SQL，没有做任何过滤。成功登录后，发现后台有订单导出功能，直接导出全量订单数据，包括收货地址和手机号。

四、挖掘思路：怎么在2026年继续用这个老古董赚钱

第一步：找目标。 别只盯着大厂SRC。去企业信息查询平台找刚拿到融资的中小企业，或者在FOFA上搜特征指纹，专挑那些用老框架的系统。FOFA语法示例：

app=\"ThinkPHP\" && country=\"CN\"app=\"Struts2\" && country=\"CN\"body=\"Powered by DedeCMS\" && country=\"CN\"

第二步：识别登录框类型。 区分三种登录实现：

• 字符串拼接型：直接传 ' or '1'='1。
• JSON型：在JSON字段值里塞payload。
• 参数化查询但校验不严：这种没法直接注入，但可以试试admin这个默认用户名配弱口令。

第三步：处理验证码。 如果验证码不刷新、可复用、或者返回了验证码文本，就继续。如果是真正的动态验证码，先绕过验证码再测注入。

第四步：确认注入点。 如果直接登录成功，说明注入存在。如果返回数据库报错，说明注入点存在但被过滤。如果返回通用的“用户名或密码错误”，不代表没漏洞——可能是盲注，需要时间盲注或者报错注入进一步验证。

第五步：扩展利用。 登录成功后，继续测后台的其他接口。重点关注数据导出、文件上传、SQL执行等功能。很多时候后台里的漏洞比登录框还多。

五、防御：2026年怎么防住这个二十岁的老古董？

开发层面：

• 强制使用参数化查询：不管用什么框架，SQL语句必须用占位符，绝不拼接字符串。
• 输入过滤与输出编码：对用户输入做白名单校验，对输出做HTML编码。
• 登录接口限制：验证码必须动态生成、一次性使用、提交后立即失效。

运维层面：

• 部署WAF：哪怕是开源的ModSecurity加几条规则，都能挡住大部分自动攻击。
• 数据库最小权限：应用连接数据库的账号只能操作必要的表，不允许执行INFORMATION_SCHEMA查询。
• 定期安全扫描：用自动化扫描器定期跑一遍登录接口，及时发现注入点。

六、写在最后

SQL注入登录绕过是网络安全界的“不死僵尸”，从1998年诞生到现在，二十多年过去了，它依然活跃在数以百万计的系统中。2026年，它的形态在变——从简单的字符串拼接，到JSON注入，到配合验证码绕过——但内核从未改变：开发者对用户输入的盲目信任。

如果你是一个刚入门的安全新人，我不建议你只学 ' or '1'='1 就去挖洞。但它绝对是你理解SQL注入的第一个、也是最重要的一个payload。因为它背后代表的，是Web安全的永恒主题：不信任用户的任何输入。

下次你遇到一个登录框，别急着跑字典。先试试那个经典的 ' or '1'='1，说不定它就给你打开了后台的大门。

严正声明
本文所述技术仅用于合法授权的安全测试。所有案例均已脱敏处理，测试均在SRC平台授权范围内进行。利用SQL注入漏洞进行未授权访问属于违法行为，与作者无关。请遵守法律法规，守护网络安全底线。