10、其他
①支持不推荐使用的SSL版本
只需要开发同学修改配置即可。
②Cookie中无HTTPonly属性
只需要开发同学修改配置即可。
（二）漏洞复现方式
1、复现SQL注入漏洞
打开扫描的scan文件，选择SQL注入-请求/响应--测试，根据请求信息，进行复现。
分析下这个问题，这个接口主要是将参数sort_fields的值改为date_time%27%3B后，响应信息中出现了数据库的相关信息，说明攻击成功了。（查看数据库相关的报错信息可点击页面的黄颜色ab按钮，一直往下，可查看所有的报错信息）。
这是一个get请求，可以直接在浏览器中进行复现，先登录系统，直接在url中输出如图GET后到HTTP/1.1之前的参数，前面加上http://host或https://host，拼接起来就是http:/host/manage/report/activity-list?pageXXXXXXXXXXXXXXXsort_fields=%7B%22value%22%3A%22date_time%27%3B%22%2C%22soXXXXXXXXXXXXXXXXXX-20%22,%222021-10-19%22]%7D，即可复现。
2、复现跨站点请求伪造csrf漏洞
在实际的项目中，只要测试报告中有csri的漏洞问题，就可以人工去查看post或get接口的请求头,是否包含token和referer。
如果没有包含，就去尝试复现，理论上，使用post请求去复现，但是目前团队由于无法解决跨域的原因，还没构造出对应的表单，所以复现就直接用get接口了，
利用get请求复现的方法很简单:
①在浏览器中登录系统，找到一个get接口链接A，复制下来。
②再去百度，随便搜索一个博客链接B，找到元素的链接B后，右键编辑，直接将B替换为所测。
③点击博客上刚刚替换链接对应的文字，如果跳转的页面返回了接口A的信息，则证明攻击成功，存在跨站点请求csr的问题，如果不是，则会返回无权限或接口的其他状态码等等。
3、复现跨站点脚本攻击xss漏洞
复现步骤与SQL漏洞复现的步骤几乎一致。
①打开扫描的scan文件，选择跨站点脚本编制--请求响应--测试，根据请求信息，进行复现。
分析下这个问题，这个接口主要是将参数skuName的值改为%3C%2Fscript+%3E%3Cscript%3Ealert%28124%29%3C%2Fscript%3E（decode解码后是:</script+><script>alent(124)</script>）后，响应信息中出现了js脚本信息，说明攻击成功了，（查看数据库相关的报错信息可点击页面的黄颜色ab按钮，一直往下，可查看所有的报错信息）
补充：
①复现反射型XSS漏洞的方式，在get接口请求参数中加入</script><script>alert(123456)</script>即可，看页面是否会输出123456，输出了，则证明执行了脚本文件，存在XSS漏洞。
②复现DOM基于文档对象模型漏洞的方式，直接在前端找到元素，修改为</script+><script>alert(124)</script>之后，如果弹出执行窗口，就证明存在漏洞。
四、总结测试结果形成报告
（一）发送测试报告
以邮件的形式发送测试报告，测试报告主要包含两份附件：导出的安全测试报告和手写的测试报告。
这两份报告的区别：从生成的scan测试文件直接导出来的报告，会显示所有的问题，高中低都会显示，且有些问题是无法复现的。
而自己手写的测试报告，包含了开发负责人，测试负责人，以及需要修复的漏洞，对比导出的报告，做出了筛选，只列出了需要修复的漏洞，以及对应的接口地址，修复情况等等。
测试邮件则包含：
1、项目名称
2、网址
3、开发负责人
4、测试负责人
5、测试概述（即介绍安全测试的意义）
7、测试工具
8、风险等级（包含的漏洞风险等级，以及问题总数）
9、风险类型（SQL注入，跨站点请求伪造等等）
10、测试日期
11、安全审计员
具体报告的呈现形式取决于项目组，如果大家对模板感兴趣，可以私我领取。
（二）开发修复漏洞
待开发同学修复漏洞之后，需要重新验证，验证方法与重现方法一样，可参考重现方法。
验证完后可在之前的scan文件上，用工具验证一轮。
（三）回归验证结果
待所有的问题修复完后，回复一个验证报告。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
