一、目的：
梳理web项目安全关注点及测试方法，形成通用安全测试清单。
二、安全检查清单：
1、Web系统
| 类型 | 安全项 | 通过标准 | 备注 |
| 传输协议 | 未使用https引起的信息泄露、运营商劫持等问题 | 1、对外提供服务、面向C端用户的web、H5、接口均应启用https传输； 2、服务器间交互且有身份或白名单等形式校验，对响应时间要求高的可考虑走http |
原则上无条件默认推https，遇到http的需沟通确认 |
| 信息泄露 | 敏感信息未脱敏展示 | 所有涉及用户个人隐私的信息，如姓名、手机号、邮箱、地址、身份证号等均不得在前端页面上 未脱敏 展示 | 一般而言不应由前端做特殊脱敏处理，而应该是服务端下发的数据本身已经过脱敏 |
| 敏感信息明文传输 | 接口请求及响应中的敏感信息，如个人隐私、设备串号等，应做加密处理 | ||
| 敏感信息明文存储 |
|
||
| 响应信息泄露 | 1、接口响应信息中不可明文返回用户敏感信息； 2、接口响应（404、403、500等）不可返回debug调试信息，如代码路径、sql语句、服务器代码信息、数据库连接信息 3、媒体链接和超链接不可用物理路径，采用相对路径的表达方式 |
||
| SQL注入 | SQL注入漏洞 | 1、sqlmap等工具扫描通过； 2、测试手动模拟注入时不生效或接口报错；服务端避免SQL拼接形式，添加参数过滤 |
|
| XSS跨站脚本攻击 | XSS跨站脚本攻击 | 模拟XSS攻击不生效 1、无反射型XSS脚本攻击：系统的URL地址搜索框后面输入以下无弹窗 <οnlοad=alert(document.cookie)>或<script>alert(/xss/)</script>、<img src="javascript:alert('xss')">、 <html>"1234"</html>(是否出错）、<input type="text" name="user"/>（是否出现文本框），<script type="text/javascript">alert("提示")</scripe>（是否出现提示） 大小写转换、引号的使用、[/]代替空格、回车符 2、无存储型XSS脚本攻击：搜索框、输入框、留言、输入以上测试语句 |
|
| CSRF跨站伪造请求攻击 | CSRF跨站伪造请求攻击 | 检查存在CSRF限制措施 添加校验token等 |
|
| 文件上传漏洞 | 文件上传漏洞 | 1、严格限制和校验上传文件类型，限定文件后缀名，禁止直接上传.exe，php、asp、.py等可执行文件； 2、限制相关目录的执行权限 3、文件内容服务端校验，避免本地绕过 4、限制上传文件大小，防止由于内存、磁盘耗尽造成的拒绝服务 |
|
| CSRF跨站伪造请求攻击 | CSRF跨站伪造请求攻击 | 检查存在CSRF限制措施 添加校验token等 |
不方便直接验证 |
| DDoS攻击 | DDoS攻击 | 限制单个用户或IP的访问流量，超限后服务降级或拒绝（拉黑） | 该条视业务需要，非必须，可接入统一网关解决 |
| 业务逻辑 | 越权访问漏洞：水平越权、垂直越权 | 1、无法通过简单修改用户ID等形式越权获取他人数据； 2、无法通过url直接访问无权限页面或者文件下载 3、退出登陆后，点击后退按钮不能访问之前的页面 4、执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限 |
一般会添加登录用户token校验 |
| 业务信息泄露 | 1、注册时不得预校验用户名或手机号是否已注册，应在通过验证码校验后提交时统一校验； 2、登录时不得明确提示用户名不存在/用户名错误/密码错误，改为模糊提示，如“用户名或密码错误”； 3、密码/口令输入框不能明文显示和拷贝 |
还包括敏感信息泄露 | |
| 登录漏洞 | 1、账户锁定：密码有连续错误次数限制，达到次数账号锁定，不可穷举爆破 2、不可使用“cookie/历史访问数据”登录 3、客户端限制同一个账号多机器同时登录，web端根据实际情况是否限制 4、强制用户在首次登陆系统时修改系统为其设置的初始密码 5、用户修改密码必须验证旧密码，同时对新密码进行确认 6、不可设置每个账号的初始密码均相同，可预测 |
||
| 验证码漏洞 | 1、验证码不可重用/被爆破/一直有效 2、验证码不可过于清晰，易被机器识别 3、验证码不可为空，如value传空或字段key不传 4、验证码不可单由前端验证，需服务端校验 5、验证码生成算法的安全随机数（试多次就可观察到规律） 6、验证码不能通过html源代码查看到 7、验证码在登录失败后能够刷新 8、发送短信验证码有次数限制，不可滥用 9、发送短信验证码有超时限制，且是短信验证码一次性 |
||
| 前端限制绕过 | 1、关键业务流参数不可仅由前端限制，服务端处理时需校验，避免接口级的篡改 2、接口传输的用户名和密码不可是明文 3、不要有默认可猜测的用户账号：admin，administrator、root、system 4、对于暴力破解攻击，建议在尝试3次左右失败之后，使用图形验证码。 5、登录认证不能绕过，如输入admin or '1'='1' |
||
| 条件竞争漏洞（并发） | 限制数量或频次的业务在并发请求下不出现超发，超支等问题 | Web应用中常见的漏洞场景有：签到、领优惠券、抽奖、抢购商品等 | |
| 密码复杂度低 | 1、业务层限定密码长度和包含字符类型； 2、密码设置时除前端精准校验外，后端亦要精准校验，确保不符合密码无法被成功设置 |
||
| 参数溢出 | 不可输入超长字符串，导致数据溢出触发应用服务器异常或服务器拒绝服务 | 限制输入参数内容的长度 | |
三、漏洞介绍及测试方法
1、SQL注入
（1）介绍
SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。
（2）测试方法
- 查询页面上针对某查询条件输入'or '1=1，执行查询
- 通过修改接口，进行时间类型盲注，如后台查询功能，抓取查询接口，插入'and(select*from(select+sleep(1))a)='片段
修改sleep时间，若执行后接口会按sleep设置值延迟返回，则证明存在SQL注入问题
（3）修复建议
- 使用参数检查的方式，拦截带有SQL语法的参数传入；
- 使用预编译的处理方式处理拼接了用户参数的SQL语句；
2、XSS攻击
（1）介绍
XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。
（2）测试方法
- 存储型XSS
- 例子：云平台(www.yun.cn)，注册新用户，公司名称处填写 “弹窗<script>alert("test")</script>”，补全信息后提交。进入管理后台查看客户列表，则弹出alert弹窗，说明存在存储型XSS漏洞
- 反射型XSS
- 例子：云广平台(www.yun.cn)->消费明细>平台总收入，执行查询操作，抓取接口请求，参数中插入 <body%20οnlοad=alert(document.cookie)>，可将查询条件改为无匹配，加快速度
Payload:
http://www.yun.cn/houtai_gl/income/totalChart/?startDate=2020-11-2011&endDate=2020-11-2011<body%20οnlοad=alert(document.cookie)>&testNo=all&planType=all&wmNo=all&dateType=8&p=1&export=0&sumType=1
登录后台的情况下，点击上述链接，可看到浏览器中，成功出现弹框，证明js脚本执行成功，证明存在反射型XSS问题。
（3）修复建议
- 对输入字符进行过滤，对数据进行Html Encode处理，过滤或移除特殊的Html标签，禁止将非法字符传到服务端
- 校验参数格式，不允许输入’”<>;等特殊字符
- 限制参数长度
- 将重要的cookie标记为http only
3、CSRF攻击
（1）介绍
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
（2）测试方法
-
检查：
Ø 是否有防御CSRF的随机数。验证码、csrf_token等都是，有则 （通过）
Ø 是否验证referer，有则（通过）
Ø 请求的参数均可推测，无CSRF防御机制（不通过）
（3）修复建议
- 验证码
验证码限制用户必须与应用进行交互，才能完成最终请求。因此在通常情况下，验证码能够很好地遏制CSRF攻击。
但是这种方式易用性方面似乎不是太好，并且对于简单的图形验证码也有很多绕过机制，是防御CSRF的一种辅助手段。
- Referer 验证
当浏览器发送一个HTTP请求时一般都会在Referer中表明发起请求的URL。
通过Referer我们可以通过判断一个请求是否为同域下发起的来防御CSRF，但是Referer可能会包含一些敏感信息甚至在某些情况下能够被伪造。
因此我们无法依赖于Referer来作为防御CSRF的主要手段，但是可以通过Referer来监控CSRF攻击的发生。
- Token验证
在请求原参数不变的条件下，新增了一个随机的、不可预测参数Token是目前最普遍有效的方式。
后端在对数据处理前会首先对Token参数进行验证，只有用户请求中的Token与用户Session（或Cookie）中的Token一致时，才会认为请求是合法的。
由于Token的存在，攻击者就无法构造一个完整的请求实施CSRF攻击，从而保证了网站或系统的安全。
4、验证码类漏洞
（1）介绍
验证码本身是安全验证手段之一，但由于编码逻辑问题会存在验证码重用、易识别、可为空、仅前端校验、可被爆破、短信验证码被滥用等问题。
（2）测试方法
-
重用/可被爆破：
a.如登录场景，用户名/密码/验证码等存在错误，接口响应失败后，查看前端是否主动发起更新验证码请求，若无则可能存在问题；
b.如登录场景，填写正确的信息并提交，直接尝试回放接口请求，此时应由于验证码错误而响应失败。服务端每次生成的验证码仅可校验一次，不论通过与否均更新掉，防止验证码重用问题。
- 易识别：
结合业务安全要求来判断，检查图片验证码是否太清晰、太简单（纯数字、纯字母），容易被机器识别。若安全要求高，则可考虑字体形变、加混淆线、动态变换，甚至是12306那种逻辑验证码。考虑安全性和易用性的平衡，建议验证码策略动态变化，如失败X次后出验证码策略，失败次数增加验证码难度加大，错误次数超限甚至于被封禁IP等。
- 可为空：绕过前端限制，尝试篡改接口请求参数，模拟验证码字段value为空，验证码字段key值缺失等场景，后端应校验不通过；
- 前端校验：确认不存在“服务端将验证码下发，单纯由前端校验用户输入是否匹配，而提交时后端不校验验证码”的奇葩设计；
- 短信滥用：要有手机号格式校验、相同设备发送短信时间间隔限制、设备或用户指定时间段内请求短信次数上限、请求短信过频时的图形验证码策略等。
（3）修复建议
- 避免出现上述问题