记一次POST数据中JSON参数存在SQL延时盲注

起因是burp能测出注入点，放到sqlmap中却怎么也跑不出来，难道真得手注吗？经过一番折腾终于搞定sqlmap。

1.xray探测存在注入

2.手工复测确定注入点为body中的json数据中的name值。 “ ’ ” 分号闭合，确定为时间盲注

3.保存post包上sqlmap跑，怎么都跑不出来，期间想到用*标注注入点、用\转义name中的”，均失败。

4.使用-vvvvv查看sql发包情况

默认先测前面的type参数，回包中均有302，但不影响，继续往下翻，翻到最后发现一直在type中加payload，name直接跳过了。

5.这次在数据包中直接*标注name参数，免得打偏。

开始跑......

Cookie parameter ...这个选择y sqlmap直接停止。只能选择n，继续跑...

这次看着挺好，payload加对位置了，此payload手工测试没问题。

但还是没跑出来。。。

拿上面的数据包到burp中跑，测试正常延时，那是咋回事？

后来将数据包拿到burp中跑的时候发现，需要手工设置主机和端口

随后想到是不是端口问题？主机域名后面加上443端口再跑！

这次直接跑出来了。

最后总结一下：

1.sqlmap中的 -vvvvv参数真的挺好用。

2.在burp中手注发现注入点后，复制数据包放到sqlmap跑的时候需要手动加端口，burp中3.自动加，但是sqlmap需要手动加。

4.还一个重要的点，，没加端口使用sqlmap跑的时候，开始跑之前就会出302，让我选y，可能是没加端口的时候是80端口，所以302到443，，但这时候跑不出来，且看sqlmap的响应包中每个请求都有302响应，给人感觉一直请求的目标就不对。。后来加上443端口sqlmap的响应包就成200了，也能注成功了。

5.查看sqlmap  HTTP request发现一直到32个包才开始加入payload，不明白为啥。

6.最开始的时候，还出现了payload加在””后面，如”name”:”” ‘ and select，最后跑不出来，后来直接将name的值的””删除，发现payload正常了。

7.后面又发现可以直接将type参数删除，只保留name也能行，可避免注到type中去。

80时候老302

回包中也是302，所以不对。