文章目录【好靶场】SQL注入-POST类型注入-1 实战记录概要整体架构流程技术名词解释漏洞修复建议小结【好靶场】SQL注入-POST类型注入-1 实战记录概要该文章记录个人通过靶场sql注入-POST类型注入-1的过程。关于 POST 的吐槽与补充打完这关我很想吐槽POST 究竟体现在哪因为靶场太保姆级给了个可视化输入框连抓包的机会都不给。在真实渗透中POST 注入通常要开 Burp Suite 拦截在请求体Body里改参数而不是像 GET 那样在 URL 改。虽然也有大佬全程纯抓包改 Body 通关那样确实更还原但我这里还是用了输入框。万变不离其宗脱库逻辑是一样的。整体架构流程首先开启靶场你能看到一个如下的界面你可以看到一个输入框这时候就可以开始尝试了。第一步你要试出来这个是字符串型还是数字型。首先输入1并点击搜索试试没啥返回内容这里可能因为数据库里没1这个内容所以前面没回显。接下来直接试试1能看到回显sql语法错误也就是说这个时候肯定不是完整闭合的。如果是数字型就是我们多塞了个如果是字符串型就是后面多了个。接下来我们直接输入#注释来看看加入#发现界面恢复正常也就是说是字符串型后面多了我们给它注释了就正常运作了。接下来我们该判断当前这个查询的表里面有多少个列然后其中有多少个列是回显到前端的。这里我们使用order by语句并用二分法快速确定。最后得到列数是7。得到列数后我们可以使用联合查询先看看页面回显了哪些列。这里我们可以看到这七个列全给回显了。也就是说我们可以随便挑一个列作为注入点输入 payload。这里我选择位置2。先输入database()来确定一下当前的库名通过图片可以看到当前库名是sql_injection_lab。接下来我们可以查询一下该库里面有哪些表payload1 union select 1,group_concat(table_name),3,4,5,6,7 from information_schema.tables where table_schemasql_injection_lab #我们可以看到这个库里有两个表分别是users和flag一般来说目标就在flag表里所以我们优先看看这个表。payload如下1 union select 1,group_concat(column_name),3,4,5,6,7 from information_schema.columns where table_nameflag #从图中可以看出来这个flag表里有两个列id和flag。依旧按照惯性先看flag这个列。payload1 union select 1,(select flag from flag),3,4,5,6,7 #最后拿到结果flag{4dcb7af0711841d698317e780287d79d}(注该类在线靶场通常为动态生成环境。如果在本地或新窗口复现时报错需优先通过information_schema查询当前环境的真实结构。)技术名词解释UNION SELECT联合查询要求前后查询的列数必须完全一致常用于将我们构造的查询结果拼接到原本的回显位上。information_schemaMySQL 自带的系统库记录了所有数据库、表、列的信息。在不知道目标结构时优先查询此库获取基础信息。子查询形如(select flag from flag)将内部的查询结果作为单一值直接填入外层查询的对应位置。漏洞修复建议预编译不让代码和数据混在一起后台先把 SQL 的架子搭好比如留个问号你输入的任何字符都只会被当成纯文本去匹配你的注入直接变成废铁。输入校验安检门后台严格限制输入格式比如纯数字把你输入的引号、括号全给转义或干掉。最小权限原则不给黑客留后路数据库账号只给查询特定表的权限就算你注进去了也查不到别的东西更别提提权了。小结本次实战印证了动态靶场环境的不确定性。相较于死记硬背某一套 Payload掌握通过information_schema逐层探测库名、表名和列名的系统化逻辑才是应对不断变化的环境、稳定挖掘出目标数据的核心能力。
文章目录【好靶场】SQL注入-POST类型注入-1 实战记录概要整体架构流程技术名词解释漏洞修复建议小结【好靶场】SQL注入-POST类型注入-1 实战记录概要该文章记录个人通过靶场sql注入-POST类型注入-1的过程。关于 POST 的吐槽与补充打完这关我很想吐槽POST 究竟体现在哪因为靶场太保姆级给了个可视化输入框连抓包的机会都不给。在真实渗透中POST 注入通常要开 Burp Suite 拦截在请求体Body里改参数而不是像 GET 那样在 URL 改。虽然也有大佬全程纯抓包改 Body 通关那样确实更还原但我这里还是用了输入框。万变不离其宗脱库逻辑是一样的。整体架构流程首先开启靶场你能看到一个如下的界面你可以看到一个输入框这时候就可以开始尝试了。第一步你要试出来这个是字符串型还是数字型。首先输入1并点击搜索试试没啥返回内容这里可能因为数据库里没1这个内容所以前面没回显。接下来直接试试1能看到回显sql语法错误也就是说这个时候肯定不是完整闭合的。如果是数字型就是我们多塞了个如果是字符串型就是后面多了个。接下来我们直接输入#注释来看看加入#发现界面恢复正常也就是说是字符串型后面多了我们给它注释了就正常运作了。接下来我们该判断当前这个查询的表里面有多少个列然后其中有多少个列是回显到前端的。这里我们使用order by语句并用二分法快速确定。最后得到列数是7。得到列数后我们可以使用联合查询先看看页面回显了哪些列。这里我们可以看到这七个列全给回显了。也就是说我们可以随便挑一个列作为注入点输入 payload。这里我选择位置2。先输入database()来确定一下当前的库名通过图片可以看到当前库名是sql_injection_lab。接下来我们可以查询一下该库里面有哪些表payload1 union select 1,group_concat(table_name),3,4,5,6,7 from information_schema.tables where table_schemasql_injection_lab #我们可以看到这个库里有两个表分别是users和flag一般来说目标就在flag表里所以我们优先看看这个表。payload如下1 union select 1,group_concat(column_name),3,4,5,6,7 from information_schema.columns where table_nameflag #从图中可以看出来这个flag表里有两个列id和flag。依旧按照惯性先看flag这个列。payload1 union select 1,(select flag from flag),3,4,5,6,7 #最后拿到结果flag{4dcb7af0711841d698317e780287d79d}(注该类在线靶场通常为动态生成环境。如果在本地或新窗口复现时报错需优先通过information_schema查询当前环境的真实结构。)技术名词解释UNION SELECT联合查询要求前后查询的列数必须完全一致常用于将我们构造的查询结果拼接到原本的回显位上。information_schemaMySQL 自带的系统库记录了所有数据库、表、列的信息。在不知道目标结构时优先查询此库获取基础信息。子查询形如(select flag from flag)将内部的查询结果作为单一值直接填入外层查询的对应位置。漏洞修复建议预编译不让代码和数据混在一起后台先把 SQL 的架子搭好比如留个问号你输入的任何字符都只会被当成纯文本去匹配你的注入直接变成废铁。输入校验安检门后台严格限制输入格式比如纯数字把你输入的引号、括号全给转义或干掉。最小权限原则不给黑客留后路数据库账号只给查询特定表的权限就算你注进去了也查不到别的东西更别提提权了。小结本次实战印证了动态靶场环境的不确定性。相较于死记硬背某一套 Payload掌握通过information_schema逐层探测库名、表名和列名的系统化逻辑才是应对不断变化的环境、稳定挖掘出目标数据的核心能力。
