今天在靶场打穿了SQL注入的第一关。为了防止死记硬背我结合源码把漏洞的来龙去脉彻底捋了一遍。一、大白话理解纯比喻版网站的数据库像一个上了锁的屋子。后端代码就像一个守门员负责拿前端输入的名字去屋子里查数据。正常的流程是我报一个正常名字守门员核对无误去屋子里把属于我的信息拿出来给我。但是这个守门员做事不认真他不仅没检查我输入的东西还直接把我输入的话当成死命令传给了后面的大仓库数据库。我输入的不是名字而是一句骗人的指令“查张三或者只要1等于1就把所有人拿出来后面的规则别管了。”为什么数据库会被绕晕并交出所有人的数据因为我原本只让数据库查“名字叫张三的”但我加了 or 11。在数据库眼里1永远等于1这个条件是绝对成立的。所以它判断“即使名字不是张三只要1等于1也算符合条件。”这样一来数据库里每一条数据都满足这个永真条件它只能老老实实把所有人的数据全部交出来。一句话总结前端输入的字符后端不加验证直接当代码执行了这就是字符型注入。二、结合源码的大白话理解我们来看一眼后端实际的源码select id,email from member where username‘$name’这里的 $name 就是专门用来接收前端输入内容的变量。正常输入 kobe 时后端执行代码为select id,email from member where username‘kobe’所以只查出 kobe 一个人的数据。但是我输入了kobe’ or 11 #。因为后端没有做严格检查直接将我的输入拼接到代码里导致后端执行的完整代码变成了select id,email from member where username‘kobe’ or 11 #’这串代码直接绕过了原本的验证逻辑把数据库里所有人的数据全交了出来。三、Payload构造与原理拆解三部曲Payload构造语句kobe’ or 11 #它总共分三步完美构成了漏洞利用的闭环。闭合引导第一步kobe’为什么叫字符型因为输入的是文字。后端用 ‘$name’ 将其包裹。我输入 kobe’ 后后端拼接的完整代码变成了select id,email from member where username‘kobe’’多出来的单引号提前闭合了原本的引号边界打破了后端代码原本的语法结构为后续注入铺路。构造永真条件第二步or 11or 是逻辑“或”。A or B 只要其中一个成立整体就成立。而 11 是一个永远为真的条件在安全领域我们称它为永真条件。我接着输入 or 11后端的完整拼接代码变成了select id,email from member where username‘kobe’ or 11’数据库判断“即使名字不是kobe只要1等于1也行。”于是直接返回了数据库中所有的数据。注释截断第三步#后端源码末尾还有一个单引号 ’ 用来收尾。如果不处理它系统执行时会报错。我输入井号 #后端的完整拼接代码变成了select id,email from member where username‘kobe’ or 11 #’井号在数据库里是注释符它告诉数据库从它开始往后的内容全部忽略。这个动作阻止了报错让注入完美执行。四、详细的官方专业术语解答刚才的大白话在网络安全行业里有一套标准的官方术语。漏洞名称SQL注入字符型GET注入。漏洞原理后端应用程序未对用户输入的字符串进行严格过滤或转义直接将其拼接到 SQL 查询语句中执行。攻击手法攻击者利用单引号提前闭合原有的查询边界拼接 or 11 构造永真条件绕过验证最后使用 # 注释掉剩余SQL语句实现数据库信息的越权读取。五、以后的变通与思考何时用、怎么用什么场景下适用只要网站上出现了让用户输入文字、搜索词、账号名的输入框且提交后页面会产生变化比如URL里带有参数我们就可以尝试这套Payload。遇到数字型注入怎么变通如果源码是 select id,email from member where id$id这里的变量是数字没有引号包裹。这就叫数字型注入你不需要单引号闭合直接把Payload改成 1 or 11 # 就能打通。遇到 POST 请求怎么变通如果输入框提交数据的方式是 POST网址栏不显示参数你只靠浏览器是打不出来的。需要用 Burp Suite 工具抓包修改 POST 请求体里的参数把 Payload 填进去。六、我的S级核心笔记 ⭐核心Payloadkobe’ or 11 #构造三部曲闭合引导 ➡️ 构造永真条件or 11 ➡️ 注释截断#。适用场景后端未严格过滤用户输入直接拼接进SQL语句的文字输入框。