业务逻辑漏洞分类

业务办理模块

订单ID篡改测试

测试方法：对于一些购买东西的功能，当到订单详情页时，可以刷新页面拦截包，发送到 Repeater，修改其中的 id 订单号，看是否会返回对应的订单信息，如正常返回则存在此问题。

修复方法：在后台查看订单时要通过 Session 机制去判断用户身份，服务端要去校验相应订单和登录者的身份是否一致，如果不一致则应该拒绝请求，防止出现水平越权泄露个人隐私信息。

手机号码篡改测试

测试方法：对于一些登录后才可以使用的功能，发送请求时，可以拦截包观察其参数，如果其中包含手机号，可以尝试替换成另一个号码，查看返回结果是否有变化，如果有变化则存在此问题。

修复方法：后台要通过 Session 的机制来判断用户身份，如果其中有手机号参数时，应该在服务器端判断用户的身份信息和手机号是否一致，从而防止水平越权的问题发生。

用户ID篡改测试

测试方法：很多业务请求中都会有 UserID 参数，而后台判断其身份时也会根据这个参数来做判断，如果碰到类似参数，可尝试修改其值为另一个账号，如果系统返回了相应的信息，则存在此问题。

修复方法：后台要通过 Session 的机制来判断用户的身份，当程序逻辑需要用到 ID 号时，要在服务器判断传过来的 ID 是否和当前用户的 ID 一致，防止其产生越权问题。

邮箱和用户篡改测试

测试方法：例如有一个发邮件功能，当写好邮件内容，填好收件人后，发送时拦包修改其发件人的邮箱地址，可以成功发送。然后收件人收到的邮件也会成功显示刚才修改发件人的名，则就存在此问题。

修复方法：后台通过 Session 判断用户的身份，如果在传输的过程中需要用到类似上例中的邮箱参数，则需要在服务器端判断传过来的邮箱和当前登录的用户是否一致，避免问题的发生。

商品编号篡改测试

测试方法：在一些商城中，购买商品时在生成订单页时或者是支付时，抓包可以修改其支付的金额，或者是修改其商品的 id，实现低价买高价商品，1 分钱买商品等情况，则确定存在此问题。

修复建议：对于商品的金额，不建议从客户端传入，防止被篡改。如果必须从客户端传入，则应在服务端接收后检查商品价格和交易金额是否一致。也可以对支付的金额做一个签名校验，不一致时则组织该交易。

竞争条件测试

测试方法：拦截请求，发送到 Intruder，把线程设置多点，比如所 100，然后开始跑，随后对比数据，看是否有异常。

修复方法：在处理订单、支付等业务时，使用悲观锁或乐观锁保证事务的 ACID 特性（原子性、一致性、隔离性、持久性），并避免数据脏读（一个事务读取了另一个事务未提交的数据）。

输入/输出模块

Sql注入

测试方法：如果是登录前的连接可以直接用 sqlmap -u 去跑，如果是登录后才能访问的连接，用 burp 拦截包，复制到 sqlmap 目录下随便一个 txt 文件，直接用 sqlmap -r 去跑。也可以直接使用 burp 的插件 sqlipy 直接去跑，更方便

修复方法：过滤参数中的特殊字符，或对字符进行转义。现在基本上项目都用框架来写，需要参数化。框架机制虽越来越完善，但不能排除此问题，没以前多了，但依然不少。

XSS

测试方法：反射类型一般搜索功能出现的比较多，存储型的一般新增内容编辑内容中出现的比较多，测试的时候输入一小段 js 代码来验证是否会执行，以确定是否存在此问题。

修复方法：过滤特殊符号，实体化特殊符号，过滤 js 关键字。另外建议对敏感信息设置 httponly 属性，防止 xss 攻击窃取 cookie 内容，反射类型时，尽量不要把信息回显到页面。

命令执行

测试方法：如果有类似接收命令到服务端执行的功能，则可以测试此问题，例如 url 中的某个参数接收命令，可以直接输入命令，看服务器是否有返回信息，或将执行结果重定向到一个文件中，查看此文件。

修复方法：过滤特殊符号，避免造成命令连接。对于可接收的命令，罗列白名单。

验证码机制

验证码暴力破解测试

测试方法：只要是有接收验证码的功能都可以测试，发送到任意一个手机号，随便输入验证码，拦截包发送到 intrude，只给验证码加 $，直接使用 burte forcer 把爆破字符设置成 0-9，爆破后根据长度排序即可。

修复方法：设置验证码的失效时间，建议为 180 秒。同时限制单位时间内验证码失败的尝试次数，例如 5 分钟内连续失败 5 次即锁定账号半小时。

验证码重复使用测试

测试方法：一个提交请求带验证码的功能，输入正确验证码后拦截请求到 repeater，不修改验证码，修改其他参数信息，看是否可以重复提交，如果重复提交成功，则存在此问题。发生此问题的原因是验证码认证成功后没有将 session 及时清空，这会导致验证码首次认证成功后可重复使用。

修复方法：建议验证码认证成功后，服务端清空认证成功的 session，防止有效验证码重复使用。

验证码客户端回显测试

测试方法：例如找回密码功能，输入手机号和相关信息后，服务器给手机号发送短信，这时候可以通过 f12 查看 response 返回的信息中是否包含验证码，如果包含则存在此问题。造成此问题的原因是验证码在客户端生成的而非服务端。

修复方法：建议就是不要在客户端生成，要在服务端生成。同时设置其时效性，例如 180 秒，随机生成且一次有效。

验证码绕过测试

测试方法：例如一个注册功能，输入一个牛点的手机号，随便输入一个验证码，发送给服务器，然后拦截服务器返回的信息，在 forward 前右键选择 Do intercept 下的 Response to this request，然后再放行，这时服务器会返回响应信息，一般会有状态码，例如 0 代表成功，1 代表失败，把返回的结果码改成 0，再放行，成功注册则存在此问题。

修复方法：建议在服务端进行验证码校验时，对客户端提交的验证码进行二次校验。

验证码识别测试

测试方法：直接拿工具识别就行，可以用 pkav http fuzzer，这个一般个人感觉没有测试的必要，在测试的过程中，可以让其加固的时候设置下登录失败的次数等策略，验证码可以不加。

修复方法：单对验证码可识别的情况，修复时，可以增加背景的干扰，例如背景色、背景字幕等。字符的字体进行扭曲，粘连，也可以使用公式、逻辑验证方法等作为验证码，也可以使用选择联系人头像、购买过的物品为验证码。

业务流程乱序

测试方法：流程乱序测试也就是绕过正常的业务流程测试，例如一个注册功能，第一填写注册的手机号并发送验证码，第二步输入验证码，第三注册成功。乱序测试的话，可以拦截第三步的数据包，将其注册的信息例如手机号，替换成他人的，如果注册成功，则存在乱序的问题。 再例如，一个充值的功能，在拦截包的过程中发现充值成功后会有一个充值成功的连接，例如是 xxx.com/index.php?controller=site&action=payok&out_trade_no=aaaa，其中 aaa 是充值订单号。接下来注册一个新账号进行充值，在支付产生订单时复制其订单号然后取消支付，把订单号贴到充值成功后的连接中充值成功，则存在乱序问题。

修复方法：首先建议对敏感信息进行加密处理，例如身份 id、账号密码、订单号、金额等。其次，建议在服务器端对其信息进行二次校验，避免修改乱序等情况。

业务接口调用

接口调用重放测试

测试方法：接口调用重放测试可以理解成重放测试，接口也就是数据请求，功能很多，例如发布文章，发布评论，下订单，也可以理解成只要请求有新的数据生成，能重复请求并成功，都可以算请求重放，也就是接口重放测试。

修复方法：对生成订单缓解可以使用验证码，防止生成数据的业务被恶意调用。或是每一个请求有唯一的一个 token，请求提交后，token 失效这样。也可以参考微信的做法，在参数中添加 timestamp 和 nonce，并对其进行签名加密。

接口调用遍历测试

测试方法：例如有一个功能，是浏览商品的历史记录。把其用户的浏览历史记录 url 发送到 intruder，遍历其用户的 id，看返回 response 信息中是否有正常返回的，且是其他用户的，则证明存在接口遍历问题。

修复方法：在 session 中存储当前用户的凭证或者 id，只有传入凭证或者 id 参数值与 session 中的一致再返回数据内容。

接口调用参数篡改测试

测试方法：例如在一些短信验证码、邮件验证码等功能业务中，比如修改其他用户密码，发送后，再次点击重新发送，拦截其请求，修改为自己的账号，如果自己收到了验证码，则存在此问题。

修复方法：会话 session 中存储重要的凭证，在忘记密码、重新发送验证码等业务中，从 session 获取用户凭证而不是从客户请求的参数中获取。从客户端处获取手机号、邮箱等账号信息，要与 session 中的凭证进行对比，验证通过后才允许进行业务操作。

接口未授权访问

测试方法：只要是登录后才可以返回相关信息的接口，在未登录状态下也可以返回的，就是未授权访问。在一般的网站测试中，可以 http history 中选择网站的根目录地址，然后右键 spider from here 进行爬去相关的 url，然后在 target 栏下的 site map 中利用 mime type 进行筛选，主要关注一下 json、script、xml 等这些类型，然后把 url 贴到浏览器中看是否能访问来验证。

修复方法：利用 token 校验的方式，在 url 中添加一个 token 参数，只有 token 验证通过才返回接口数据且 token 使用一次后失效。在接口被调用时，后端对会话状态进行验证，如果已经登录，便返回接口数据，如果未登录，则返回自定义的错误信息。

callback自定义测试

测试方法：因为同源策略，很多网站都会使用 JSONP，而 JSONP 一般会使用 callback 回掉函数，如果这个函数没有做相关的措施，可以随意传入 js 代码并执行则存在此问题。

修复方法：首先可以定义下 content-type 为 json 格式，content=application/json。其次建立 callback 函数白名单，如果传入的函数不是白名单内的，则组织并转到异常页。最后可以对 callback 参数进行 html 实体编码来过滤掉一些特殊字符。

webservice测试

业务逻辑漏洞分类

登录认证模块

暴力破解测试

测试方法：例如登录，输入账号密码，burp 拦截包发送到 Intruder，把系统变量的 $ 符 clear 掉，给密码加上 add，加载上密码字典，根据返回的长度或者 response 的信息来判断正确密码。

修复方法：一、增加验证码，登录失败的时候，变换验证码。（登录失败，验证码不变不算。验证码工具可识别不算。）二、限制登录频率，例如，5 分钟内登录失败次数超过 10 次则锁定账号 1 小时。三、可以添加手机验证码或邮箱验证码，实现双重验证。

本地加密传输测试

测试方法：输入账号密码登录，拦包，查看包信息，如果账号密码明文传输则存在此问题。

修复方法：服务器使用 SSL 证书服务。

Session会话固定测试

测试方法：登录账号成功后记录下 SessionID 的值，然后退出系统，再次登录，如果第二次的 SessionID 值和第一次的相同，则存在此问题。

修复方法：用户退出系统时销毁其 SessionID，客户端登录时重新生成 SessionID。

Sessin会话注销测试

测试方法：用账号密码登录系统，记录其 SessionID 的值，随便拦截一个登录后才可以发送成功的请求，发送到 repeater，然后退出系统，在 repeater 栏 go 一下，如果服务器正常返回信息则存在此问题。

修复方法：用户退出系统后，服务器及时销毁 Session 认证会话，并清空浏览器的 Session 属性标识。

Session会话超时测试

测试方法：用账号密码登录系统，随便拦截一个登陆后才可以发送成功的请求，发送到 repeater，这时候不要和服务器有任何交互，停一段时间，再回来 go 一下，如果服务器正常返回相关信息，则存在此问题。

修复方法：系统要配置会话的生命周期，建议时间是 30 分钟，一般的业务系统 30 分钟即可，以此来降低会话认证时间过长而导致的信息泄露风险。

Cookie仿冒测试

测试方法：使用一个账号登录，找一个可以证明身份的页面，例如首页的欢迎 xxx 或者是个人中心显示昵称的地方，刷新该页面拦截请求，观察 Cookie 中的字段和值，例如 userid=xxx，把 xxx 改成 admin，forword 放行，页面显示 admin 的信息，则存在此问题。

修复方法：对于客户端标识的用户信息，使用 Session 会话认证方式，避免通过 Cookie 去仿冒其他人的身份。

密文对比认证测试

一般情况下网站输入用户名和密码后，传到后台会对其进行加密，随后和数据库里面的值做对比，以此来判断用户名和密码是否正确。但有些网站不是这么做的，他们会在前端做好加密，然后传到后台直接和数据库里面的值做对比，这时候问题就出现了，截包你可以知道它的加密方式，依然可以去做暴力破解。测试方法：用账号密码登录，拦截请求，查看传输信息，是不是通过一些加密方式对账号和密码进行了加密，如果有则存在此问题。

修复方法：把这个加密对比的方法放到后台去执行。

登录失败信息测试

测试方法：不填账号和密码直接点登录，填入账号不填密码点登录，填入密码不填账号点登录，填入错误的账号不填密码点登录，填入错误的密码不填账号点登录，填入错误的账号和密码点登录，根据提示来判断，如果单提示账号错误，或者单提示密码错误，则存在此问题。

修复方法：使用模糊的提示方法，例如账号或密码错误。

业务授权访问模块

未授权访问

测试方法：访问一个地址，且这个地址是需要认证身份后才可以访问的，随后把这个地址复制到其他浏览器，若能成功访问，则存在此问题。

修复方法：对于未授权访问的页面做 session 认证，并对每一个 url 做身份鉴别，正确校验用户 id 和 token。

越权测试

水平越权

测试方法：在测水平越权时，通常会拦截一些包然后查看能证明身份的东西，例如 id 为 1，这时候改为 2 就会返回 2 的内容，则可以证明存在水平越权。

修复方法：服务端校验身份唯一性。

垂直越权

测试方法：在测试垂直越权时，通常是普通用户登录后，查看一些功能时把能证明身份的东西进行修改，例如 user 为 test，这时候改为 admin，如果成功返回管理员的相关信息，则存在垂直越权。

回退模块

测试过程：回退测试字面理解就是退一步的意思。例如一些修改密码的操作或者是付款成功后等业务模块，操作完成后返回上一步，如果可以正常的再次操作，则存在此问题。

修复方法：对于存在此问题的业务，且是多步骤操作的，建议判断其请求是否是上一个步骤所发起的，如果不是则返回错误提示或页面失效。单步骤建议也判断其请求是否是从规定的 url 连接上发起的。

业务数据安全

商品支付金额篡改测试

测试方法：在一些电商系统或是支付购买商品功能处，生成订单后去支付时，拦截其请求，看支付金额是否可以修改，修改后提交至服务区器，如果成功返回，且存在此问题。

修复方法：对于一些支付类的信息，不能在前端控制，其校验信息应该由后端来完成。

商品订单数据篡改测试

测试方法：这个和商品支付金额负数，提交后弱服务器成功返回，则存在此问题。

修复方法：后端应该对其风险进行控制，对异常的交易行为进行限制和阻断，其异常行为例如积分为负、交易商品数量为负、交易商品数量和金额不符，商品数量为 0 等。

前端JS绕过测试

测试方法：例如一个促销活动购买商品的功能，其商品有购买数量限制，比如没人限购 1 份，这时输入 1 发送请求，拦截数据包修改其值，修改为多份时，如果成功提交，则存在此问题。

修复方法：对于类似的功能，其关键的数据信息校验应该由服务端完成，而不能只以前端来做判断。例如，商品的金额，商品的折扣，商品的数量和限购等。

请求重放测试

测试方法：例如一些商品订购功能，生成订单时抓取其请求，然后发送到 repeater，不断的 go，如果一个请求可以多次成功，生成多个订单，则存在此问题。其危害在于一次购买多次收货。

修复方法：可以添加随机的 token 作为验证，一次请求后即失效。在服务器端生成订单的时候，要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。

业务上限测试

测试方法：说是业务上限测试，也可使说是对前几条的总结或结合，例如一个查询订单功能，只能查最近 6 个月的订单，请求后抓包，修改其值为 12 则可以查看一年的订单，则存在此问题。

修复方法：修复方法：可以添加随机的 token 作为验证，一次请求后即失效。在服务器端生成订单的时候，要对订单 token 对应的订购信息内容、用户身份、用户积分等一些信息进行强制校验。

密码找回模块

测试方法：在很多的修改密码功能中，第一步都会要求用户输入手机号或者邮箱来验证用户的身份，那么验证码就可能会出现在响应包中，有些程序会将验证码放在响应包中。拦截发送验证码的的请求，查看其 response 的信息，是否包含其验证码，包含验证成功，则存在此问题。

修复方法：避免将验证码回显在响应包中，验证的比对应放在服务端进行。

测试方法：一般情况下，只有用户自己通过手机或邮箱来收取验证码，但当服务器没有对错误的次数做限制时，则可导致暴力破解。首先应该知道验证码的规律，例如是 4 位数字，或 6 位数字，然后手机发送验证码后，任意输入一个符合规则的验证码，拦截包发送到 intruder，对验证码添加标记进行枚举测试，跑出结果后根据 length 长度来找出正确验证码。

修复方法：建议对错误的次数做限制，避免被爆破，同时设置验证码的有效期，然后再加大其复杂度。

接口参数账号修改测试

测试方法：这个也可以分为多种情况，例如修改密码时，需要发送用户凭证，拦截数据包，将凭证的地址（手机号或者是邮箱等）改为自己的，如果自己可以收到，则存在此问题。再例如，直接修改自己的，拦截数据包，将其中修改的账号换成他人的，如果成功修改，则也存在此问题。

修复方法：建议对修改连接增加 token 来做验证，一个 token 只能修改一次且 token 只能使用 1 次。

response状态值修改测试

测试方法：例如一个修改密码功能，第一步需要输入手机号和接收到的验证码，通过后才可以进行第二步的修改。通常如果第一步验证成功，一般服务器都会返回类似 ok、1、success、true 这种的状态值。那么在拦截数据包后可以右键选择 do intercept->reponse to this request，这样下一步就会显示服务器的返回包，修改其状态值，然后直接 intercept is on 关闭拦截数据包，如果跳转到修改密码页，则存在此问题。

修复方法：前端不要利用服务器的返回值来判断是否修改密码，在整个校验的流程中，都应该在服务器进行。

session覆盖测试

session 覆盖测试第一步：输入自己的手机号和自己的短信验证码跳到密码重置页，打开一个新的标签页，粘贴密码重置页的 url，放在这里做备用。第二步：回到刚才输入自己手机号的那个页面回退一步，此时输入目标用户的手机号，然后发送验证码。第三步：目标用户不知道有没有收到验证码，但此时的 session 已经有自己的换成了目标用户的。第四步：打开刚才备用的那个重置密码页，刷新一下，如果有显示修改的账号手机号，则此时应该会变成目标的手机号。重置后可以成功修改目标用户的密码。则存在此问题。

修复方法：在重置密码的请求中，一定要对修改的账号和凭证是否一致做进一步的校验。

弱token设计缺陷测试

测试方法：很多密码找回功能都会将重置密码链接发送到邮箱，可以发送多次，然后观察其 url 的规律，很多网站的重置密码链接的 token 并不安全，例如使用时间戳作为 token，或者是 id 经过 md5 作为 token，或者是 base64 编码后作为 token，观察规律后就可以伪造 url 进行目标用户的重置，如果中间加油随机数，则可以暴力破解下。

修复方法：建议设置 token 的复杂度，不要有规律可循，如果加随机验证码，建议位数多点。同时 token 设置失效时间，避免恶意攻击者有足够的时间进行爆破。

密码找回流程绕过测试

测试方法：当找回密码分为多步时，例如一步输入账号页，第二步验证身份页，第三步修改密码页。可以先用自己的账号走一遍流程，把每一步的流程都拦截数据包，依次记录下整个过程中所有的 url，然后直接访问第三步的 url 页面地址，如果可以成功打开并修改，则存在密码找回绕过问题。

修复方法：建议在后台要验证上一步的操作是否已经完成，避免被绕过。