测试角度对于开发的一些看法

• 暴力破解测试

就是指对应用系统用户登录账号与密码进行的穷举测试，针对账号和密码进行逐一比较，直到找到正确账号与密码。

一般是三种情况：

已知账号，加载密码字典对密码进行穷举测试；

未知账号，加载账号字典，结合密码字典进行穷举测试；

未知账号与密码，利用账号与密码进行穷举测试；

   使用BurpSuite工具进行破解。

   修复建议：增加验证码，登陆失败一次则验证码重新变换一次；

             配置登录失败次数限制策略，同一用户连续输错密码几次则在一定时间内限制其登录；

             增加短信验证码与邮箱验证码双重验证。

• 本地加密传输测试

就是针对客户端与服务器的数据传输，查看数据是否采用SSL安全套接字加密方式加密。

使用Fiddle或Wireshark抓包工具进行登录页面用户名与密码的数据抓取，未采用SSL协议且对登录信息未进行算法加密的可直接拿到明文数据。

修复建议：在Web应用的服务器上部署有效的SSL证书服务。三.Session会话固定测试

Session是针对应用系统对浏览器客户端身份认证的属性标识，在用户退出应用系统时，应将客户端session认证属性标识清空。如果未能清空客户端Session标识，在下次登录系统时，系统会重复利用该Session标识进行认证会话，攻击者可利用该漏洞生成固定Seesion会话，诱骗用户利用攻击者生成的固定会话进行系统登录，导致用户会话认证被窃取。

同样利用Burpsuite在用户登陆后退出时截取SessionID，再次进行登录查看SessionID，若两次相同则存在固定会话风险。

修复建议：客户端登录系统时，首先判断客户端是否提交浏览器的留存session认证会话标识，客户端提交此信息到服务器时，应及时销毁浏览器留存的session。

四.密文比对认证测试

系统登录时加密流程是密码与用户名发送到服务器，服务器对密码哈希加密后与数据库中存储的加密值比对，相同则正确。但有些网站是在浏览器客户端对密码进行哈希加密后传到服务器进行对比，这种流程会泄露加密方式，导致出现隐患。

建议：将密码加密过程与密文比对过程放到服务器进行。

• 登陆失败信息测试

登录页面登录失败时会提示账号不存在，账号错误，密码错误这些间接的提示信息，攻击者可借此判断账号是否存在该系统。

建议：对登陆失败的提示信息统一模糊描述，只提示账号或密码错误，或登录失败等。

• 验证码暴力破解测试

短信验证码大部分情况由4到6位数字组成，如果没有对验证码的失效时间和失败次数做限制，攻击者可以尝试这个区间内的所有数字来进行暴力破解攻击。

1. 获取验证码；2.抓取数据包，对code参数进行暴力破解。

建议：设置验证码失效时间建议180秒；限制失败尝试次数，五分钟连续失败5次锁定账号15分钟。

• 验证码客户端回显

攻击者进入找回密码页面，输入手机号与证件号，获取验证码，服务器向手机发送验证码时通过浏览器工具查看返回信息包里有验证码信息。

建议：禁止验证码在本地客户端生成，采用服务器验证码生成机制；设置验证码时效性，如180秒过期；验证码应随机生成，使用一次就失效。

• 验证码自动识别

  图形验证码使用较广泛，它的识别流程是：

   图像二值化处理>去干扰>字符分割>字符识别

一般为了防止验证码被自动识别，通常加入一些点，线，色彩之类进行干扰。

流程：通过刷新验证码页面查看验证码组成规律，进行图像二值化，去干扰处理，并进行人工比对，存储成功识别的验证码包，截入工具进行暴力破解。（PKAV HTTP Fuzzer工具）

建议：增加背景元素的干扰，如背景色，背景字母等；字符的字体进行扭曲，粘连；使用公式，逻辑验证方法等作为验证码，如四则运算法，问答题等；另图形验证码与使用者有关，比如选择联系人头像，选择购买过的物品作为验证码。

• 密码找回时短信验证码返回给客户端

 忘记密码操作时使用一个已注册手机号通过短信验证码找回密码，输入图片验证码后单击获取短信验证码，这时抓取数据包发现服务端直接将短信验证码返回给了客户端，直接填写短信验证码即可重置密码。

• 密码重置凭证与用户账户关联不严

  有些系统在密码找回时只校验了密码重置凭证是否在数据库存在，没有严格校验该重置凭证和用户账号之间的绑定关系，有可能我们进行手机号密码找回时收到验证码后输入验证码与新密码提交，这是用抓包工具抓取数据包将username改为其他账号进行post后可以直接登录其他账号。

• 密码找回流程绕过测试

密码找回时有三个步骤：1是用户输入找回密码的账号，2是校验凭证，用户收到的短信验证码或找回密码的链接，用户填写验证码或链接证明操作用户是账号主人，3是校验成功后进入重置密码页面。

第二步最重要，我们收集这三个步骤的请求接口，尝试直接跳过凭证验证的接口去第三步重置密码的接口，有可能会直接跳过验证身份环节。    建议：防止跳过验证步骤一定要在后端逻辑校验中确认上一步流程已经完成。

• Session覆盖测试 短信验证码未与手机号绑定

一般来说短信验证码仅能使用一次，验证码和手机号未绑定，验证码一段时期内有效，那么可能会发生：A手机的验证码，B可以拿来用；A手机在一定时间间隔内接到两个验证码，都可以用。检测接受验证码的手机号与绑定的手机号是否一致，有任意用户密码重置的案例，先使用自己手机号A接收验证码，同时在一个客户端用另一个B手机号接收验证码，把A收到的验证码输入到B的验证码框，下一步发现验证通过可以设置新密码。 建议：在服务器进行有效验证，在重置密码请求中一定要对修改的账号和凭证是否一致做进一步的校验。

• 用户ID篡改测试

从开发的角度，用户登录后查看个人信息时，需要通过sessionid判定用户身份，显示相对应个人信息，但有时我们发现在GET或POST请求中有userid这类的参数传输，并且后台通过此参数显示对应的用户隐私信息，这有可能导致攻击者可以通过篡改用户ID越权访问其他用户隐私信息。建议：后台功能请求要通过session机制判断用户身份，不要相信客户端传来的用户id，如果确实需要客户端传输userid，则服务端需要校验userid是否和登录者的session身份一致，如果发现不一致则拒绝请求，防止被攻击者篡改，未授权访问他人账号内容。

竞争条件测试

就是当两个或多个进程试图同一时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序。那么在服务端逻辑与数据库读写间存在时序问题时，就有可能存在竞争条件漏洞，攻击者可利用多线程并发请求，在数据库余额字段更新前，多次购买商品。例子是攻击者在提交订单时抓包，然后设置多个线程重放此包，在众多请求中，个别请求就可能争取绕过金额，次数判断交易成功。  建议：在处理订单，支付等关键业务时，使用悲观锁或乐观锁保证事务的ACID特性，并避免数据脏读，解决竞争条件和并发操作可能的问题。

防范账号泄露的措施

1. 核查数据库中的账号与密码存储方式，自行加密用户敏感数据，严格限制数据库的访问条件，禁止外部连接数据库。2.采用HTTPS协议对账户认证过程实现加密封装，确保身份认证过程无法被窃取。
2. 加强网络信息安全意识，网络管理人员对内部员工进行安全意识培训，禁止使用弱口令，禁止公开个人账号密码，定期修改密码。4.使用数字证书认证，数字证书是通过运用对称和非对称密码体制等密码技术建立起一个严密的身份认证系统，从而保证信息除发送方和接收方外不被其他人窃取。5.了解互联网账号泄露事件，存在账号泄露事件时第一时间通知客户修改个人账号和密码，避免撞库攻击。

                    部份业务数据安全测试

• 商品支付金额篡改测试

电商类网站在业务流程整个环节需要对业务数据的完整性和一致性进行保护，特别确保在用户客户端与服务，业务系统接口之间的数据传输的一致性，在订购交易流程中容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交业务数据而导致的商品金额篡改漏洞。

在支付过程中抓包篡改金额数据进行支付。

建议：商品信息的金额，折扣等数据的校验应来自服务器端，不应接受客户端传递过来的值。

• &商品订购数量篡改测试

在业务流程中抓包修改商品数量等字段，如将请求中的商品数量修改成任意非预期数额，负数等后进行提交，查看业务系统能否以修改后的数量完成业务流程。

三．请求重放测试

用户每次订单Token不应该能重复提交，避免产生重放订购请求的情况，在服务器订单生成的关键环节应对订单的Token对应的订购信息内容，用户身份，用户积分等进行强校验。

四．业务上限测试

   主要是针对一些电商类应用程序在进行业务办理流程中，服务端没有对用户提交的查询范围，订单数量，金额等数据进行严格校验而引发的一些业务逻辑漏洞，一般在业务流程中通过向服务端提交高于或低于预期数据以校验服务端是否对所提交的数据做预期强校验。

   建议：在服务器端应该对订单的Token对应 的订购信息内容，用户身份，用户可用积分等进行强检验。服务端应考虑交易风险控制，对产生异常情况的交易行为应当直接予以限制，阻断。

• 防范密码找回漏洞的相关手段

   在密码找回功能设计时对用户凭证的验证次数和频率进行限制，防止攻击者对用户凭证的暴力枚举攻击；对密码找回的各个环节进行梳理，记录分析所有交互数据，避免密码找回凭证等敏感信息直接返回客户端；对服务端密码重置Token的生成算法进行审计，避免使用容易被攻击者破解的简单算法；密码重置凭证应与账户严格绑定，并设置有效时间，避免攻击者通过修改账户ID的方式重置他人密码；对客户端传入的数据要进行严格的校验，手机号，邮箱地址等重要信息应和后台数据库中已存储的信息进行核对，不应从客户端传入的参数中直接取用，避免攻击者通过篡改传入数据的方式重置他人密码；对用户注册，手机邮箱绑定等业务逻辑进行审计，避免攻击者通过用户重复注册和越权绑定等漏洞间接重置他人密码。

• 防范越权访问漏洞的相关手段

   平行越权：攻击者请求操作（增删改查）某条数据时，Web应用程序没有判断该数据的所属人，或者在判断数据所属人时直接从用户提交的表单参数中获取（如用户ID），导致攻击者可以自行修改参数，操作不属于自己的数据。

纵向越权：服务器为鉴定客户端浏览器会话及身份信息，会将用户身份信息存储在cookie中，并发送到客户端存储。攻击者通过尝试修改Cookie中的身份标识为管理员，欺骗服务器分配管理员权限，，达到垂直越权目的。

对于开发者而言，一定要有安全意识，时刻警惕。

永远不要相信来自客户端的输入，对于可控参数进行严格的检查与过滤；执行关键操作前必须验证用户身份，多阶段功能的每一步都要验证用户身份；对于直接对象引用，加密资源ID，以防攻击者对ID进行枚举；在前端实现的验证并不可靠，前端可以验证用户的输入是否合规，要在服务端对请求的数据和当前用户身份做校验。检查提交CRUD请求的操作者与目标对象的权限所有者是否一致，如果不一致则阻断；在调用功能之前，验证当前用户身份是否有权限调用相关功能（推荐使用过滤器，进行统一权限验证）；把属主，权限，对象，操作的场景抽象成一个统一的框架，在框架内统一实现权限的管理和检查。

防范在线支付漏洞的相关手段

针对订单金额篡改的预防措施：将订单中的商品价格封装为码表形式，即每个商品拥有一个ID，每个ID对应一个相应的价格。用户访问前台选择商品并提交，服务器端验证商品ID，然后计算商品总额并生成订单。

针对订单数量篡改的预防措施：在服务器端判断提交商品ID中数量参数值不低于0，如果低于0，则直接提示错误信息，让客户修正。   通过数据类型判断正确后，同时判断商城库存对应的商品的剩余量，如果剩余量低于商品的购买数量，则直接提示错误信息，让客户修正。

针对订单请求重放测试的预防措施：无论支付成功还是失败，使用的订单编号必须唯一，并且永久记录订单编号，不许二次使用。

针对其他参数（如运费）干扰测试的预防措施：在服务器端判断订单中运费参数值不低于0，如运费参数值低于0，则直接提示错误信息。