业务逻辑测试主要技术手段

本文列举一下业务逻辑测试主要技术手段，参考《Web攻防之业务安全实战指南》一书，主要测试方向如下：

1）登录认证模块测试

2）业务办理模块测试

3）业务授权模块测试

4）输入输出模块测试

5）回退模块测试

6）验证码机制测试

7）业务数据安全测试

8）密码找回模块测试

9）业务接口调用模块测试

1 登录认证模块测试

1.1 暴力破解测试

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

一般分为以下三种情况：

Ø 在已知账号的情况下，加载密码字典针对密码进行穷举测试；

Ø 在未知账号的情况下，加载账号字典，并结合密码字典进行穷举测试；

Ø 在未知账号和密码的情况下，利用账号字典和密码字典进行穷举测试。

1.2 本地加密传输测试

本机加密传输测试是针对客户端与服务器的数据传输，查看数据是否采用SSL加密方式加密。

1.3 session测试

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

1.4 cookie仿冒测试

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在cookie中，并发送至客户端存储，攻击者通过尝试修改cookie中的身份标识，从而达到仿冒其他用户身份的目的，并拥有相关用户的所有权限。

1.5 密文比对认证测试

在系统登录时密码加密流程一般是先将用户名和密码发送到服务器，服务器会把用户提交的密码经过Hash算法加密后和数据库中存储的加密值比对，如果加密值相同，则判定用户提交密码正确。

但有些网站系统的流程是在前台浏览器客户端对密码进行Hash加密后传输给服务器并与数据库加密值进行对比，如果加密值相同，则判定用户密码正确，此流程会泄露密码加密方式，导致出现安全隐患。

1.6 登录失败信息测试

在用户登陆系统失败后，系统会在页面显示用户登录的失败信息，假如提交账号系统中不存在，系统提示“用户名不存在”、“账号不存在”等明确信息，假如提交账号在系统中存在，则系统提示“密码/口令错误”等间接提示信息，攻击者可根据此类登录失败提示信息来判断当前登录账号是否在系统中存在，从而进行有针对性的暴力破解口令测试。

2 业务办理模块测试

2.1 订单ID篡改测试

在有电子交易业务的网站中，用户登录后可以下订单购买相应产品，购买成功后，用户可以查看订单的详情。当开发人员没有考虑登录后用户间权限隔离的问题时，就会导致平行权限绕过漏洞。攻击者只需注册一个普通账户，就可以通过篡改、遍历订单id，获得其他用户订单详情，其中多数会包括用户的姓名、身份证、地址、电话号码等敏感隐私信息。黑色产业链中的攻击者通常会利用此漏洞得到这些隐私信息。

2.2 手机号码篡改测试

手机号通常可以代表一个用户身份。当请求中发现有手机号参数时，我们可以试着修改它，测试是否存在越权漏洞。系统登录功能一般先判断用户名和密码是否正确，然后通过Session机制赋予用户令牌。但是在登录后的某些功能点，开发者很容易忽略登录用户的权限问题。所以当我们用 A 的手机号登录后操作某些功能时，抓包或通过其他方式尝试篡改手机号，即可对这类问题进行测试。

2.3 用户ID篡改测试

从开发的角度，用户登录后查看个人信息时，需要通过sessionid判定用户身份，然后显示相应用户的个人信息。但有时我们发现在GET或POST请求中有userid这类参数传输，并且后台通过此参数显示对应用户隐私信息，这就导致了攻击者可以通过篡改用户ID越权访问其他用户隐私信息。黑色产业链中的攻击者也喜欢利用此类漏洞非法收集个人信息。

2.4 邮箱和用户篡改测试

在发送邮件或站内消息时，篡改其中的发件人参数，导致攻击者可以伪造发信人进行钓鱼攻击等操作，这也是一种平行权限绕过漏洞。用户登录成功后拥有发信权限，开发者就信任了客户端传来的发件人参数，导致业务安全问题出现。

2.5 商品编号篡改测试

在交易支付类型的业务中，最常见的业务漏洞就是修改商品金额。例如在生成商品订单、跳转支付页面时，修改 HTTP 请求中的金额参数，可以实现 1 分买充值卡、1元买特斯拉等操作。此类攻击很难从流量中匹配识别出来，通常只有在事后财务结算时发现大额账务问题，才会被发现。此时，攻击者可能已经通过该漏洞获得了大量利益。如果金额较小或财务审核不严，攻击者则可能细水长流，从中获得持续的利益。事后发现此类漏洞，就大大增加了追责的难度和成本。此类业务漏洞的利用方法，攻击者除了直接篡改商品金额，还可以篡改商品编号，同样会造成实际支付金额与商品不对应，但又交易成功的情况。攻击者可以利用此业务漏洞以低价购买高价的物品。

2.6 竞争条件测试

竞争条件通常是在操作系统编程时会遇到的安全问题：当两个或多个进程试图在同一时刻访问共享内存，或读写某些共享数据时，最后的竞争结果取决于线程执行的顺序（线程运行时序），称为竞争条件（Race Conditions）。在Web安全中，我们可以沿用这个概念，在服务端逻辑与数据库读写存在时序问题时，就可能存在竞争条件漏洞。攻击者通常利用多线程并发请求，在数据库中的余额字段更新之前，多次兑换积分或购买商品，从中获得利益。

3 业务授权访问模块

3.1 非授权访问测试

非授权访问是指用户在没有通过认证授权的情况下能够直接访问需要通过认证才能访问到的页面或文本信息。可以尝试在登录某网站前台或后台之后，将相关的页面链接复制到其他浏览器或其他电脑上进行访问，观察是否能访问成功。

3.2越权测试

越权一般分为水平越权和垂直越权，水平越权是指相同权限的不同用户可以互相访问；垂直越权是指使用权限低的用户可以访问权限较高的用户。水平越权测试方法主要是看能否通过A用户的操作影响B用户。垂直越权测试方法的基本思路是低权限用户越权高权限用户的功能，比如普通用户可使用管理员功能。

4 输入/输出模块测试

4.1SQL注入测试

SQL注入就是通过把SQL命令插入Web表单提交或输入域名页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令的目的。具体来说，它是利用现有应用程序，将（恶意）SQL命令注入后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL 语句获取一个存在安全漏洞的网站上的数据库权限，而不是按照设计者的意图去执行SQL语句。下面通过一个经典的万能密码登录案例深入浅出地介绍SQL注入漏洞。SQL注入按照请求类型分为：GET型、POST型、Cookie注入型。GET与POST两种类型的区别是由表单的提交方式决定的。按照数据类型可分为：数字型和字符型（数字也是字符，严格地说就是一类，区别在于数字型不用闭合前面的SQL语句，而字符型需要闭合）。测试方法分为报错型、延时型、盲注型、布尔型等。数字型注入（一般存在于输入的参数为整数的情况下，如 ID、年龄等）测试方法如下。

第一步：正常请求，查看页面。

第二步：在请求的参数后加and 1=1，如果可以添加执行，则和第一步的返回页面并无差异。

第三步：在请求参数后加and 1=2，如果返回页面与第二步页面明显不同，或有所差异，则断定存在数字型注入。字符型注入（一般存在于接收的参数为字符串的情况下，如姓名、密码等）测试方法如下。

第一步：正常请求查看页面（如查询admin用户信息，则返回admin用户的信息）。

第二步：在查询的参数后加’or 1=1（有时可以加--来注释后面的语句），加单引号的目的是闭合前面的SQL语句并与后面的语句形成语法正确的SQL语句。如果可以添加并能够执行，则返回除 admin 用户外所有用户的信息。这时可以判断存在字符型注入。

4.2 XSS测试

跨站脚本漏洞是Web应用程序在将数据输出到网页的时候存在问题，导致恶意攻击者可以往Web页面里插入恶意JavaScript、HTML代码，并将构造的恶意数据显示在页面的漏洞中。攻击者一般利用此漏洞窃取或操纵客户会话和 Cookie，用于模仿合法用户，从而使攻击者以该用户身份查看或变更用户记录以及执行事务。跨站一般情况下主要分为存储型跨站、反射型跨站、DOM型跨站。存储型跨站脚本可直接写入服务端数据库，而反射型不写入数据库，由服务端解析后在浏览器生成一段类似<script>alert（/xss/）</script>的脚本。反射型跨站测试方法主要是在URL或输入框内插入一段跨站脚本，观察是否能弹出对话框。存储型跨站测试方法主要是在网站的留言板、投诉、建议等输入框内输入一段跨站脚本，看是否能插入数据库，插入成功的表现为当网站管理人员查看该留言时，会执行跨站语句（如弹出对话框），或者当普通用户再次访问该页面时，会执行跨站语句，如弹出对话框。

4.3 命令执行测试

在应用需要调用一些外部程序去处理内容的情况下，就会用到一些执行系统命令的函数。如PHP中的system、exec、shell_exec等，当用户可以控制命令执行函数中的参数时，将可注入恶意系统命令到正常命令中，造成命令执行攻击。测试中如果没有对参数（如cmd=、command、excute=等）进行过滤，就可以直接造成命令执行漏洞或配合绕过及命令连接符（在操作系统中，“&、|、||、；”都可以作为命令连接符使用，用户通过浏览器提交执行命令，由于服务器端没有针对执行函数做过滤，导致在没有指定绝对路径的情况下就执行命令）等进行命令执行漏洞测试。

5 回退模块测试

5.1 回退测试

很多Web业务在密码修改成功后或者订单付款成功后等业务模块，在返回上一步重新修改密码或者重新付款时存在重新设置密码或者付款的功能，这时如果能返回上一步重复操作，而且还能更改或者重置结果，则存在业务回退漏洞。

6 验证码机制测试

6.1 验证码暴力破解测试

验证码机制主要被用于防止暴力破解、防止DDoS攻击、识别用户身份等，常见的验证码主要有图片验证码、邮件验证码、短信验证码、滑动验证码和语音验证码。以短信验证码为例。短信验证码大部分情况下是由4～6位数字组成，如果没有对验证码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来进行暴力破解攻击。

6.2 验证码重复使用测试

在网站的登录或评论等页面，如果验证码认证成功后没有将session及时清空，将会导致验证码首次认证成功之后可重复使用。测试时可以抓取携带验证码的数据包重复提交，查看是否提交成功。

6.3 验证码客户端回显测试

当验证码在客户端生成而非服务器端生成时，就会造成此类问题。当客户端需要和服务器进行交互发送验证码时，可借助浏览器的工具查看客户端与服务器进行交互的详细信息。

6.4 验证码绕过测试

在一些案例中，通过修改前端提交服务器返回的数据，可以实现绕过验证码，执行我们的请求。攻击者进入注册账户页面，输入任意手机号码，获取验证码，在注册账户页面填写任意验证码，提交请求并抓包，使用抓包工具查看并修改返回包信息，转发返回数据包，查看是否注册成功。

6.5 验证码自动识别测试

网站登录页面所使用的图形验证码是出现最早也是使用最为广泛的验证码，我们就以图形验证码为例来讲解如何对其进行自动识别。一般对于此类验证码的识别流程为：图像二值化处理→去干扰→字符分割→字符识别。图像二值化就是将图像上像素点的灰度值设置为0或255，也就是将整个图像呈现出明显的黑白效果。为了防止验证码被自动识别，通常用加入一些点、线、色彩之类的方式进行图像干扰所以为了达到良好的识别效果，需要对图像进行去干扰处理。字符分割主要包括从验证码图像中分割出字符区域，以及把字符区域划分成单个字符。字符识别就是把处理后的图片还原回字符文本的过程。

7 业务数据安全测试

7.1 商品支付金额篡改测试

电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是确保在用户客户端与服务、业务系统接口之间的数据传输的一致性，通常在订购类交易流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交的业务数据而导致的商品金额篡改漏洞。商品金额篡改测试，通过抓包修改业务流程中的交易金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。

7.2 商品订购数量篡改测试

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

7.3 前端JS限制绕过测试

很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务器端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数据完成业务流程。

7.4 请求重放测试

请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“一次购买多次收货”等违背正常业务逻辑的结果。

7.5 业务上限测试

业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中，服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。通常情况下，在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性的应用程序，通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。

8 业务流程乱序测试

8.1 业务流程绕过测试

该项测试主要针对业务流程的处理流程是否正常，确保攻击者无法通过技术手段绕过某些重要流程步骤，检验办理业务过程中是否有控制机制来保证其遵循正常流程。例如业务流程分为三步：第一步，注册并发送验证码；第二步，输入验证码；第三步，注册成功。在第三步进行抓包分析，将邮箱或手机号替换为其他人的，如果成功注册，就跳过了第一步和第二步，绕过了正常的业务流程。

9 密码找回模块测试

9.1 验证码客户端回显测试

找回密码测试中要注意验证码是否会回显在响应中，有些网站程序会选择将验证码回显在响应中，来判断用户输入的验证码是否和响应中的验证码一致，如果一致就会通过校验。

9.2 验证码暴力破解测试

找回密码功能模块中通常会将用户凭证（一般为验证码）发送到用户自己才可以看到的手机号或者邮箱中，只要用户不泄露自己的验证码就不会被攻击者利用，但是有些应用程序在验证码发送功能模块中验证码位数及复杂性较弱，也没有对验证码做次数限制而导致验证码可被暴力枚举并修改任意用户密码。在测试验证码是否可以被暴力枚举时，可以先将验证码多次发送给自己的账号，观察验证码是否有规律，如每次接收到的验证码为纯数字并且是4位数。

9.3 接口参数账号修改测试

找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账号的参数，而用户账号参数作为一个可控的变量是可以被篡改的，从而导致修改账号密码的凭证或修改的目标账号出现偏差，最终造成任意账号密码修改的漏洞。

通常在找回密码逻辑中，服务端会要求用户提供要修改的账号，然后给这个账号发送只有账号主人才能看到的凭证。比如给这个账号主人绑定的邮箱或手机号发送验证码，或者找回密码的链接，这样可以保证只有账号主人才可以看到这些凭证。但是如果服务端对账号的控制逻辑不当，就会导致原有账号被篡改为其他账号，服务端把凭证发送给篡改后的账号的邮箱或手机，最终造成可利用凭证重置任意账号密码的漏洞。

9.4 Response状态值修改测试

Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或者手机App往往因为校验不严格而导致了非常危险的重置密码操作。这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true、1、ok、success等，网站看到回显内容为特定值后即修改密码，通常这种漏洞的回显值校验是在客户端进行的，所以只需要修改回显即可。

9.5 Session覆盖测试

找回密码逻辑漏洞测试中也会遇到参数不可控的情况，比如要修改的用户名或者绑定的手机号无法在提交参数时修改，服务端通过读取当前session会话来判断要修改密码的账号，这种情况下能否对Session中的内容做修改以达到任意密码重置的目的呢？在某网站中的找回密码功能中，业务逻辑是：由用户使用手机进行注册，然后服务端向手机发送验证码短信，用户输入验证码提交后，进入密码重置页面。对网站中Session覆盖的测试如下：

（1）需要准备自己的账号接收凭证（短信验证码）；

（2）获得凭证校验成功后进入密码重置页面；

（3）在浏览器新标签重新打开找回密码页面，输入目标手机号；

（4）此时当前 Session 账户已经被覆盖，重新回到第二步中打开的重置密码页面即可重置目标手机号。

9.6 弱Token设计缺陷测试

在找回密码功能中，很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱，打开找回密码邮件中的链接，就可以进入密码重置页面了。找回密码的链接通常会加入校验参数来确认链接的有效性，通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效。例如，网站给出的找回密码的url如下，单击这个链接将跳转到重置密码页面。

http://www.xxx.com/findpwd?uid=xx-uu-xx-sxx&token=1497515314

观察这个链接的参数，uid参数可能是对应修改密码的账户，Token就是之前提到的校验参数了，这个参数的值看起来像一个时间戳，猜测系统生成这个token的机制就是使用的时间戳。把这个值通过时间格式化后发现确实变成了日期，那么这个Token就是可预测的一个时间范围的时间戳，只需要通过这个时间段就可以推测或者暴力枚举出系统生成的时间戳值。

9.7 密码找回流程绕过测试

很多网站的密码找回功能一般有以下几个步骤。

（1）用户输入找回密码的账号；

（2）校验凭证：向用户发送短信验证码或者找回密码链接，用户回填验证码或单击

链接进入密码重置页面，以此方式证明当前操作用户是账号主人；

（3）校验成功进入重置密码页面。

在找回密码逻辑中，第二步校验凭证最为重要。不是账号主人是无法收到校验凭证的，试想有没有办法可以绕过第二步凭证校验，直接进入第三步重置密码呢？

用户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们首先要收集三个步骤的请求接口，重点是收集到最后一步重置密码的接口，这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。

10 业务接口调用模块测试

10.1 接口调用重放测试

在短信、邮件调用业务或生成业务数据环节中，如短信验证码、邮件验证码、订单生成、评论提交等，对业务环节进行调用（重放）测试。如果业务经过调用（重放）后多次生成有效的业务或数据结果，可判断为存在接口调用（重放）问题。

10.2 接口调用遍历测试

Web 接口一般将常见的一些功能需求进行封装，通过传入不同的参数来获取数据或者执行相应的功能，其中一个最常见的场景就是通过接口传入id参数，返回对应id的一些信息。在安全测试中，我们可以使用Burp Suite作为HTTP代理，记录所有请求和响应信息，通过Burp Suite以登录后的状态对整站进行爬取，再使用过滤功能找到传入id参数的HTTP请求，然后通过Intruder对id参数进行遍历，看是否返回不同的响应信息。如果不同的id值对应不同用户的信息，则说明存在漏洞。接口调用参数篡改测试：在短信、邮件调用业务环节中，例如短信验证码、邮件验证码。修改对应请求中手机号或邮箱地址参数值提交后，如果修改后的手机号或邮箱收到系统发送的信息，则表示接口数据调用参数可篡改。

10.3 接口未授权访问/调用测试

在正常的业务中，敏感功能的接口需要对访问者的身份进行验证，验证后才允许调用接口进行操作。如果敏感功能接口没有身份校验，那么攻击者无须登录或者验证即可调用接口进行操作。在安全测试中，我们可以使用Burp Suite作为HTTP代理，在登录状态下记录所有请求和响应信息，筛选出敏感功能、返回敏感数据的请求。在未登录的情况下，使用浏览器访问对应敏感功能的请求，如果返回的数据与登录状态后的一致，则存在漏洞或缺陷。

参考：《Web攻防之业务安全实战指南》

关注公众号了解更多资讯

原文始发于微信公众号（纵横安全圈）：业务逻辑测试主要技术手段