【业务安全01】业务安全基础及测试流程

Fighting_hawk

已于 2022-07-01 02:56:38 修改

阅读量5.9k

点赞数 4

分类专栏： # 筑基07：WEB漏洞原理文章标签：安全安全架构 web安全业务逻辑漏洞业务安全

于 2022-03-17 11:10:48 首次发布

本文链接：https://blog.csdn.net/Fighting_hawk/article/details/123524358

版权

筑基07：WEB漏洞原理专栏收录该内容

58 篇文章 49 订阅

订阅专栏

1 互联网业务安全概述

1.1 业务安全背景

近年来，随着信息化技术的迅速发展和全球一体化进程的不断加快，计算机和网络已经成为与所有人都息息相关的工具和媒介，个人的工作、生活、娱乐，企业的生产、管理，乃至国家的发展和改革都无处其外。
信息和互联网带来的不仅仅是便利和高效，大量隐私、敏感和高价值的信息数据资产成为恶意攻击者攻击和威胁的主要目标，从早期以极客为核心的黑客黄金时代，待现在利益链驱动的庞大黑色产业，网络安全已经成为任何个人、企业、组织和国家必须面临的重要问题。

1.2 业务安全现状

随着互联网+的发展，经济形态不断发生演变。众多传统行业逐步地融入互联网，并利用信息通信技术和互联网平台进行频繁的商务活动，这些平台（如银行、保险、证券、电商、P2P、020、游戏、社交、招聘、航空等）由于涉及大量的金钱、个人信息、交易等重要隐私数据，已经成为黑客攻击的首要目标，而由于业务开发人员往往只注重功能的实现而忽略了在用户使用过程中个人行为对Web应用程序的业务逻辑功能的安全性影响、开发代码频繁迭代导致这些平台业务逻辑层面的安全风险层出不穷。
这些漏洞主要是开发人员业务流程设计的缺陷，不仅存在于网络层、系统层、代码层等。比如登录验证的绕过、交易中的数据修改、接口的恶意调用等，都属于业务逻辑漏洞。

1.3 黑客攻击的目标

一方面随着社会和科技的发展，购物、社交、P2P、020、游戏、招聘等业务纷纷具备在线支付功能，同时还保存大量隐私、敏感数据。如电商支付系统保存着用户手机号、姓名、家庭住址、银行卡信息及支付密码等，这些信息都是黑客感兴趣的敏感信息。攻击者可以利用程序员的设计缺陷进行交易数据篡改、敏感信息盗取、资产窃取等操作。
另一方面，如今的业务系统对于传统安全漏洞防护的技术和设计越来越成熟，基于传统漏洞入侵也变得越来越困难，增加了黑客攻击的成本。而业务逻辑漏洞可以逃逸大部分的安全防护，迄今为止没有很好的解决办法。这也是为什么黑客偏好使用业务逻辑漏洞攻击的一个原因。

2 业务安全测试流程

2.1 测试准备

准备阶段内容：主要是对业务系统的前期熟悉工作。
针对白盒性质的测试，可以结合相关开发文档去熟悉相关系统业务。
针对黑盒测试，可以通过实际操作还原业务流程的方法理解业务。

2.2 业务调研

调研阶段内容：主要针对业务系统相关负责人进行访谈调研，了解业务系统的整体情况，包括部署情况、功能模块、业务流程、数据流、业务逻辑以及现有的安全措施等内容。
根据以往测试实施经验，在业务调研前可先设计访谈问卷，访谈后可能会随着对客户业务系统具体情况和随着了解的深入不断调整、更新问卷。
黑盒测试可忽略此步骤。

2.3 业务建模及流程梳理

2.3.1 建模及流程梳理

业务场景建模：针对不同行业、不同平台的业务系统，如电商、银行、金融、证券、保险、游戏、社交、招聘等业务系统，识别出其中的高风险业务场景进行建模。
建模完成后，需要对重要业务场景的各个业务模块逐一进行业务流程梳理。

2.3.2 流程梳理的关键点

分析维度：从前台、后台、业务和支撑系统等4个维度进行分析；
目的：识别各业务模块的业务逻辑、业务数据流和功能字段等。
原则：
1. 对于业务核心主流程，应梳理关键环节
  区分业务的主要流程和分支流程，业务流程梳理工作主要围绕主流程进行分析，而主流程一定是核心业务流程，因此业务流程重点梳理的对象应该放在核心主流程上，务必梳理出业务的关键环节。
2. 对于业务分支流程，可归纳一并测试
  概括归纳业务分支流程，业务分支流程往往存在通用点，可将具有业务相似性的分支流程归纳成某一类型的业务流程，无需单独对其进行测试。
3. 识别业务流程数据信息流，特别是业务数据流在交互方双方之间传输的先后顺序、路径等。先后顺序很重要，测试时经常需要测试业务流程是否会乱序。
4. 识别业务流程数据信息流功能字段，识别数据流中包含的重要程度不等的信息，理解这些字段的含义有助于下阶段风险点分析。

2.4 业务风险点识别

在完成前期不同维度的业务流程梳理工作后，针对前台业务应着重关注用户操作每一步可能的逻辑风险，针对后台业务应着重关注数据安全、数据流转以及处理的日志和审计。
业务风险点识别应主要关注以下安全风险内容
1. 业务环节存在的安全风险指的是业务使用者可见的业务存在的安全风险。如在注册、登录的密码找回等身份认证环节：
  （1）是否存在完善的验证码机制、数据一致性校验机制、Session和Cookie校验机制等。
  （2）是否能规避绕过、暴力破解和SQL注入等漏洞。
2. 支持系统存在的安全风险。如：
  （1）用户访问控制机制是否完善，是否存在水平越权或垂直越权漏洞。
  （2）系统内加密存储机制是否完善。
  （3）业务数据是否明文传输。
  （4）业务使用的业务接口是否可以未授权访问、调用；是否可以调用重放、遍历。
  （5）接口调用参数是否可以篡改。
3. 支持系统间存在的安全风险，如：
  （1）系统间传输的数据是否加密。
  （2）系统间传输的参数是否可篡改。
  （3）系统间输入参数的过滤机制是否完善。
  （4）是否可能导致SQL注入、XSS跨站脚本、代码注入命令注入、代码执行等漏洞。
4. 业务环节间存在的安全风险，如：
  （1）系统业务流程是否存在乱序问题，导致某个业务环节可绕过、回退、或某个业务请求可以无限重放；
  （2）业务环节间传输的数据是否有一致性校验机制；
  （3）业务环节间传输的数据是否可被篡改的风险。
5. 业务环节与支持系统间存在的安全风险，如：
  （1）数据传输是否加密。
  （2）加密方式是否完善，是否采用前端加密、简单MD5编码等不安全的加密方式。
  （3）系统处理多线程并发请求的机制是否完善。
  （4）服务端逻辑与数据库读写是否存在时序问题（如QQ刷钻漏洞）。
  （5）是否存在竞争条件漏洞。
  （6）系统间输入参数的过滤机制是否完善。
关于身份验证与访问控制：
1. 失效的身份验证是指验证身份时出错（可能是被攻击者如何绕过或欺骗）；
2. 失效的访问控制是指用户没有欺骗行为而系统在判断其是否能访问目标资源时出错。
可以采用类似下面的表格进行检验。