ics-06工控SQL注入实战：从目录扫描到联合查询拿flag

1. 题目定位与整体思路拆解

1.1 这道题到底在考什么

攻防世界Web入门区的ics-06，题目标签写得很清楚：Web、工控。刚点进去的时候，页面很简单，没有什么花里胡哨的东西，就是一个工控系统的登录或信息面板界面。很多新手一上来就盯着登录框去暴力破解或者猜密码，结果浪费了大量时间。实际上这道题的核心考点非常经典——SQL注入获取后台敏感信息，而且它把工控场景和Web安全结合在了一起，算是一个很典型的“披着工控外壳的SQL注入题”。

题目来源是攻防世界的入门题，难度评级写的是“简单”，但它并不是那种让你直接看到flag的送分题。它考察的点比较综合：目录扫描、参数发现、注入点判断、联合注入查询、flag定位，一环扣一环。对于刚接触CTF的Web选手来说，这道题是一个非常不错的练手素材。

1.2 为什么推荐新手拿这道题练手

我见过不少刚入门的选手，一上来就刷那种很难的题目，结果被各种WAF绕过、二次编码、堆叠注入劝退，最后连基础的手工注入都没掌握。ics-06这道题的好处在于：

• 没有WAF，注入过程很“干净”，适合用来建立手工注入的完整流程感。
• 页面元素少，攻击面清晰，能让新手学会怎么从无到有地分析一个Web应用。
• 工控背景是一个很好的场景延伸，让你知道在真实业务中，SQL注入往往就藏在这些不起眼的接口后面。
• 网上的Writeup虽然不少，但很多都写得比较简略，直接说“注入report.php?id=1”就完了，把中间的思考过程全部略掉了，这恰恰是新手最需要的部分。

所以这篇Writeup我会尽量把我当时一步步尝试、踩坑、回退、再尝试的过程还原出来，不只是给你最终答案，更希望你能通过这个案例把“手工注入”这一整套套路真正吃透。

2. 信息收集与入口发现

2.1 页面观察：别急着动手，先看

题目打开之后，我先把页面从头到尾看了一遍。这个页面模拟的是一个工控系统的监控后台，界面上有一些设备状态、数据指标之类的信息，但绝大多数功能按钮点击之后并没有实际响应。我试了一下登录功能，随便输了几个账号密码，提示的是“用户名或密码错误”，这说明后端确实是查询数据库的，不是纯前端假页面。

但是，问题在于：我并不知道后台存了哪些用户，直接猜用户名是一种效率极低的方式。而且从题目设计的角度来看，凡是那种“点击基本没反应、登录框又没有验证码”的题，大概率真正的漏洞点并不在登录页面本身。

这里有一个很重要的经验：CTF题目里，凡是你能直接看到的功能点，往往是诱饵或无关功能；真正的问题往往藏在目录里的某个脚本文件下。 所以我很快放弃了在登录页面上死磕，转向了目录扫描。

2.2 目录扫描：找到真正的接口

目录扫描这一步，工具上我用的Dirsearch，因为比较轻量，字典也丰富。命令很简单：

bash复制python dirsearch.py -u http://<target-ip> -e php,html,txt

扫描结果里出现了不少常见文件，比如index.php、robots.txt、login.php，这些都比较常规。但有一个文件非常扎眼：report.php。

为什么说它扎眼？因为在正常工控系统里，report（报表）功能是很常见的，但它通常会和权限绑定，不会直接暴露在公开目录下。而在这道题目场景里，report.php出现在扫描结果中，意味着它可能是一个开发调试时遗留的接口，或者就是题目故意留下的入口。

访问report.php之后，页面显示了一段文字，大意是“找到设备管理页面的入口，并提交查询请求”，具体内容我记不太清了，但核心是要让你通过某种方式触发设备上报。这时候页面上的表格、设备ID列表等数据，都是可以通过URL参数来控制的。

2.3 参数发现：flag藏在哪里

访问report.php，页面上有一个设备ID列表，点击某个ID，URL会变化。实际抓包之后看到的是这样的：

http复制GET /report.php?id=1 HTTP/1.1
Host: <target-ip>

id参数非常显眼，而且它的值是直接拼在URL里的。如果你在浏览器里把id=1改成id=2，页面上的内容会跟着变化——这说明id参数是被后端接受并且参与数据库查询的。

这时候已经基本可以确定注入点就是id了。但这里要提醒大家一句：看到参数就注入，是新手很常见的毛病。 至少应该先确认一下这个参数是不是真的被后端用了、它是什么类型的值、查询出来之后页面会不会回显结果。确认了这些，后面的注入才会比较顺利。我在确定id是查询参数之后，还顺手试了一下id=1'，页面直接报错，回显了一条SQL语法错误的信息。好，没问题，注入点坐实了。

3. SQL注入的核心环节与关键实现

3.1 注入类型判断：是数字型还是字符型

先用最简单的办法判断类型。id=1 正常回显，id=1' 直接报错，说明这里很可能存在数字型注入——因为数字型注入不需要闭合单引号，你丢一个单引号进去反而会破坏原有的SQL语法。

我接着用id=1 and 1=1和id=1 and 1=2做对比测试：

• id=1 and 1=1：页面正常显示ID为1的设备信息。
• id=1 and 1=2：页面没有任何数据返回，但没有报错。

这种表现说明我的判断是对的：and 1=1为真时正常查询，and 1=2为假时查询为空。后端的SQL语句大概长这样：

sql复制select id, name, ... from <table> where id = $id

注意这里我把id写成$id，没有加引号，这就是数字型注入的典型写法。如果是字符型，SQL会是where id = '$id'，你注入的内容就需要先闭合单引号才能生效。数字型少了闭合这一步，做起注入来会省不少事。

很多Web入门阶段的朋友可能会想：为什么题目不设置成字符型的呢？其实这不是题目放水，而是很多真实业务系统里，开发者确实会把数字类型的参数直接拼进SQL，觉得“数字不可能注入”。可恰恰是这种轻视，导致了大量本可避免的漏洞。

3.2 确定字段数：order by 打法

知道是数字型注入之后，下一步就是确定select查询的字段数。这一步的意义在于：后续使用union select时，你需要让前后两个查询的列数保持一致，否则数据库会报错。

方法是用order by不断递增数字，观察页面在哪一个数字时报错或者行为改变：

http复制GET /report.php?id=1 order by 1
GET /report.php?id=1 order by 2
GET /report.php?id=1 order by 3
...
GET /report.php?id=1 order by 5

在order by 3之前页面都比较正常，order by 4开始出现错误提示。这基本说明查询结果只有3列。用一条更直观的SQL来理解：

sql复制select a, b, c from devices where id = 1 order by 4

order by后面的数字代表的是第几列，4已经超出了查询列的范围，所以数据库直接报错。通过这种方式，我们就确定了这个查询语句一共返回3列。

注意：order by报错时，不同数据库的错误提示不太一样，有些比较隐晦（比如直接返回500），但这道题还算友好，报错信息写得非常具体。如果你在测试其他题目时碰到不太友好的报错，可以结合响应长度来判断：请求正常时响应长度是一个固定值，一旦异常，长度会明显变化。

3.3 联合查询：从试探到拿到版本信息

字段数确定之后，union select就可以派上用场了。目标很明确：先拿到数据库的版本、当前数据库名，然后再去找我们需要的数据表。

先构造一个基础payload：

http复制GET /report.php?id=1 union select 1,2,3

如果页面正常显示了设备信息，并且出现了2或者3这样的数字，说明第2列或第3列是回显点。实际情况是，页面上确实显示了数字2和3，说明这两列的内容会被原样输出到页面上，这就是我们可以利用的位置。

那么接下来要替换回显点的内容，把数据库信息查询出来：

http复制GET /report.php?id=1 union select 1,database(),version()

页面上第2列展示了当前数据库名，第3列展示了数据库版本。我记得当时查出来的数据库版本是MySQL 5.x。这里有个小知识：MySQL 5.0以上版本，information_schema库里包含了所有数据库、表名、列名的元数据，拿到版本信息之后我最关心的就是能不能用information_schema把整个库结构扒出来。

用生活化的方式说：information_schema就像是数据库的“户口本”，每个库、每张表、每个字段的信息都记录在里面。你只要能查这个“户口本”，就等于拿到了整个数据库的目录。

3.4 爆表名、爆字段名、拿flag

接下来就是标准的“三步走”：查表名、查字段名、查数据。

第一步，查当前数据库下有哪些表：

http复制GET /report.php?id=1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=database()

group_concat可以把多行结果拼成一行输出，这样页面上就能一次性看到所有表名。这比一条条查要高效得多，也是手工注入里非常常用的函数。返回的结果里有一张表叫cetc（我印象里是这个名字），还有一张表叫user。直觉告诉我，flag很可能不在user表里，因为题目强调的是“设备管理”，数据应该和设备相关。但为了保险，我还是两张表都查了一下。

第二步，查看cetc表的字段结构：

http复制GET /report.php?id=1 union select 1,group_concat(column_name),3 from information_schema.columns where table_name='cetc'

查询结果是：flag。到这基本就锁定目标了——cetc表里只有一个字段，明摆着就是藏flag用的。

第三步，查字段内容：

http复制GET /report.php?id=1 union select 1,flag,3 from cetc

页面直接返回了一个长字符串，开头就是flag{...}。到这里，这道题的核心流程就走完了。

说实话，这一步做完之后我是有点感慨的：整个注入过程只用了4次SQL查询就拿到了flag，没有任何绕WAF、绕过过滤之类的花活，这就是一道非常“教科书”的数字型union注入。如果你能完整走一遍这个过程，后续再遇到类似题目，思路就会清晰很多。

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

4.1 参数被过滤？先分清楚是“拦截”还是“无效”

很多新手在测试注入时，一旦发现参数加了单引号后页面没有反应，就立刻怀疑“是不是有WAF”。这种判断太草率了。WAF拦截通常会有明显的特征：返回403、返回一个拦截页面、或者请求直接超时。而如果页面只是正常显示但内容没变化，那更可能的原因是参数类型没对上，或者注入点根本不在这里。

ics-06这道题里，id参数的注入表现非常“听话”，几乎不存在过滤问题。但在其他题目里，如果碰到过滤，正确的思路是：

• 先确认单引号会不会触发报错，试试id=1'，观察页面是否有异常输出。
• 再试试id=1 and 1=1和id=1 and 1=2，看响应是否有差异。
• 如果确实存在过滤，再考虑用大小写、注释符、内联注释、编码绕过等手段。

入口判断永远是第一步，入口判断错了后面全是白费。

4.2 扫描器扫不到report.php怎么办

这道题的report.php是靠目录扫描发现的。有的朋友可能会遇到扫描器字典不够全、扫不出这个文件的情况。我的建议是：

• 换字典。Dirsearch自带的字典比较均衡，但如果你只是浅扫了一遍，不一定能扫全。还可以试试dirmap、ffuf这类工具，配合更完整的字典。
• 根据题目背景猜路径。工控系统常见路径有admin.php、report.php、system.php、monitor.php等。如果扫描器扫不出来，可以手工把这些路径挨个试一遍。
• 注意观察首页源码。有些题目会在页面源码、JS文件里留下接口路径的注释，这也是信息收集的重要一环。

4.3 字段数判断不准确导致union查询一直失败

这是最典型的卡壳环节。我见过不少人在union select这一步反复失败：页面要么报错，要么根本不回显数据。原因基本都出在字段数没对上。这里分享一个笨办法：如果你不确定字段数，可以从order by 1开始，一条一条往上试，不要跳着试。比如你试到order by 5时报错，那字段数就是4，然后你构造union select 1,2,3,4，一定不会因为列数不一致而报错。

另外，union select在MySQL里有还有个坑：id=1 union select 1,2,3虽然能回显1,2,3，但如果前半段查询结果本身就是空的（比如id=999999），那么union后面那个查询的结果才会被显示出来，且回显位置会稍微有点不一样。为了更干净地观察回显点，可以把id改成一个不存在的值，比如id=-1，这样前一条查询结果为空，union后的内容就是唯一的输出源了。

4.4 常见问题速查表

4.5 注入过程中的几个小细节

这里再补充几条实操心得，都是我在做题或者说在写Writeup时比较在意的地方。

第一，别急着用sqlmap。我知道很多人第一步就喜欢上sqlmap，一条命令搞定。但对于入门阶段的题目，手工注入才能帮你建立真正的“手感”。sqlmap上瘾之后，你很容易变成一个只会敲命令的“脚本小子”，遇到稍微偏一点的题就完全没方向。我建议至少前面20道Web注入题都用手工的方式做，哪怕慢一点。

第二，注意观察响应长度。有时候单引号报错并不体现在页面上，而是体现在响应的数据包长度上。通过Burp Suite的“Compare”功能或者直接看HTTP响应大小，你会发现异常非常明显。这个方法在做盲注时尤其好用。

第三，提交flag前再三确认格式。CTF题的flag一般都有固定格式，比如flag{...}。有些题目的flag不是放在页面上直接显示，而是需要你再进一步操作（比如在管理后台里找到），所以拿到字符串之后不要着急复制提交，先看一眼是不是完整的、有没有被截断。我见过有人因为页面换行把flag折断了，结果复制到一半少了一段，白白丢分。

5. 复盘与扩展思考

5.1 从ics-06延伸到真实工控安全

做完这道题之后，我特意去查了一下真实工控系统中的Web管理后台。实际上，很多工控设备（比如PLC、SCADA系统的上层软件）确实会自带Web管理页面，用于设备状态查看、参数配置、报表导出等。这些页面如果暴露在互联网上，或者内网中权限控制不到位，SQL注入、弱口令、未授权访问等问题层出不穷。

ics-06这道题虽然是CTF，但它的场景设计是有现实依据的：设备报表查询功能、后台设备ID参数、隐藏的管理入口。现实中，攻击者很可能就是通过类似report.php?id=1的接口，用SQL注入把整个数据库翻个底朝天。这给我的一个很大的提醒是：在做Web安全测试时，不要只盯着登录框和高权限功能点，一些看起来不起眼的查询接口，反而可能成为突破口。

5.2 这道题还能怎么变

如果你觉得自己已经把这道题吃透了，可以试着给自己加一些变体练习：

• 把数字型改成字符型：如果id参数变成id='1'，你的注入语句要怎么调整？闭合引号、处理注释符，流程会复杂不少。
• 把回显改成盲注：如果页面不展示查询结果，你只能用true/false判断，怎么用二分法查出flag？
• 加上简单的过滤：如果题目把union、select这些关键词过滤了，你需要考虑注释符拆分、内联注释/*!50000union*/、等价函数替换等手段。

这几个变体能帮你把SQL注入这一支真正练扎实，也算是从这道入门题出发的进阶方向。

5.3 最后再分享一个小技巧

做这类题目的时候，我习惯在Burp Suite里把整个请求过程按顺序存下来，包括每一步的payload和响应结果。这样不只是为了写Writeup方便，更重要的是，当你在某个环节卡住的时候，翻一下之前的尝试记录，往往能发现“原来我是在第三步就已经走偏了”的问题。CTF解题最忌讳的就是闷头乱试，觉得这条路不行就换一条，但没有任何记录，最后连自己试过什么都不记得。

我自己踩过不少这样的坑：盲注一半发现前面字段数判断错了，回头重新走，浪费了大把时间。有了记录，回溯速度会快很多，也更容易形成一套自己的测试方法论。

如果你能按照这篇Writeup的流程把ics-06完整做下来，并且理解了每一步背后的原理，那我基本上可以确定，你在Web入门这一块算是站稳脚跟了——接下来那些更难一点的SQL注入题，无非是给它加上各种限制条件罢了。