1. 从靶场到实战SQL注入的本质与危害刚入门Web安全的朋友第一关往往就是SQL注入。你可能在CTFHub、DVWA、Pikachu这些靶场里见过它也可能在奇安信的安全扫描报告里被它“点名批评”。这玩意儿听起来老生常谈但直到今天它依然是OWASP Top 10的常客是大量数据泄露事件的元凶。我处理过不少应急响应溯源到最后往往就是一行${}引发的“血案”。所以别觉得它基础吃透SQL注入是理解Web安全攻防逻辑的基石。这篇文章我会从一个简单的题目入手带你拆解SQL注入的完整攻击链条、背后的数据库交互原理以及开发者最常踩的那些坑。无论你是想通关CTF还是想真正理解并修复公司项目里的漏洞这些内容都值得你花时间琢磨。2. 题目场景还原与核心思路拆解我们假设一个经典的入门级题目场景一个简单的用户登录查询。前端页面有一个登录框输入用户名和密码点击提交。后端PHP代码可能长这样$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql); if (mysqli_num_rows($result) 0) { echo 登录成功; } else { echo 用户名或密码错误。; }2.1 漏洞根源字符串拼接的“原罪”漏洞的核心就出在$sql这一行。代码直接将用户输入的$username和$password变量用单引号包裹后拼接进了SQL语句字符串中。这看起来没问题因为数据库查询语法本就如此。但关键在于程序没有对用户输入的内容进行任何检查或过滤就将其当作了SQL语句的一部分来执行。攻击者的思路是我输入的数据不应该被当作“数据”而应该被当作“代码”的一部分去改变原有SQL语句的语义。比如在用户名输入框我不输入admin而是输入admin --。那么拼接后的SQL语句就变成了SELECT * FROM users WHERE username admin -- AND password $password在SQL中--是注释符它会把其后的所有内容都注释掉。于是这条语句的实际执行部分就变成了SELECT * FROM users WHERE username admin它完全绕过了密码验证只要数据库里存在用户名为admin的记录无论密码是什么攻击者都能成功登录。这就是最经典的“永真条件”绕过。2.2 攻击目标扩展不止于登录绕过登录绕过只是开始。通过精心构造的输入攻击者可以实现更多危害数据窃取利用UNION操作符将恶意查询的结果拼接到正常查询结果中从而盗取数据库中的其他表数据如用户信息、交易记录。数据库信息探测利用数据库的内置函数如version()database()user()和系统表如information_schema逐步摸清数据库的结构、版本、所有表名和列名。数据篡改与删除执行UPDATE、DELETE甚至DROP TABLE语句破坏数据完整性。文件系统操作在某些高权限配置下如MySQL的secure_file_priv设置不当利用LOAD_FILE()读取服务器文件或利用INTO OUTFILE写入Webshell获取服务器控制权。3. 手动注入的详细步骤与技巧解析很多新手依赖sqlmap这类自动化工具但工具是黑盒不理解原理就无法应对变种和防护。手动注入是基本功。我们以上述登录场景为例假设我们不知道任何用户名需要进行“无回显”或“错误回显”注入来获取信息。假设后端代码会显示SQL错误信息这在开发调试阶段很常见这为我们提供了“错误型注入”的机会。3.1 第一步探测注入点与数据库类型首先我们需要确认这里是否存在注入漏洞以及是什么数据库。单引号探测在用户名处输入。如果页面返回了数据库错误信息如“You have an error in your SQL syntax...”那么基本可以确定存在字符型注入且未过滤单引号。如果页面显示“用户名或密码错误”没有语法错误则可能是数字型注入或者单引号被转义了。永真/永假条件测试输入 or 11构造永真。输入 and 12构造永假。 观察页面返回结果的差异。如果永真能登录成功永假失败则注入点存在且可利用。判断数据库类型通过错误信息或特有函数判断。MySQL输入 and sleep(5) --观察页面响应是否延迟5秒。或者利用version()函数 and updatexml(1, concat(0x7e, version()), 1) --通过错误回显爆出版本。SQL Server错误信息中常包含“Microsoft SQL Server”。可用version探测。Oracle可用 AND 1(SELECT 1 FROM dual) --测试。注意在实际渗透测试中必须先获得授权未经授权的测试是违法行为。3.2 第二步利用错误回显提取信息以MySQL为例假设我们通过触发了详细的MySQL错误我们可以利用MySQL的updatexml()或extractvalue()函数通过报错来带出我们想要查询的数据。这是因为这两个函数在解析错误的XML路径时会将路径参数的内容以错误形式返回。爆当前数据库名 and updatexml(1, concat(0x7e, database()), 1) --concat(0x7e, database())将波浪号~0x7e是其十六进制与当前数据库名连接起来。波浪号常用于在错误信息中醒目地分隔出我们想要的数据。updatexml()执行时第二个参数如果不是合法的XPath格式就会报错并将这个参数的内容显示在错误信息里。于是你可能会看到类似这样的错误“XPATH syntax error: ~my_database_name”。爆所有表名 and updatexml(1, concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schemadatabase())), 1) --information_schema.tables是MySQL的系统信息表存储了所有表的信息。table_schemadatabase()条件限定只查询当前数据库下的表。group_concat()函数将多行查询结果即所有表名合并成一个用逗号分隔的字符串方便一次爆出。爆指定表如users的所有列名 and updatexml(1, concat(0x7e, (select group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_nameusers)), 1) --爆数据如users表的username和password列 and updatexml(1, concat(0x7e, (select group_concat(concat(username, :, password)) from users)), 1) --实操心得updatexml()函数一次能回显的数据长度有限约32KB如果表数据很多需要用substr()或mid()函数进行分片读取。例如 and updatexml(1, concat(0x7e, substr((select group_concat(table_name) from information_schema.tables where table_schemadatabase()), 1, 30)), 1) --然后不断调整substr的起始位置和长度。3.3 第三步联合查询注入Union-Based如果页面会正常显示查询结果比如一个新闻列表页面那么联合查询注入是更直接高效的方式。前提是你需要判断原始查询的列数。判断列数使用ORDER BY或UNION SELECT。 ORDER BY 1 -- ORDER BY 2 -- ORDER BY 3 --... 直到页面返回错误如“Unknown column 5 in order clause”说明列数为4。或者 UNION SELECT 1,2,3 --不断增减SELECT后的数字个数直到页面正常显示此时的数字个数就是列数。确定回显点假设列数为3。构造Payload UNION SELECT 1,2,3 --。查看页面原本显示数据的地方是否被数字“2”或“3”替代。这些位置就是我们可以用来回显查询结果的位置。获取数据将回显点的数字替换为我们想要的查询语句。爆数据库名 UNION SELECT 1, database(), 3 --爆表名 UNION SELECT 1, group_concat(table_name), 3 FROM information_schema.tables WHERE table_schemadatabase() --后续爆列名、爆数据的步骤与错误注入类似只是将查询语句放在回显点位置。4. 开发者视角漏洞是如何产生的以及如何修复作为攻击者我们知道了怎么利用。作为开发者或安全人员我们必须知道漏洞怎么来的以及如何堵上。4.1 罪魁祸首动态SQL拼接除了最原始的字符串拼接在现代开发中隐患常常隐藏在看似“高级”的用法里MyBatis中的${}这是网络热词里提到的高频风险点。MyBatis中#{}是预编译占位符会被安全地处理为参数。而${}是字符串替换会直接将值拼接到SQL语句中。如果这个值来自用户输入且未过滤SQL注入就产生了。错误示例select idgetUser parameterTypeString resultTypeUser SELECT * FROM users WHERE username ${username} /select正确做法永远优先使用#{}。除非是动态传入列名、表名等非数据值且这些值在代码中是硬编码或经过严格白名单校验的否则绝对不要使用${}。不安全的存储过程/函数调用即使使用了存储过程如果在其内部依然使用EXECUTE或sp_executesql来动态拼接SQL字符串风险同样存在。框架误用误以为使用了ORM框架如Hibernate, Entity Framework就绝对安全。如果使用其提供的“原生SQL”或“SQL查询”接口时仍然采用拼接方式漏洞依旧。4.2 根本解决方案参数化查询预编译语句这是防治SQL注入最有效、最根本的方法。它的原理是将SQL语句的结构代码与数据参数分开发送给数据库。之前拼接发送给数据库的是一条完整的、混合了代码和数据的字符串SELECT * FROM users WHERE username admin -- AND password xxx。数据库需要解析并执行整条字符串。之后参数化程序先发送一个SQL模板预编译语句给数据库SELECT * FROM users WHERE username ? AND password ?。这里的?是占位符。数据库预先解析这个模板确定其语法结构知道这是一个SELECT查询有两个条件。程序随后将数据如admin和123456作为参数单独发送。数据库将参数安全地“填入”之前解析好的模板结构中执行。此时即使参数里包含SQL元字符如单引号、注释符数据库也只会将其视为普通字符串数据而不会将其解释为SQL代码。各语言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Python (sqlite3/pymysql):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))4.3 辅助与补充措施最小权限原则为Web应用连接数据库的账户分配最小必要的权限。通常只授予SELECT、INSERT、UPDATE、DELETE等业务必需权限坚决杜绝DROP、FILE、GRANT等高危权限。这样即使发生注入危害也能被限制。输入验证与过滤在参数化查询的基础上增加一层防御。对输入的数据类型、长度、格式进行严格校验如用户名只允许字母数字长度在20以内。但切记过滤不能替代参数化查询复杂的过滤规则可能存在绕过风险。使用Web应用防火墙部署WAF可以在网络层面拦截常见的SQL注入攻击Payload作为一种边界防护手段。但它可能被绕过不能作为唯一的防护措施。避免显示详细错误信息在生产环境中将数据库错误信息重定向到日志文件而不是展示给前端用户。这可以增加攻击者探测漏洞的难度。定期安全扫描与代码审计使用奇安信等厂商的扫描器或开源工具定期对应用进行漏洞扫描。在代码层面重点审计所有SQL执行点检查是否使用了不安全的拼接方式。5. 靶场实战与工具使用中的避坑指南5.1 CTF与靶场常见套路过滤与绕过靶场不会总是“傻白甜”。常见过滤包括空格过滤用/**/、%0a换行符、%0d回车符、%09制表符代替。关键词过滤用大小写混合SeLeCt、双写selselectect、内联注释/*!SELECT*/绕过。或者使用等价函数/符号如用代替!用mid()代替substr()。单引号过滤如果是数字型注入则无需单引号。如果是字符型且被转义可尝试宽字节注入如GBK编码下输入%df%27%df与转义符\结合形成合法汉字从而“吃掉”转义符使%27单引号逃逸。无回显注入盲注页面没有数据回显也没有错误信息。这时需要利用“布尔盲注”或“时间盲注”。布尔盲注通过页面返回的真/假如“存在”/“不存在”“登录成功”/“失败”状态来逐位推断数据。Payload如 and ascii(substr(database(),1,1))100 --通过二分法不断调整数值判断第一个字符的ASCII码。时间盲注通过页面响应时间来判断。Payload如 and if(ascii(substr(database(),1,1))100, sleep(5), 0) --如果条件为真则页面延迟5秒返回。5.2 自动化工具sqlmap的明智使用sqlmap很强大但无脑用会出问题。不要一上来就--dump-all这会产生大量流量可能拖垮测试目标或触发警报。应该循序渐进--current-db---tables--D dbname --columns--D dbname -T tablename --dump。善用--level和--risk参数Level越高测试的Payload越全面但速度越慢越可能触发WAF。Risk越高会使用风险更高的Payload如OR 11。通常从默认值level 1, risk 1开始。遇到WAF时使用--tamper参数调用脚本对Payload进行混淆。sqlmap自带很多tamper脚本如space2comment.py空格转注释、randomcase.py随机大小写。注意--batch模式这个模式会默认选择所有交互选项在你不熟悉目标时可能会进行破坏性操作。初期测试建议关闭手动确认。记录与学习使用-v参数提高输出详细程度-v 3会显示发送和接收的HTTP请求这对于学习Payload构造和理解绕过原理非常有帮助。5.3 企业级扫描器如奇安信报SQL注入的处置流程确认漏洞扫描器报出的不一定是真漏洞可能是误报。首先根据扫描器提供的URL和Payload手动复现。尝试构造简单的、and 11、and 12进行验证。定位代码根据漏洞URL参数在代码中定位到对应的SQL执行语句。全局搜索该参数名或接口。分析成因检查是使用了字符串拼接、.、format还是MyBatis的${}或是其他不安全的数据库操作方式。制定修复方案首选方案改为参数化查询/预编译语句。次选方案如果因历史原因改动困难对输入参数进行严格的白名单过滤或转义。对于数字型参数强制转换为整数intval()Integer.parseInt()。修复后验证修复后不仅要用扫描器重新扫描更要手动测试确保漏洞已修复且未引入新问题如功能异常。根源整改推动建立安全编码规范在团队内普及参数化查询的必要性并在代码审查环节加入对SQL语句的安全检查。SQL注入是一个“古老”但远未过时的话题。从手动构造Payload的技艺到理解参数化查询的底层原理再到在复杂框架和过滤规则下的绕过思路每一层都值得深入。靶场是练习场而真实世界的漏洞往往藏在那些不经意的${}和自以为安全的拼接函数里。真正的安全始于对每一行用户输入保持敬畏的编码习惯。
1. 从靶场到实战SQL注入的本质与危害刚入门Web安全的朋友第一关往往就是SQL注入。你可能在CTFHub、DVWA、Pikachu这些靶场里见过它也可能在奇安信的安全扫描报告里被它“点名批评”。这玩意儿听起来老生常谈但直到今天它依然是OWASP Top 10的常客是大量数据泄露事件的元凶。我处理过不少应急响应溯源到最后往往就是一行${}引发的“血案”。所以别觉得它基础吃透SQL注入是理解Web安全攻防逻辑的基石。这篇文章我会从一个简单的题目入手带你拆解SQL注入的完整攻击链条、背后的数据库交互原理以及开发者最常踩的那些坑。无论你是想通关CTF还是想真正理解并修复公司项目里的漏洞这些内容都值得你花时间琢磨。2. 题目场景还原与核心思路拆解我们假设一个经典的入门级题目场景一个简单的用户登录查询。前端页面有一个登录框输入用户名和密码点击提交。后端PHP代码可能长这样$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql); if (mysqli_num_rows($result) 0) { echo 登录成功; } else { echo 用户名或密码错误。; }2.1 漏洞根源字符串拼接的“原罪”漏洞的核心就出在$sql这一行。代码直接将用户输入的$username和$password变量用单引号包裹后拼接进了SQL语句字符串中。这看起来没问题因为数据库查询语法本就如此。但关键在于程序没有对用户输入的内容进行任何检查或过滤就将其当作了SQL语句的一部分来执行。攻击者的思路是我输入的数据不应该被当作“数据”而应该被当作“代码”的一部分去改变原有SQL语句的语义。比如在用户名输入框我不输入admin而是输入admin --。那么拼接后的SQL语句就变成了SELECT * FROM users WHERE username admin -- AND password $password在SQL中--是注释符它会把其后的所有内容都注释掉。于是这条语句的实际执行部分就变成了SELECT * FROM users WHERE username admin它完全绕过了密码验证只要数据库里存在用户名为admin的记录无论密码是什么攻击者都能成功登录。这就是最经典的“永真条件”绕过。2.2 攻击目标扩展不止于登录绕过登录绕过只是开始。通过精心构造的输入攻击者可以实现更多危害数据窃取利用UNION操作符将恶意查询的结果拼接到正常查询结果中从而盗取数据库中的其他表数据如用户信息、交易记录。数据库信息探测利用数据库的内置函数如version()database()user()和系统表如information_schema逐步摸清数据库的结构、版本、所有表名和列名。数据篡改与删除执行UPDATE、DELETE甚至DROP TABLE语句破坏数据完整性。文件系统操作在某些高权限配置下如MySQL的secure_file_priv设置不当利用LOAD_FILE()读取服务器文件或利用INTO OUTFILE写入Webshell获取服务器控制权。3. 手动注入的详细步骤与技巧解析很多新手依赖sqlmap这类自动化工具但工具是黑盒不理解原理就无法应对变种和防护。手动注入是基本功。我们以上述登录场景为例假设我们不知道任何用户名需要进行“无回显”或“错误回显”注入来获取信息。假设后端代码会显示SQL错误信息这在开发调试阶段很常见这为我们提供了“错误型注入”的机会。3.1 第一步探测注入点与数据库类型首先我们需要确认这里是否存在注入漏洞以及是什么数据库。单引号探测在用户名处输入。如果页面返回了数据库错误信息如“You have an error in your SQL syntax...”那么基本可以确定存在字符型注入且未过滤单引号。如果页面显示“用户名或密码错误”没有语法错误则可能是数字型注入或者单引号被转义了。永真/永假条件测试输入 or 11构造永真。输入 and 12构造永假。 观察页面返回结果的差异。如果永真能登录成功永假失败则注入点存在且可利用。判断数据库类型通过错误信息或特有函数判断。MySQL输入 and sleep(5) --观察页面响应是否延迟5秒。或者利用version()函数 and updatexml(1, concat(0x7e, version()), 1) --通过错误回显爆出版本。SQL Server错误信息中常包含“Microsoft SQL Server”。可用version探测。Oracle可用 AND 1(SELECT 1 FROM dual) --测试。注意在实际渗透测试中必须先获得授权未经授权的测试是违法行为。3.2 第二步利用错误回显提取信息以MySQL为例假设我们通过触发了详细的MySQL错误我们可以利用MySQL的updatexml()或extractvalue()函数通过报错来带出我们想要查询的数据。这是因为这两个函数在解析错误的XML路径时会将路径参数的内容以错误形式返回。爆当前数据库名 and updatexml(1, concat(0x7e, database()), 1) --concat(0x7e, database())将波浪号~0x7e是其十六进制与当前数据库名连接起来。波浪号常用于在错误信息中醒目地分隔出我们想要的数据。updatexml()执行时第二个参数如果不是合法的XPath格式就会报错并将这个参数的内容显示在错误信息里。于是你可能会看到类似这样的错误“XPATH syntax error: ~my_database_name”。爆所有表名 and updatexml(1, concat(0x7e, (select group_concat(table_name) from information_schema.tables where table_schemadatabase())), 1) --information_schema.tables是MySQL的系统信息表存储了所有表的信息。table_schemadatabase()条件限定只查询当前数据库下的表。group_concat()函数将多行查询结果即所有表名合并成一个用逗号分隔的字符串方便一次爆出。爆指定表如users的所有列名 and updatexml(1, concat(0x7e, (select group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_nameusers)), 1) --爆数据如users表的username和password列 and updatexml(1, concat(0x7e, (select group_concat(concat(username, :, password)) from users)), 1) --实操心得updatexml()函数一次能回显的数据长度有限约32KB如果表数据很多需要用substr()或mid()函数进行分片读取。例如 and updatexml(1, concat(0x7e, substr((select group_concat(table_name) from information_schema.tables where table_schemadatabase()), 1, 30)), 1) --然后不断调整substr的起始位置和长度。3.3 第三步联合查询注入Union-Based如果页面会正常显示查询结果比如一个新闻列表页面那么联合查询注入是更直接高效的方式。前提是你需要判断原始查询的列数。判断列数使用ORDER BY或UNION SELECT。 ORDER BY 1 -- ORDER BY 2 -- ORDER BY 3 --... 直到页面返回错误如“Unknown column 5 in order clause”说明列数为4。或者 UNION SELECT 1,2,3 --不断增减SELECT后的数字个数直到页面正常显示此时的数字个数就是列数。确定回显点假设列数为3。构造Payload UNION SELECT 1,2,3 --。查看页面原本显示数据的地方是否被数字“2”或“3”替代。这些位置就是我们可以用来回显查询结果的位置。获取数据将回显点的数字替换为我们想要的查询语句。爆数据库名 UNION SELECT 1, database(), 3 --爆表名 UNION SELECT 1, group_concat(table_name), 3 FROM information_schema.tables WHERE table_schemadatabase() --后续爆列名、爆数据的步骤与错误注入类似只是将查询语句放在回显点位置。4. 开发者视角漏洞是如何产生的以及如何修复作为攻击者我们知道了怎么利用。作为开发者或安全人员我们必须知道漏洞怎么来的以及如何堵上。4.1 罪魁祸首动态SQL拼接除了最原始的字符串拼接在现代开发中隐患常常隐藏在看似“高级”的用法里MyBatis中的${}这是网络热词里提到的高频风险点。MyBatis中#{}是预编译占位符会被安全地处理为参数。而${}是字符串替换会直接将值拼接到SQL语句中。如果这个值来自用户输入且未过滤SQL注入就产生了。错误示例select idgetUser parameterTypeString resultTypeUser SELECT * FROM users WHERE username ${username} /select正确做法永远优先使用#{}。除非是动态传入列名、表名等非数据值且这些值在代码中是硬编码或经过严格白名单校验的否则绝对不要使用${}。不安全的存储过程/函数调用即使使用了存储过程如果在其内部依然使用EXECUTE或sp_executesql来动态拼接SQL字符串风险同样存在。框架误用误以为使用了ORM框架如Hibernate, Entity Framework就绝对安全。如果使用其提供的“原生SQL”或“SQL查询”接口时仍然采用拼接方式漏洞依旧。4.2 根本解决方案参数化查询预编译语句这是防治SQL注入最有效、最根本的方法。它的原理是将SQL语句的结构代码与数据参数分开发送给数据库。之前拼接发送给数据库的是一条完整的、混合了代码和数据的字符串SELECT * FROM users WHERE username admin -- AND password xxx。数据库需要解析并执行整条字符串。之后参数化程序先发送一个SQL模板预编译语句给数据库SELECT * FROM users WHERE username ? AND password ?。这里的?是占位符。数据库预先解析这个模板确定其语法结构知道这是一个SELECT查询有两个条件。程序随后将数据如admin和123456作为参数单独发送。数据库将参数安全地“填入”之前解析好的模板结构中执行。此时即使参数里包含SQL元字符如单引号、注释符数据库也只会将其视为普通字符串数据而不会将其解释为SQL代码。各语言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Python (sqlite3/pymysql):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))4.3 辅助与补充措施最小权限原则为Web应用连接数据库的账户分配最小必要的权限。通常只授予SELECT、INSERT、UPDATE、DELETE等业务必需权限坚决杜绝DROP、FILE、GRANT等高危权限。这样即使发生注入危害也能被限制。输入验证与过滤在参数化查询的基础上增加一层防御。对输入的数据类型、长度、格式进行严格校验如用户名只允许字母数字长度在20以内。但切记过滤不能替代参数化查询复杂的过滤规则可能存在绕过风险。使用Web应用防火墙部署WAF可以在网络层面拦截常见的SQL注入攻击Payload作为一种边界防护手段。但它可能被绕过不能作为唯一的防护措施。避免显示详细错误信息在生产环境中将数据库错误信息重定向到日志文件而不是展示给前端用户。这可以增加攻击者探测漏洞的难度。定期安全扫描与代码审计使用奇安信等厂商的扫描器或开源工具定期对应用进行漏洞扫描。在代码层面重点审计所有SQL执行点检查是否使用了不安全的拼接方式。5. 靶场实战与工具使用中的避坑指南5.1 CTF与靶场常见套路过滤与绕过靶场不会总是“傻白甜”。常见过滤包括空格过滤用/**/、%0a换行符、%0d回车符、%09制表符代替。关键词过滤用大小写混合SeLeCt、双写selselectect、内联注释/*!SELECT*/绕过。或者使用等价函数/符号如用代替!用mid()代替substr()。单引号过滤如果是数字型注入则无需单引号。如果是字符型且被转义可尝试宽字节注入如GBK编码下输入%df%27%df与转义符\结合形成合法汉字从而“吃掉”转义符使%27单引号逃逸。无回显注入盲注页面没有数据回显也没有错误信息。这时需要利用“布尔盲注”或“时间盲注”。布尔盲注通过页面返回的真/假如“存在”/“不存在”“登录成功”/“失败”状态来逐位推断数据。Payload如 and ascii(substr(database(),1,1))100 --通过二分法不断调整数值判断第一个字符的ASCII码。时间盲注通过页面响应时间来判断。Payload如 and if(ascii(substr(database(),1,1))100, sleep(5), 0) --如果条件为真则页面延迟5秒返回。5.2 自动化工具sqlmap的明智使用sqlmap很强大但无脑用会出问题。不要一上来就--dump-all这会产生大量流量可能拖垮测试目标或触发警报。应该循序渐进--current-db---tables--D dbname --columns--D dbname -T tablename --dump。善用--level和--risk参数Level越高测试的Payload越全面但速度越慢越可能触发WAF。Risk越高会使用风险更高的Payload如OR 11。通常从默认值level 1, risk 1开始。遇到WAF时使用--tamper参数调用脚本对Payload进行混淆。sqlmap自带很多tamper脚本如space2comment.py空格转注释、randomcase.py随机大小写。注意--batch模式这个模式会默认选择所有交互选项在你不熟悉目标时可能会进行破坏性操作。初期测试建议关闭手动确认。记录与学习使用-v参数提高输出详细程度-v 3会显示发送和接收的HTTP请求这对于学习Payload构造和理解绕过原理非常有帮助。5.3 企业级扫描器如奇安信报SQL注入的处置流程确认漏洞扫描器报出的不一定是真漏洞可能是误报。首先根据扫描器提供的URL和Payload手动复现。尝试构造简单的、and 11、and 12进行验证。定位代码根据漏洞URL参数在代码中定位到对应的SQL执行语句。全局搜索该参数名或接口。分析成因检查是使用了字符串拼接、.、format还是MyBatis的${}或是其他不安全的数据库操作方式。制定修复方案首选方案改为参数化查询/预编译语句。次选方案如果因历史原因改动困难对输入参数进行严格的白名单过滤或转义。对于数字型参数强制转换为整数intval()Integer.parseInt()。修复后验证修复后不仅要用扫描器重新扫描更要手动测试确保漏洞已修复且未引入新问题如功能异常。根源整改推动建立安全编码规范在团队内普及参数化查询的必要性并在代码审查环节加入对SQL语句的安全检查。SQL注入是一个“古老”但远未过时的话题。从手动构造Payload的技艺到理解参数化查询的底层原理再到在复杂框架和过滤规则下的绕过思路每一层都值得深入。靶场是练习场而真实世界的漏洞往往藏在那些不经意的${}和自以为安全的拼接函数里。真正的安全始于对每一行用户输入保持敬畏的编码习惯。
