TangScan插件审核细则
一、首要原则
插件不可误报，在保证这个基础的前提下尽量保证不漏报。
二、插件标题
插件标题格式规范：xx应用xx页面（xx参数）xx类型漏洞
审核某个插件前先根据其标题和代码去搜索下此漏洞的插件有没有白帽子提交过
三、插件信息
四、插件代码
五、防止误报
文件读取类插件在判断时关键字一定要特殊且针对对应的应用比较通用，response.content.find(‘index’)之类的判断一定不要出现！能使用正则，则尽量使用正则去匹配结果。
命令执行/文件上传类的插件在写文件证明方面也不可用简单的关键字去判断，如：上传 然后访问上传的文件判断response.content.find(“uploadtest”)!=-1来证文件上传成功，这里有很明显的错误：如果上传目录不能解析会如何？所以命令执行/上传文件在证明方面尽量采用运算，如：ASP:<%response.write(1+2333332)%>、PHP：、JSP:<%out.print(1+2333332);%>访问上传的文件，判断结果中有无2333333即可证明。[当然也可以使用md5、base64去计算出一个字符串然后匹配]
注入类的插件非盲注类型一般必用re去匹配结果，如：
为何MSSQL使用的是”+’~’+@@version+”+’~’而不是’~’+@@version+’~’;MYSQL使用的是concat(0x7e7e7e,version(),0x7e7e7e)而不是concat(‘~’,version(),’~’)?
因为一些webserver在异常时会抛出错误原因及请求参数，如：xxx页面发生错误，错误原因xxxx、请求参数id=1′ union select 1,concat(‘~’,version(),’~’)# 这时re依然会匹配到结果导致误报！
在对应漏洞的验证方面，payload也要尽量精简高效且考虑规避WAF，不能生般硬套主站的漏洞内容！
六、列举几类典型错误
1.欢乐多型
2.不细心型
3.易误报型
4、信息错乱型
5、代码错误导致误报型
6、没事测试型
就不上图了
七、审核规则
插件按高、中、低的漏洞等级依次给5、3、1汤圆（改动/修改错误较多的酌情扣取一定数量汤圆）；优质漏洞插件/悬赏插件酌情多给汤圆（现阶段还未实施）；插件审核顺序为先提交先审核（后台积压插件较多时优先审核新注册用户的插件以及时发放邀请码）
最后，欢迎各位白帽子来乌云TangScan提交插件，这里不仅可以拿汤圆、交基友，而且还可以学习到更多的东西。
云悉指纹