代做机械毕业设计网站,手机网站横向切换,wordpress推广升级vip,国内网站设计欣赏文章目录 1、业务安全概述1.1业务安全现状1.1.1、业务逻辑漏洞1.1.2、黑客攻击目标 2、业务安全测试2.1、业务安全测试流程2.1.1、测试准备2.1.2、业务调研2.1.3、业务建模2.1.4、业务流程梳理2.1.5、业务风险点识别2.1.6 开展测试2.1.7 撰写报告 3、业务安全经典场景3.1、业务… 文章目录 1、业务安全概述1.1业务安全现状1.1.1、业务逻辑漏洞1.1.2、黑客攻击目标 2、业务安全测试2.1、业务安全测试流程2.1.1、测试准备2.1.2、业务调研2.1.3、业务建模2.1.4、业务流程梳理2.1.5、业务风险点识别2.1.6 开展测试2.1.7 撰写报告 3、业务安全经典场景3.1、业务数据安全3.1.1 商品⽀付⾦额篡改在线靶场演示 3.1.2 前端JS 限制绕过3.1.3 请求重放测试3.1.4 业务上限测试3.1.5 商品订购数量篡改大米cms案例演示 3.2、密码找回安全3.2.1、验证码客户端 回显测试3.2.2、验证码暴力破解3.2.3、Response状态码值修改测试3.2.4、Session覆盖3.2.5、弱Token设计缺陷测试在线靶场演示介绍 3.2.6 密码找回流程绕过测试3.2.7 接⼝参数账号修改metinfo_4.0 任意账号密码重置案例演示 1、业务安全概述
1.1业务安全现状
1.1.1、业务逻辑漏洞
近年来随着信息化技术的迅速发展和全球一体化进程的不断加快计算机和⽹络已经成为与所有⼈都息息相关的⼯具和媒介个⼈的⼯作、⽣活和娱乐企业的管理乃⾄国家的发展和改⾰都⽆处其外。信息和互联⽹带来的不仅仅是便利和⾼效⼤量隐私、敏感和⾼价值的信息数据和资产成为恶意攻击者攻击和威胁的主要⽬标从早期以极客为核⼼的⿊客⻩⾦时代到现在利益链驱动的庞⼤⿊⾊产业⽹络安全已经成为任何个⼈、企业、组织和国家所必须⾯临的重要问题。“⽹络安全和信息化是事关国家安全和国家发展、事关⼴⼤⼈⺠群众⼯作⽣活的重⼤战略问题没有⽹络安全就没有国家安全没有信息化就没有现代化。”
随着互联⽹ 的发展经济形态不断地发⽣演变。众多传统⾏业逐步地融⼊互联⽹并利⽤信息通信技术以及互联⽹平台进⾏着频繁的商务活动这些平台如银⾏、保险、证券、电商、P2P、O2O、游戏、社交、招聘、航空等由于涉及⼤量的⾦钱、个⼈信息、交易等重要隐私数据成为了⿊客攻击的⾸要⽬标而因为开发⼈员安全意识淡薄只注重实现功能而忽略了在⽤⼾使⽤过程中个⼈的⾏为对Web 应⽤程序的业务逻辑功能的安全性影响、开发代码频繁迭代导致这些平台业务逻辑层⾯的安全⻛险层出不穷。 业务逻辑漏洞主要是开发⼈员业务流程设计的缺陷不仅限于⽹络层、系统层、代码层等。⽐如登录验证的绕过、交易中的数据篡改、接口的恶意调⽤等都属于业务逻辑漏洞。
1.1.2、黑客攻击目标
一方面随着社会和科技的发展购物、社交、P2P、O2O、游戏、招聘等业务纷纷具备了在线支付功能。如电商支付系统保存了用户手机号、姓 名、家庭住址包括支付的银行卡信息、支付密码信息等这些都是黑客感兴趣的敏感信息。攻击者可以利用程序员的设计缺陷进行交易数据篡改、敏 感信息盗取、资产的窃取等操作。现在的黑客不在以炫耀技能为主要攻击目的而主要以经济利益为目的攻击的目的逐渐转变为趋利化。
另一方面如今的业务系统对于传统安全漏洞防护的技术、设备和开发框架越来越成熟基于传统漏洞入侵也变得越来越困难增加了黑客攻击的 成本。而业务逻辑漏洞可以逃逸各种安全防护迄今为止没有很好的解决办法。也是为什么黑客偏好使用业务逻辑漏洞攻击的一个原因
一夜薅走拼多多上千万背后的“羊毛党”究竟有多可怕
拼多多一夜被薅200亿4毛充100话费一个bug引发的惨案
为了解决业务安全所带来的风险所以要对业务安全进行审计
2、业务安全测试
2.1、业务安全测试流程 2.1.1、测试准备
准备阶段主要包括对业务系统的前期熟悉工作以了解被测试业务系统的数量、规模和场景等内容。
针对白盒测试可以结合相关开发文档去熟悉相关系统的业务针对黑盒测试可通过实际操作还原业务流程的方式理解业务
2.1.2、业务调研
业务调研阶段主要针对业务系统相关负责人进行访谈调研了解业务系统的整体情况包括部署情况、功能模块、业务流程、数据流、业务逻辑以 及现有的安全措施等内容。根据以往测试实施经验在业务调研前可先设计访谈问卷访谈后可能会随着对客户业务系统具体情况了解的深入而不断调 整、更新问卷黑盒测试此步骤可忽略。
2.1.3、业务建模
针对不同行业、不同平台的业务系统如电商、银行、金融、证券、保险、游戏、社交、招聘等业务系统识别出其中的高风险业务场景进行建 模。 以电商系统为例 2.1.4、业务流程梳理
以商城用户登录 建模完成后需要对重要业务场景的各个业务模块逐一进行业务流程梳理从前台和后台、业务和支撑系统等4 个不同维度进行分析识别各业务模 块的业务逻辑、业务数据流和功能字段传参点等。
业务模块的流程梳理主要遵循以下原则
区分业务主流程和分支流程业务梳理工作是围绕主流程进行分析的而主流程一定是核心业务流程业务流程重点梳理的对象首先应放在核 心主流程上务必梳理出业务关键环节概括归纳业务分支流程业务分支流程往往存在通用点可将具有业务相似性的分支流程归纳成某一类型的业务流程无须单独对其进行测 试识别业务流程数据信息流特别是业务数据流在交互方双方之间传输的先后顺序、路径等识别业务数据流功能字段识别数据流中包含的重要程度不等的信息理解这些字段的含义有助于下阶段风险点分析。 2.1.5、业务风险点识别
在完成前期不同维度的业务流程梳理工作后针对前台业务应着重关注用户界面操作每一步可能的逻辑风险和技术风险针对后台业务应着重关注 数据安全、数据流转及处理的日志和审计。
业务风险点识别应主要关注以下安全风险内容
业务环节存在的安全风险业务环节存在的安全风险指的是业务使用者可见的业务存在的安全风险如注册、登录和密码找回等身份认证环节是 否存在完善的验证码机制、数据一致性校验机制、Session 和Cookie 校验机制等是否能规避验证码绕过、暴力破解和SQL 注入等漏洞。
支持系统存在的安全风险支持系统存在的安全风险如用户访问控制机制是否完善是否存在水平越权或垂直越权漏洞。系统内加密存储机制是 否完善业务数据是否明文传输。系统使用的业务接口是否可以未授权访问或调用是否可以调用重放、遍历接口调用参数是否可篡改等。
业务环节间存在的安全风险业务环节间存在的安全风险如系统业务流程是否存在乱序导致某个业务环节可绕过、回退或某个业务请求可以 无限重放。业务环节间传输的数据是否有一致性校验机制是否存在业务数据可被篡改的风险。
支持系统间存在的安全风险如系统间数据传输是否加密、系统间传输的参数是否可篡改。系统间输入参数的过滤机 制是否完善是否可能导致SQL 注入、XSS 跨站脚本和代码执行漏洞。
业务环节与支持系统间存在的安全风险业务环节与支持系统间存在的风险如数据传输是否加密、加密方式是否完善是否采用前端加密、简单 MD5 编码等不安全的加密方式。系统处理多线程并发请求的机制是否完善服务端逻辑与数据库读写是否存在时序问题导致竞争条件漏洞。系统间 输入参数的过滤机制是否完善。 2.1.6 开展测试
对前期业务流程梳理和识别出的风险点进行有针对性的测试。
2.1.7 撰写报告
针对业务安全测试过程中发现的风险结果进行评价和建议综合评价利用场景的风险程度和造成影响的严重程度最终完成测试报告的编写
3、业务安全经典场景
3.1、业务数据安全
3.1.1 商品⽀付⾦额篡改
典型案例:
1 毛钱买电冰箱
电商类网站在业务流程整个环节需要对业务数据的完整性和一致性进行保护特别是确保在用户客户端与服务端、业务系统接口之间的数据传输 的一致性通常在订购类交易流程中容易出现服务器端未对用户提交的业务数据进行强制校验过度信赖客户端提交的业务数据而导致的商品金额篡 改漏洞。商品金额篡改测试通过抓包修改业务流程中的交易金额等字段例如在支付页面抓取请求中商品的金额字段修改成任意数额的金额并提 交查看能否以修改后的金额数据完成业务流程。
该项测试主要针对订单生成的过程中存在商品支付金额校验不完整而产生业务安全风险点通常导致攻击者用实际支付远低于订单支付的金额订购 商品的业务逻辑漏洞。 在线靶场演示
地址https://portswigger.net/web-security/all-labs
需要注册密码系统随机给定一个复杂的密码 根据提示可以使用账户wiener密码peter登录然后买一个夹克buy a Lightweight l33t leather jacket. 使用给的账号登陆My account登陆后发现只有$100.00 然后在查看皮夹克的详情 点击Add to cartBurpSuite抓取数据包 修改数据包然后Forward放包 放包后查看购物车提交订单 通关 3.1.2 前端JS 限制绕过
典型案例
绕过JS 限制购买多个打折商品
很多商品在限制用户购买数量时Web 应用仅在页面通过JS 脚本限制未在服务器端校验用户提交的数量通过抓取客户端发送的请求包修改JS 端生成处理的交易数据如将请求中的商品数量改为大于最大数限制的值查看能否以非正常业务交易数据完成业务流程。
该项测试主要针对电商平台由于交易限制机制不严谨、不完善而导致的一些业务逻辑问题。例如在促销活动中限制商品购买数量却未对数量进 行前、后端严格校验往往被攻击者所利用购买多个促销商品造成商家的损失。
3.1.3 请求重放测试
典型案例
一次购买多次收货
请求重放漏洞是电商平台业务逻辑漏洞中一种常见的由设计缺陷所引发的漏洞通常情况下所引发的安全问题表现在商品首次购买成功后参照订 购商品的正常流程请求进行完全模拟正常订购业务流程的重放操作可以实现“一次购买多次收货” 等违背正常业务逻辑的结果。
该项测试主要针对电商平台订购兑换业务流程中对每笔交易请求的唯一性判断缺乏有效机制的业务逻辑问题通过该项测试可以验证交易流程中随 机数、时间戳等生成机制是否正常。
3.1.4 业务上限测试
典型案例
无限制查询历史消费记录
业务上限测试主要是针对一些电商类应用程序在进行业务办理流程中服务端没有对用户提交的查询范围、订单数量、金额等数据进行严格校验而 引发的一些业务逻辑漏洞。通常情况下在业务流程中通过向服务端提交高于或低于预期的数据以校验服务端是否对所提交的数据做预期强校验。存在 此类脆弱性的应用程序通常表现为查询到超出预期的信息、订购或兑换超出预期范围的商品等。
该项测试主要判断应用程序是否对业务预期范围外的业务请求做出正确回应。
3.1.5 商品订购数量篡改
典型案例
damicms_5.4_网上商城任意商品购买
商品数量篡改测试是通过在业务流程中抓包修改订购商品数量等字段如将请求中的商品数量修改成任意非预期数额、负数等进行提交查看业务 系统能否以修改后的数量完成业务流程。
该项测试主要针对商品订购的过程中对异常交易数据处理缺乏风控机制而导致相关业务逻辑漏洞例如针对订购中的数量、价格等缺乏判断而产生 意外的结果往往被攻击者利用。
大米cms案例演示
来到首页之后先进行登陆
产品展示页面 打开BurpSuite提交订单
原始数据包 修改后数据包 点击Forward放包订单提前成功 显示订单已经付款 查看余额 再次 查看金额 3.2、密码找回安全
用户提交修改密码请求账号认证服务器发送唯一ID例如短信验证码只有账户所有者才能看的地方完成身份验证身份验证用户提交验证码完成身份验证修改密码用户修改密码
3.2.1、验证码客户端 回显测试
典型场景
任意用户登录
使用验证码的场景 人机验证防止机器操作爆破表单。 唯一凭据唯一性判断任意账户登录。
找回密码测试中要注意验证码是否会回显在响应中有些网站程序会选择将验证码回显在响应中来判断用户输入的验证码是否和响应中的验证码 一致如果一致就会通过校验。 3.2.2、验证码暴力破解
典型案例
验证码无使用次数限制
找回密码功能模块中通常会将用户凭证一般为验证码发送到用户自己才可以看到的手机号或者邮箱中只要用户不泄露自己的验证码就不会被 攻击者利用但是有些应用程序在验证码发送功能模块中验证码位数及复杂性较弱也没有对验证码使用次数做限制而导致验证码可被暴力枚举并修改 任意用户密码。
在测试验证码是否可以被暴力枚举时可以先将验证码多次发送给自己的账号观察验证码是否有规律如每次接收到的验证码为纯数字并且是4 位数。 3.2.3、Response状态码值修改测试
Response 状态值修改测试即修改请求的响应结果来达到密码重置的目的存在这种漏洞的网站或者手机App 往往因为校验不严格而导致了非常 危险的重置密码操作。
这种漏洞的利用方式通常是在服务端发送某个密码重置的凭证请求后出现特定的响应值比如
true1oksuccess200…
网站看到回显内容为特定值后即修改密码或者登陆通常这种漏洞的回显值校验是在客户端进行的所以只需要修改服务器的响应数据包即可 3.2.4、Session覆盖
Session ID 也叫会话ID服务器对浏览器客户端用户身份进行唯一性标志。
找回密码逻辑漏洞测试中也会遇到参数不可控的情况比如要修改的用户名或者绑定的手机号无法在提交参数时修改服务端通过读取当前 session 会话来判断要修改密码的账号这种情况下能否对session 中的内容做修改以达到任意密码重置的目的呢
在某网站中的找回密码功能中业务逻辑是由用户使用手机进行密码重置然后服务端向手机发送验证码短信用户输入验证码提交后进入密 码重置页面。
对网站中Session 覆盖的测试如下
打开浏览器访问重置密码页面并提交自己的手机号133同时浏览器接收Session ID用自己的账号手机号133接收凭证短信验证码获得凭证校验成功后进入密码重置页面在浏览器新标签重新打开找回密码页面输入目标手机号(177)此时服务器就会重新下发Session ID此时当前SessionID 已经被覆盖重新回到第三步中打开的重置密码页面即可重置目标手机号密码。
漏洞原因
在验证码校验之后没有及时更新Session ID或者没有及时更新服务器端SESSION 信息。SessionID 不仅要与手机号绑定还要与验证码绑定
3.2.5、弱Token设计缺陷测试
在找回密码功能中很多网站会向用户邮箱发送找回密码页面链接。用户只需要进入邮箱打开找回密码邮件中的链接就可以进入密码重置页面 了。找回密码的链接通常会加入校验参数来确认链接的有效性通过校验参数的值与数据库生成的值是否一致来判断当前找回密码的链接是否有效
http://www.xxx.com/findpwd?uidjaychoutokenjaychou-2018-0906-1314上面这串链接能看出token是由uid-年-月日-数字组成这样的设计很不安全
在线靶场演示介绍
login_user 点击Forgot your password?会给邮箱发送链接 链接如下
https://portswigger.net/users/retrieve-password-td449832696b5dsf88526a5166bb8992br73s92f8fdcdm8f8n86f822aj8fb7183?tid7zfPWC7QrC9YwJTXeaE8prvdj5zg-s1J6EVB-_6_BNUM0i2UMRutfw3b455sipX2看不出链接的组成看不出链接的规律
3.2.6 密码找回流程绕过测试
很多网站的密码找回功能一般有以下几个步骤
用户输入找回密码的账号校验凭证向用户发送短信验证码或者找回密码链接用户回填验证码或单击链接进入密码重置页面 以此方式证明当前操作用户是账号主人校验成功进入重置密码页面接口
在找回密码逻辑中第二步校验凭证最为重要。不是账号主人是无法收到校验凭证的试想有没有办法可以绕过第二步凭证校验直接进入第三步 重置密码呢
用户修改密码需要向服务器发送修改密码请求服务器通过后再修改数据库中相应的密码所以在测试中我们首先要收集三个步骤的请求接口重 点是收集到最后一步重置密码的接口这样我们可以直接跳过凭证校验的接口去尝试直接重置密码
3.2.7 接⼝参数账号修改
典型案例
metinfo_4.0 任意账号密码重置
找回密码功能逻辑中常常会在用户修改密码的接口提交的参数中存在传递用户账号的参数而用户账号参数作为一个可控变量是可以被篡改的从 而导致修改账号密码的凭证或修改的目标账号出现偏差最终造成任意账号密码修改的漏洞。
通常在找回密码逻辑中服务端会要求用户提供要修改的账号然后给这个账号发送只有账号主人才能看到的凭证。比如给这个账号主人绑定的邮 箱或者手机号发送验证码或者找回密码链接这样可以保证只有账号主人才可以看到这些凭证。但是如果服务器对账号的控制逻辑不当就会导致原 有账号被篡改为其他账号服务器端把凭证发送给篡改后的账号的邮箱或手机最终造成可利用凭证重置任意账号密码的漏洞。
接口参数账号修改流程测试为拦截前端请求通过修改请求内的账号ID 、名称或者邮箱、手机号等参数将修改后的数据发送给服务器进行欺骗 达到密码重置的目的。
metinfo_4.0 任意账号密码重置案例演示
下载地址
下载完环境部署
在虚拟机里访问来到登陆界面/admin/login/login.php
使用BurpSuite拦截请求的数据包
登陆后来都首页底部点击会员中心 填写基本信息后点击·提交信息
然后在来到来到登陆界面/admin/login/login.php
使用原来的密码登陆发现登陆不上了 分析数据包
第一次登陆的数据包 修改密码的数据包 使用原密码的登陆的数据包 提示密码错误说明用户名是正确存在的
假如说这里用的 其他用户登陆而不是admin账户登陆那么就可以对修改密码的数据包进行修改把userid换成admin
那么就把管理员的密码给改了
