sql注入随笔
最近挖了一些漏洞，还挺有意思的。这边分享两个需要细节一点才能挖到的sql注入，希望给大家带来一些漏洞挖掘思路。
黑盒是很有意思的，有趣的。
1.搜索功能的隐藏sql注入，post data数据内容如下:
{"product":"","offer":"DIV","variant":"*","search":""}
探测的时候发现这些参数都不存在注入
开始第二次尝试,当删除json体中某个参数后，variant参数触发报错注入:
{"product":"","variant":"*","search":""}
结论:测试漏洞的时候，记得删除参数。可能某个参数起到了健全的作用。
2.搜索功能的order by隐藏注入，post data数据包内容如下:
Origin: Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8 number=0&size=10&sortField=id*&sortOrder=desc&playerUsername=&uid=
对数据包进行正常发包:
发包返回当前搜索的所有数据。因为有sortField参数，所以我格外注意测试order by注入。这里我对每个参数进行了sql注入测试，发现并不存在order by和其他类型的sql注入。
直觉告诉我，可能有漏洞。我想坚持fuzz下，如果我放弃了，那么一个高风险漏洞都没有了。
fuzz参数发现当post data参数为:
Origin: Sec-Fetch-Site: same-origin Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8 number=0&size=10&sortField=id&sortOrder=desc&playerUsername=%25&uid=
这里我为playerUsername赋值%25后，正常发包后，他的返回和上面第一个数据包的返回内容一致。
但是这个赋值不一般，直接导致了sortField参数可以受到order by注入攻击，直接触发sql语句报错。
很神奇，这个点真的很神奇。也可以说是意外之喜。然后就是出数据，证明是sql注入:
结论:遇到敏感的参数，一定要坚持下！不然可能错过高风险安全漏洞。
