Sqlmap使用中遇到的一个小破问题

本文因我一个不好的小习惯引起，于是我进行了一番探究

在一次攻防演练过程中，发现了靶标SQL注入，基于时间的盲注

使用 SQLMAP一把梭

SQLMAP 竟然没有跑出来，奇奇怪怪

难道是payload level/risk 较高？

设置 level 5 和 risk 3 也同样没有跑出来，这可有点难为我了，一个小破攻防，我还要写脚本，不可能！

开始探究

sqlmap 挂 burpsuite 看看返回值啥样（这里使用 -v 5 也是可以的）

我擦？？我这边输入一堆payload，你给我都返回 301 是啥意思呢？发到 repeater 重放一下，还是301, 见了鬼了（此处埋下一个大坑，已经看破的可以直接走了）

怎么整呢，生活还要继续呀？要么手写脚本，要么解决这个问题

更改Method

就在一筹莫展之际，小伙伴扔过来一个方法，将 POST 改成 GET ，之后使用 SQLMAP 进行注入

成功注入！

不正经的来了

当然，事实情况并不是如此顺利，因为网络问题，第一次GET并未成功，所以我怀疑sqlmap 中没有这个 payload ，于是走上了 sqlmap payload 修改之路，哎，都因为这破网，不然也不会掌握一门技能，在这里我就不写怎么修改，新增了，因为有一片文章写的贼好，我附上，如果哪天无聊，我想写再写出来吧,可以参考 

https://www.anquanke.com/post/id/188173

在 time_blind.xml 中，找到了如下 paylaod

这样看的话，sqlmap 中是有这个 payload 的呀，所以我就换了个环境，重新尝试了一下，果然使用 GET 方法可以跑出来

POST为什么不行呢？

像我这种不信邪的人，遇到这种问题高低得整明白，目前来看，导致 POST 方法有问题的就是这个301了，为啥GET不会产生 301 呢？

使用 burp change method

？？？GET方式也是返回301？？？那凭啥它就能成功呢？

经过一段时间的思考，我发现了一个小细节，我抓sqlmap的包，之后放到repeater里的是http的包，301 的 Location 地址就是其 https 的地址，难道说，使用 -r 数据包 的形式来注入，sqlmap 默认会使用 http 来进行探测？

推测到这里，我突然想到 POST 方式进行注入的时候，SQLMAP曾给过我选择：

估计这个地方大家都遇到过，每次都是因为有waf将我们的请求重定向到 error.aspx 这类，所以已经习惯了选择 no，看来这次真的是栽在这了！

这回真相了，以后使用数据包来进行注入的时候，千万得注意https，如果我们希望sqlmap 默认使用 https 进行测试的话，可以使用 --force-ssl 来进行测试

吃一堑长一智，溜了溜了...