WEB安全测试要点总结

常见的测试点如下：

1、用户隐私协议

• 用户注册时需要明确告知用户会获取到哪些用户信息，包括cookie、手机号、邮箱等等，并且不会泄漏给第三方（可参考JD、taobao等）

2、注册功能

• 注册功能是否能正常实现；
• 注册请求是否安全传输；
• 验证必填项为空是否允许注册；
• 密码二次确认时，此时复制粘贴不可生效，其余的情况应该生效；
• 注册时，设置密码为特殊版本号，检查登录时是否会报错；
• 注册时对密码的复杂度是否进行校验（管理员密码策略有12位，要求含有大小写、数字、特殊字符；普通用户密码策略有6位，含有大小写、数字）

3、登录功能

• 登录失败时，是否给出合理的提示（用户名或密码错误）；
• 是否支持登陆失败次数的限制（如密码输入5次，锁定账号30分钟等），是否可被暴力破解；
• 登录时，当页面刷新或重新输入数据时，验证码是否更新；
• 关键cookie是否httponly；
• 是否明文传输用户凭据；
• 是否可以直接修改服务器返回的数据包（如将false改为true，-1改为1等），从而直接登录账户；
• 是否本地存储用户敏感信息（如cookie中存储用户密码等）
• 会话固定：Session fixation attack(会话固定攻击)是利用服务器的session不变机制，借他人之手用相同的会话ID获取认证和授权，然后利用该会话ID劫持他人的会话以成功冒充他人，造成会话固定攻击。

4、验证码功能

• 短信验证码轰炸；
• 验证码一次性有效；
• 验证码是否在返回的数据包中显示
• 验证码是否经过前后端校验，是否可以通过抓包修改验证码；

5、忘记密码

• 通过手机号/邮箱找回，要经过二次验证（可以同时使用密保问题、手机号验证码、身份证号、购买记录等任意两种鉴权方式组合验证）
• 密码找回链接是否在客户端回显，是否可直接点击该链接绕过验证码；
• 复制粘贴操作（如密码需二次确认验证，此时复制粘贴不可生效，其余的情况应该生效）；
• 程序设计不合理，导致可以绕过短信验证码，从而进行修改(使用burpsuite抓包，修改响应值true)

6、密码安全性要求

• 密码复杂度要求（管理员密码策略有12位，要求含有大小写、数字、特殊字符；普通用户密码策略有6位，含有大小写、数字）；
• 用户密码保存要求；检查数据库中存储的用户信息是否进行加密，禁止明文存储用户信息；

7、安全配置管理

• Config中的链接字符串以及用户信息，邮件，数据存储信息都需要加以保护；
• 配置所有的安全机制，关掉所有不使用的服务，设置角色权限帐号，使用日志和警报

8、错误信息

• 访问一些不存在的页面，错误信息中是否含有SQL语句，错误信息，源代码以及web服务器的绝对路径；

9、session

• 登录后长时间不操作，session超时，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用；
• session是否失效，将需要测试的页面Page1在另一个标签中打开，然后再在原来的页面中退出登录，此时session已经失效；这样再去操作Page1，查看session是否失效；
• 账户登录前后session需不一致；
• 会话固定：利用session的不变机制，获取他人认证和授权，然后冒充

10、后退按钮、返回键

• 对于页面的操作，要注意测试下浏览器上的后退按钮操作，查看下做完操作后点击后退按钮后，之前的操作是否会撤销？
• 连续点击后退按钮，查看页面会做何种处理，是否会报错；
• 比如已经退出登录的页面，点击后退按钮，页面是否仍是登录状态？
• 对于有返回键的页面，对于已经成功提交的记录，点击返回键后，看如何处理之前的操作；

11、目录遍历

• 访问网站页面，是否显示目录文件列表（服务器文件列表）；

12、越权测试

• 不登陆系统，直接输入下载文件的URL是否可以下载/直接输入登录后页面的URL是否可以访问
• 手动更改URL中的参数值能否访问没有权限访问的页面
• 不同用户之间session共享，可以非法操做对方的数据

    一个web系统，一般地址栏都会有参数的带入，如：用户号，订单号或者是其他的一些参数，而在这个基础上一个系统都会有很多用户，如：A、B用户，如果我使用B用户进行登录，查看B用户所属的订单，在地址栏中会有订单号的参数带入，如果系统没有进行相应的限制，此时B用户就可以修改订单号从而可以看到A用户的数据，这就可能导致数据的泄露，进行越权。

13、上传功能

• 上传中断，程序是否有判断上传是否成功；
• 上传与服务器端语言(jsp/asp/php)一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行；
• 上传文件的类型、大小对否做了限制，测试是否可以绕过限制；

14、SQL注入

• 输入恶意的SQL注入语句，后台处理程序没有对这些参数进行过滤，且所使用的数据库查询手段为拼接方式，进而导致敏感数据外泄。
• 输入框、参数处是否对用户输入的内容进行处理是否转义或编码，是否可以被绕过；
• 结合自动化的扫描工具进行网站扫描，如AWVS，可以扫描出网站是否存在SQL注入、XSS攻击等漏洞；

15、XSS

• 输入框、参数处是否对用户输入的内容进行处理是否转义或编码，是否可以被绕过；
• 结合自动化的扫描工具进行网站扫描，如AWVS，可以扫描出网站是否存在SQL注入、XSS攻击等漏洞；

16、日志文件

• 验证服务器日志工作是否正常；
• 日志记录和业务数据，是否采取了相应的隔离措施和安全保护措施。
• 日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?是否是可追踪的？

17、存储安全

• 检查数据库中存储的用户信息是否进行加密，禁止明文存储用户信息；

18、未授权访问

• 检测网站是否可以对开放的某些服务进行未授权访问，匿名登录等（如redis未授权访问、rsync未授权访问等）；

19、拒绝服务攻击

• 拒绝服务攻击是攻击者可以从一个主机产生足够多的流量来耗尽很多应用程序，最终使程序陷入瘫痪，需要做负载均衡来对付；
• 检测网站是否有慢速的http拒绝服务攻击等漏洞；

20、SSL服务测试

• 可以使用如下网站测试：https://www.ssllabs.com/ssltest/index.html
• 应确保敏感信息通信信道的安全，建议在客户端与web服务器之间使用SSL。并正确配置SSL，建议使用SSL3.0/TLS1.0以上版本。

21、支付漏洞测试

• 支付功能是否完善；
• 抓包是否可以修改订单价格和数量，重放数据包等；

 通常的支付流程：选择商品和数量——选择支付及配送方式——生成订单——订单支付——完成支付，

 如测试是否可以修改订单的数量：登录网站，选择购买一个商品病抓取数据包——找到其中代表商品数量的参数，将参数的值改为负数——发送数据包，生成订单，观察订单是否有效，是否能进入支付页面——完成支付

 修复方式：在请求数据中对涉及金额、数量等敏感信息进行加密，保证加密算法不可猜解。并在服务器端进行校验；

                   支付交易请求数据中加入token，防止重放攻击；

推荐一篇觉得写得不错的关于支付漏洞的文章https://www.secpulse.com/archives/67080.html