Michele

场景一、orderby和联合查询注入的组合portswigger靶场sql注入第三题。这里是orderby和联合查询注入的组合。 整个流程大概是这样的： 1、'单引号测试 →确认存在注入【报语法错误】 2、order by猜列数 →得知原始查询返回 2 列 这道题是通过 ‘ order by 3 – 判断原始查询有多少列 【order by n 按查询结果的第n列排序】 UNION 联合查询有硬性规则：前后两个 select 返回的列数量必须一模一样。所以必须先测出原始 SQL 返回多少列。 3、union+常量字符串‘a’‘b’测试哪些列可以回显字符串。 在这里有两个作用：验证数据库（Oracle 需要 FROM dual 才不报错）、看页面输出确认哪些列是网页回显位（没有回显的就不是） 由上一步查出有两列，所以这里要构造的语句是： 查询1 UNION SELECT 字段1,字段2 FROM 表名 4、把想要查询的数据放到回显列，其余位置用常量占位，完成数据窃取。 1category=Gifts' UNION SELECT banner,'x&#...

这个题目给了提示说登录 administrator 这个账号，payload 一把就过了。但是我想到一个问题：实战里你根本不知道账号叫什么啊，这题换个环境还能打吗？ 场景一：登录界面不知道账号怎么办？题目直接告诉用 administrator，实战不可能有这种好事。拿到一个登录框，第一步不是急着注入，先搞清楚账号长什么样。 查了一下，大概就是这几种办法： 爆破字典。拿一个常见用户名字典（admin、administrator、root、test、system、manager 这些）去跑，看哪个能命中。最常见的方式。 信息收集。如果目标是企业站，去 LinkedIn 找 IT 管理员的名字，去 GitHub 搜公司名看有没有泄露的测试账号。发现邮箱格式是 zhangsan@company.com，那用户名大概率就是 zhangsan、zhangs 或者 zs。 用户名枚举。这个比较容易被忽略。有些网站登录报错信息不一样——输 admin 提示”密码错误”，输 admin123 提示”该用户不存在”，这就等于告诉你 admin 是真实存在的。还有些系统验证存在的用户和不存在的用户，...

皮卡丘靶场解题记录-SSRFSSRF（curl）1、漏洞原理总结：URL 跳转 = 服务器告诉你”那家店在那”，你自己去；SSRF = 服务器说”你要啥我帮你跑腿去拿”，结果服务器替你去了内网/不该去的地方，还把东西带回来。 2、我的测试过程： 3、核心漏洞代码分析：12345678910111213141516if(isset($_GET['url']) && $_GET['url'] != null){ //接收前端URL没问题,但是要做好过滤,如果不做过滤,就会导致SSRF $URL = $_GET['url']; $CH = curl_init($URL); curl_setopt($CH, CURLOPT_HEADER, FALSE); curl_setopt($CH, CURLOPT_SSL_VERIFYPEER, FALSE); $RES = curl_exec($CH); curl_close($CH) ;/...

皮卡丘打完之后，想找点更接近真实环境的靶场练手，就上了 PortSwigger。结果第一个就踩了坑：一个很简单的搜索型 SQL 注入，试了几种写法结果前后不一致——有的能成功，换一种就报 Internal Server Error。 这样能成功： 这样也能成功： 但换成这个就失败： 1https://0a9d007104202ecc80cc0da60077001d.web-security-academy.net/filter?category=Pets' or 1=1 # 查资料加几轮尝试，才发现是三个坑叠在了一起。 坑一：数据库语法有细微差别我之前一直学的 MySQL，注释 -- 和 # 都能用；但 PortSwigger 这个靶场用的是 PostgreSQL，注释只能用 -- （前后都得有空格）。实战拿不准数据库，就先上 sqlmap 测一下。 顺手把四个库的语法差异整理成了速查： 注释符 MySQL：-- （注意后面有空格）、# PostgreSQL：-- SQL Server：-- Oracle：-- # 只有 MySQL 能用，这就是我刚才...

皮卡丘靶场解题记录-URL重定向1、漏洞原理总结：略，见后文 2、我的测试过程： 把url参数修改为外部url即可 成功 3、核心漏洞代码分析：123456789if(isset($_GET['url']) && $_GET['url'] != null){ $url = $_GET['url']; if($url == 'i'){ $html.="<p>好的,希望你能坚持做你自己!</p>"; }else { header("location:{$url}"); // 接收前端传的 url，直接跳过去，没做任何白名单校验 }} 靶场代码如上，同样是跟前面的关卡类似的原理，总之，用户可控制的信息都不可信。 这里的url是外部传入的，可以被修改 4、实战延伸： 参数名 出...

皮卡丘靶场解题记录-XXE1、漏洞原理总结：xml：类似html，用成对的标签把数据包起来，用于结构化地存储数据。 1234<人> <姓名>张三</姓名> <年龄>20</年龄></人> DTD：xml顶部的声明区，类似于术语说明，约定好什么符号代表什么。 实体（ENTITY）：xml里面的变量。在DTD里声明，然后在正文里用 &名字; 引用，解析器会自动把 &名字; 替换成它代表的内容。类似于开头写A=xxxxxxx,后面全文写A，然后解析器会自动把A替换成xxxxxxx。 内外实体的区别： 类型 值从哪来 写法 内部实体 值写死在 DTD 里 <!ENTITY hacker "ESHLkangi"> 外部实体 值去读外部文件/URL <!ENTITY f SYSTEM "file:///etc/passwd"> SYSTEM 这个词 = “值不是写死的，去系统里取”。 比...

皮卡丘靶场解题记录-PHP反序列化1、漏洞原理总结：要搞懂php反序列化，首先要了解两个函数,serialize()和unserialize() 函数 作用 白话 serialize() 对象 → 字符串 把对象打包成快递箱（方便传输/存储） unserialize() 字符串 → 对象 收到快递拆箱还原成对象 同样这里也是信任了用户。这里的序列化的内容是由用户放入的，但反序列之后并没有检查内容，就直接使用了。 2、我的测试过程： 3、核心漏洞代码分析：123456789if(isset($_POST['o'])){ $s = $_POST['o']; if(!@$unser = unserialize($s)){ $html.="<p>大兄弟,来点劲爆点儿的!</p>"; }else{ $html.="<p>{$unser->test
...

皮卡丘靶场解题记录-敏感信息暴露1、漏洞原理总结：开发者疏忽，把不该让用户看到的东西暴露出来了。它本身危害低，但往往是进一步攻击的跳板。有三种典型形态： 形态 例子 ① 目录列出 直接访问目录 URL，服务器把文件列表列出来 ② 报错泄露版本 输入错误参数，报错信息里带出操作系统/中间件/语言版本 ③ 前端源码泄露 HTML/CSS/JS 里藏了后台地址、内网接口、甚至账号密码 2、我的测试过程： 测试账号都直接放出来了 放账号密码的表单是get提交 3、核心漏洞代码分析：略 4、实战延伸： 拓展，目录列出： 首先要知道访问文件和访问目录是两回事。 访问 例子 服务器行为 一个文件 /infoleak.php 执行/返回这个文件 → 你看到网页 一个目录 /vul/infoleak/ 服务器要决定给你看什么（见下 平时访问 xxx.com/（根目录）能看到网页，是因为那个目录里有个 index.php / index.html，服务器默认把它当首页返回给你。这是有 in...

sqlmap-auto项目复盘（持续更新…）2026.8.31最近在练习sql注入，然后觉得sqlmap差点意思，每次敲命令行很烦，就想着能不能自己搓一个skill让agent代劳。然后就搓了这个Michele-deng/sqlmap-auto目前这个版本,emmm,没我想象中好用，目前在中级靶场里试了一下，emmm，速度还算正常，但完全没有想象中的效果。。。。 我一开始对它的设想是，给它一个url，就自动帮我跑完里面sql注入的全过程了，当然我也知道在有很多前置验证的情况下这个要实现起来是有困难的，我的这个设想也非常的粗糙，过于理想化了。我想要能在真实环境里能用来实战的东西。 【插点题外话，这段时间也越来越摸到agent能力的边界了，并非我很久之前想的那样一切东西都能交给它完美完成，还是要以人作为主导的，让工具跑在人前面的结果就是，token烧了很多，结果事情只推进了一点，或者直接南辕北辙了。之前有几个月我还一直很担心以后agent发展起来我要靠什么吃饭来着，果然恐惧源自未知。然后就是，怎么说呢，我觉得ai的发展反而，emmm，像是形成了新的一种门槛，筛选掉容易被替...

皮卡丘靶场解题记录-SQL注入数字型注入1、漏洞原理总结：sql语句给数据库下达指令，用户的恶意输入破坏原语句，被当成正常语句执行。 2、我的测试过程：抓包，修改传参1为1 or 1=1 与原本的查询语句拼接起来即为： 1select username,email from member where id=1 or 1=1 因为 1=1 恒真，where id=1 or 1=1 相当于 where 恒真，全表返回 直接出结果 3、核心漏洞代码分析：对输入没做处理，直接被拼写进查询语句里面 4、实战延伸： 字符型注入1、漏洞原理总结：数字型没引号直接拼；字符型有引号，要先闭合引号、再注入、最后用#注释掉尾部 2、我的测试过程： 出结果 3、核心漏洞代码分析：同样没做变量处理，但是这里变量变成了字符，需要考虑闭合 1234567891011121314151617if(isset($_GET['submit']) && $_GET['name']!=null){ //这里没有做任何处...