文章目录业务安全简介黑客目标业务安全测试流程测试准备业务建模业务流程整理业务风险点识别测试编制报告业务数据安全商品支付金额篡改前端JS限制绕过验证请求篡改测试业务上限测试商品订单数量damiCMS V5.1例路径恢复安全验证码客户端回波验证码暴力破解响应se状态值修复测试Session覆盖弱token设计缺陷测试绕过密码恢复过程测试接口参数帐户修复metinfo V4.0示例
企业安全概述
近年来随着信息化技术的飞速发展和全球化的加速计算机和网络已经成为一切
人与人密切相关的工具和媒体、个人工作、生活和娱乐、企业管理、全国反捕获v资产都在之外。 信息和互联网带来的不仅是方便高效，还有大量隐私、敏感、高价值的信息数据和资产
成为恶意攻击者攻击和威胁的主要目标，从早期极客为主的黑客黄金时代，到当今利益链驱动的巨大黑色产业，网络安全成为任何个人、企业、组织和国家都必须面对的重要问题。 “网络安全和信息化是关系国家安全和国家发展、关系广大人民群众工作生活的重大战略问题。 没有网络安全就没有国家安全，没有信息化就没有现代化。 ”
随着互联网的发展，经济形态不断演化。 许多传统行业逐渐融入互联网，利用信息通信技术和网络平台进行频繁的商务活动。 这些平台(如银行、保险、证券、电商、P2P、020、游戏、社交、招聘、航空等)涉及大量金钱、个人信息、交易等重要隐私数据，成为黑客的自我目标开发者安全意识淡薄(3358www.Sina.com) )、开发代码的频繁迭代使得这些平台在业务逻辑方面的安全风险层出不穷(3358www.Sina.com) )
黑客的目标一方面是随着社会和科技的发展，购物、社交、P2P，020、游戏、招聘等业务相继具备了在线支付功能。 例如，电商的支付系统中存储有用户的手机号码、姓名、家庭地址、包括支付在内的银行卡信息、支付密码信息等，这些都是黑客感兴趣的敏感信息。 攻击者可以利用程序员的设计缺陷进行交易数据篡改、敏感信息被盗、资产被盗等操作。只注重实现功能而忽略了在用户使用过程中个人的行为对Web 应用程序的业务逻辑功能的安全性影响
同时，当前的业务系统随着传统安全漏洞防护技术和设备的成熟，基于传统漏洞进行入侵变得越来越困难，黑客攻击的成本增加。 业务逻辑漏洞可以逃避各种安全措施，从来没有好的解决方案。 也是黑客喜欢业务逻辑漏洞攻击的理由之一。
业务安全测试流程
测试的准备阶段主要包括对业务系统的前期知识。
对白盒性质的测试，可结合相关开发文件熟悉相关系统业务；
黑匣子测试时，可以通过实际操作恢复业务流程来理解业务。
业务调查业务调查阶段主要对业务系统相关负责人进行访谈，了解业务系统的总体情况，包括部署情况、功能模块、业务流程、数据流、业务逻辑、现有安全措施等。 根据以往的测试实施经验，可以在业务调查前设计采访问卷，采访后随着对客户业务系统具体情况的了解，不断调整、调整问卷(业务逻辑漏洞主要是开发人员业务流程设计的缺陷，不仅限于网络层、系统层、代码层等。比如登录验证的绕过、交易中的数据篡改、接口的恶意调用等，都属于业务逻辑漏洞)
业务建模是针对电子商务、银行、金融、证券、保险、游戏、社交、招聘等不同行业、不同平台的业务系统，识别其中的高风险业务场景并进行建模。
业务流程整理建模完成后，将关键业务场景的各业务模块逐一进行业务流程整理，从前台和后台、业务和支撑系统等4个不同维度进行分析，识别各业务模块的业务逻辑、业务数据流和功能字段等
业务模块的流程整理主要遵循以下原则。
区分业务主流程和分支流程。 业务清理工作以主流程为中心进行分析，但主流程必须是核心业务流程。 业务流程重点梳理的对象首先要放在核心主线上，要理清业务的关键环节； 概括业务分支流程，业务分支流程往往有共同点，不需要单独测量具有业务相似性的分支流程，就可以归纳为某一类型的业务流程
试试看； 识别业务流程数据流，特别是业务数据流在交互者双方之间传输的优先级、路径等； 识别业务数据流功能字段，识别数据流中包含的不同重要性信息，并理解这些字段的含义，有助于下一阶段的风险点分析。
在业务流程的每个阶段，组织业务流程的关键点：
业务风险点识别前期不同维度的业务流程清理工作结束后，对前台业务应重点关注用户界面操作各步骤可能的逻辑风险和技术风险； 后台业务应重点关注数据安全、数据流和处理的日志和审核。
确定业务风险点应主要关注以下安全风险内容：
作为业务一环存在的安全风险
业务环节存在的安全风险是指注册、登录、密码恢复等业务中存在的安全风险，包括验证码机制、数据一致性检查机制、Session和Cookie检查机制等
QL注入等漏洞。支持系统存在的安全风险支持系统存在的安全风险，如用户访问控制机制是否完善，是否存在水平越权或垂直越权漏洞
系统内加密存储机制是否完善，业务数据是否明文传输。系统使用的业务接口是否可以未授权访问/调用，是否可以调用重放、遍历，接口调用参数是否可篡改等。业务环节间存在的安全风险
业务环节间存在的安全风险，如系统业务流程是否存在乱序，导致某个业务环节可绕过、回退
或某个业务请求可以无限重放。业务环节间传输的数据是否有一致性校验机制，是否存在业务数据可被篡改的风险。支持系统间存在的安全风险
支持系统间存在的安全风险，如系统间数据传输是否加密、系统间传输的参数是否可篡改。系统间输入参数的过滤机制是否完善，是否可能导致SQL注入、XSS跨站脚本和代码执行漏洞。业务环节与支持系统间存在的安全风险
业务环节与支持系统间存在的风险，如数据传输是否加密、加密方式是否完善，是否采用前端加密、简单MD5编码等不安全的加密方式。系统处理多线程并发请求的机制是否完善。服务端逻辑与数据库读写是否存在时序问题，导致竞争条件漏洞（早年间QQ刷钻）。系统间输入参数的过滤机制是否完善。 开展测试
对前期业务流程梳理和识别出的风险点，进行有针对性的测试。
撰写报告针对业务安全测试过程中发现的风险结果进行评价和建议，综合评价利用场景的风险程度和造成影响的严重程度，最终完成测试报告的编写。
业务数据安全 商品支付金额篡改电商类网站在业务流程整个环节，需要对业务数据的完整性和一致性进行保护，特别是确保在用户客户端与服务器、业务系统接口之间的数据传输的一致性，通常在订购类交易流程中，容易出现服务器端未对用户提交的业务数据进行强制校验，过度信赖客户端提交的业务数据而导致的商品金额篡改漏洞。
商品金额篡改测试，通过抓包修改业务流程中的交易金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。
该项测试主要针对订单生成的过程中存在商品支付金额校验不完整而产生业务安全风险点，通常导致攻击者用实际支付远低于订单支付的金额订购商品的业务逻辑漏洞。
前端JS 限制绕过验证很多商品在限制用户购买数量时，服务器仅在页面通过JS脚本限制，未在服务器端校验用户提交的数量，通过抓取客户端发送的请求包修改JS端生成处理的交易数据，如将请求中的商品数量改为大于最大数限制的值，查看能否以非正常业务交易数据完成业务流程。
该项测试主要针对电商平台由于交易限制机制不严谨、不完善而导致的一些业务逻辑问题。例如：在促销活动中限制商品购买数量，却未对数量进行前、后端严格校验，往往被攻击者所利用，购买多个促销商品,造成商家的损失。
请求重放测试请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞，通常情况下所引发的安全问题表现在商品首次购买成功后，参照订购商品的正常流程请求，进行完全模拟正常订购业务流程的重放操作，可以实现“一次购买多次收货”等违背正常业务逻辑的结果。
该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题，通过该项测试可以验证交易流程中随机数、时间戳等生成机制是否正常。
业务上限测试业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中，服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而引发的一些业务逻辑漏洞。
通常情况下，在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在此类脆弱性的应用程序，通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。
该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应。
商品订购数量篡改商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段，如将请求中的商品数量修改成任意非预期数额、负数等进行提交，查看业务系统能否以修改后的数量完成业务流程。
该项测试主要针对商品订购的过程中对异常交易数据处理缺乏风控机制而导致相关业务逻辑漏洞，例如针对订购中的数量、价格等缺乏判断而产生意外的结果，往往被攻击者利用。
damiCMS V5.1为例点击进入商品详情页面
立即购买
提示没有登陆，我们注册一个账户：
注册成功后进行登录，再次今日购买商品页面：
抓到提交订单的包：
更改数量为-1，进行转发：
查看订单：
查看我们的钱包：
找回密码测试中要注意验证码是否会回显在响应中，有些网站程序会选择将验证码回显在响应中，来判断
用户输入的验证码是否和响应中的验证码-致，如果一致就会 通过校验。
找回密码功能模块中通常会将用户凭证( 一般为验证码)发送到用户自己才可以看到的手机号或者邮箱中，只要用户不泄露自己的验证码就不会被攻击者利用，但是有些应用程序在验证码发送功能模块中验证码位数及复杂性较弱，也没有对验证码做次数限制而导致验证码可被暴力枚举并修改任意用户密码。
在测试验证码是否可以被暴力枚举时，可以先将验证码多次发送给自己的账号，观察验证码是否有规律，如每次接收到的验证码为纯数字并且是4位数。
Response 状态值修改测试Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这种漏洞的网站或者手机App往往因为校验不严格而导致了非常危险的重置密码操作。
这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true、1、ok、success等， 网站看到回显内容为特定值后即修改密码，通常这种漏洞的回显值校验是在客户端进行的,
所以只需要修改回显即可。
找回密码逻辑漏洞测试中也会遇到参数不可控的情况，比如要修改的用户名或者绑定的手机号无法在提交参数时修改，服务端通过读取当前session会话来判断要修改密码的账号，这种情况下能否对Session中的内容做修改以达到任意密码重置的目的呢?
在某网站中的找回密码功能中，业务逻辑是：由用户使用手机进行注册，然后服务端向手机发送验证码短信，用户输入验证码提交后，进入密码重置页面。
对网站中Session 覆盖的测试如下:
需要准备自己的账号接收凭证(短信验证码) ;获得凭证校验成功后进入密码重置页面;在浏览器新标签重新打开找回密码页面，输入目标手机号;此时当前Session 账户已经被覆盖，重新回到第二步中打开的重置密码页面即可重置目标手机号。 弱token 设计缺陷测试在找回密码功能中，很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱，打开找回密码邮件中的链接，就可以进入密码重置页面了。找回密码的链接通常会加入校验参数来确认链接的有效性，通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效。
例如：http://www.XXX.com/findpwd?uid=Xx–lyddx–xx–sxx&token=1497515314
很多网站的密码找回功能一般有以下几个步骤：
用户输入找回密码的账号;校验凭证:向用户发送短信验证码或者找回密码链接，用户回填验证码或单击链接进入密码重置页面，以此方式证明当前操作用户是账号主人;校验成功进入重置密码页面。在找回密码逻辑中，第二步校验凭证最为重要。不是账号主人是无法收到校验凭的，试想有没有办法可以绕过第二步凭证校验，直接进入第三步重置密码呢?
用户修改密码需要向服务器发送修改密码请求，服务器通过后再修改数据库中相应的密码，所以在测试中我们首先要收集三个步骤的请求接口，重点是收集到最后一步重置密码的接口，这样我们可以直接跳过凭证校验的接口去尝试直接重置密码。
接口参数账号修改找回密码功能逻辑中常常会在用户修改密码接口提交参数中存在传递用户账号的参数，而用户账号参数作为一个可控变量是可以被篡改的，从而导致修改账号密码的凭证或修改的目标账号出现偏差，最终造成任意账号密码修改的漏洞。
通常在找回密码逻辑中，服务端会要求用户提供要修改的账号，然后给这个账号发送只有账号主人才能看到的凭证。比如给这个账号主人绑定的邮箱或者手机号发送验证码，或者找回密码链接，这样可以保证只有账号主人才可以看到这些凭证。但是如果服务器对账号的控制逻辑不当，就会导致原有账号被篡改为其他账号，服务器端把凭证发送给篡改后的账号的邮箱或手机，最终造成可利用凭证重置任意账号密码的漏洞。
接口参数账号修改流程测试为拦截前端请求，通过修改请求内的账号ID、名称或者邮箱、手机号等参数，将修改后的数据发送给服务器进行欺骗达到密码重置的目的。
metinfo V4.0为例首页：
开另一台浏览器进入后台管理界面：
从首页进入会员中心注册一个账号进行登录：
登录成功之后，进入修改信息页面：
抓到这个包：
既然能够修改成功，我们这次看能否修改掉其他用户的密码：
查看另一浏览器登录的admin账号已经退出登录：
使用更改的密码进行登录：登陆成功！