07逻辑漏洞-课件.ppt

商业逻辑漏洞攻击 未来分析： 据统计，这些商业逻辑攻击在恶意攻击流量中占到 14%。 黑客可以利用应用程序截获私人信息，进行扭曲，并外泄给其他更多的用户，而这些行为通常不受安全控制。 一旦商业逻辑攻击(BLA)与高级可持性(APT)类攻击相结合，所爆发出来的网络商战威力将不容小视。 逻辑漏洞攻击防御 逻辑漏洞攻击防御概述 鉴于逻辑漏洞的本质，即使实施安全开发标准、使用代码审查工具或常规渗透测试，我们仍然无法避免这种缺陷。逻辑漏洞的多样性特点使得探查与防止他们往往需要从各个不同的角度思考问题，这预示着在很长一段时期内，逻辑缺陷仍将大量存在。 基于开发流程及设计的预防 基于网络行为识别的防御 基于开发流程及设计的预防 遵循以下最佳实践可以显著降低在应用程序中出现逻辑缺陷的风险： 确保将应用程序中各个方面的设计信息清楚、详细的记录在文档中，以方便其他人员了解设计者做出的每个假设。 要求所有源代码提供清楚的注释，包含但不限于以下内容： 每个代码组件的用户和预计用法。 每个组件对它无法直接控制内容做出的假设。 清楚记录所有调用组件的代码效果。 基于开发流程及设计的预防 在以安全为中心的应用程序设计审核中，考虑在设计中做出的每一个假设，并想象假设被违背的每种情况。 在以安全为中心的代码审查过程中，从各个角度考虑一下两个因素： 应用程序如何处理用户的反常行为和输入。 不同代码组件与应用程序功能之间相互依赖、相互操作可能造成的不利影响。 逻辑漏洞挖掘之测试客户端数据传输 总结，实际分析中可参考以下基本步骤： 在应用程序中，确认隐藏表单字段、cookie和URL参数明显用于客户端传送可控数据的所有情况。 根据以上数据出现的位置极其名称与值，尝试确定其在应用程序逻辑中发挥的作用。 修改在应用程序相关功能中的值，确定应用程序是否处理字段中提交的任意值，并确定这样做是否可以干扰其正常逻辑。 如果应用程序通过客户端传输模糊数据，我们依然可以使用各种方式攻击它。如：如果模糊处理，则可以尝试破解算法，提交任意数据。如果采用安全加密，则可使用其他加密块替换提交以攻击程序逻辑。 逻辑漏洞挖掘之测试客户端组件逻辑 逻辑漏洞挖掘之测试客户端组件逻辑 客户端组件及控件也是一种收集、确认并提交用户数据的主要方法。 由于速度和用户体验方面的原因，之前在服务器端处理的任务将在客户端执行，这将有意无意的增加客户端的风险。 开发者假设操作的用户都是可信任的或者浏览器扩展会自行防御恶意企图。 由于相对HTML表单和JavaScript确认机制，控件方式更加不透明，这也使得开发者认为控件的确认更加安全。 逻辑漏洞挖掘之测试客户端组件逻辑 举例： 功能：购物网站一般都有购物车功能，这些功能大多是由控件实现，同时控件中会加载一些购物策略，eg：购物满多少可以打几折等，通过分析我们也许可以直接获得低折扣的商品价格。同时在结算页面确认时还可以选择商品数量及退订商品。 假设：当购物车的商品满1000元的时候，可以享受8折优惠，当满2000元的时候可以享受7折优惠，同时在提交结算页面时计算最终折扣。 逻辑漏洞挖掘之测试客户端组件逻辑 攻击：以上假设没有考虑到购物者放入商品后结算确认时再修改商品的情况，因此购物者可以将大量商品放入购物车以获得最优折扣，在结算确认页面再将部分商品退掉或修改商品数量，这样就可以获得最优的折扣。 以上的例子举的比较浅显，实际的控件功能逻辑更加复杂，同时数据可能会采取模糊或者加密处理，因此实际的分析中应当更加严谨。 逻辑漏洞挖掘之测试客户端组件逻辑 总结，实际分析中可参考以下基本步骤： 使用代理工具对客户端和服务器端的流量进行监视。如果发现数据被序列化，则可以使用某种反序列化工具或插件。 浏览控件在客户端的所有功能，并使用代理修改关键请求或者服务器响应，以确认任何可以改变数据逻辑的功能。 反编译客户端控件，分析相关代码，确认其中的输入限制及其他逻辑方式。 逻辑漏洞挖掘之测试客户端组件逻辑 附加调试器，查找监视关于安全及业务逻辑的功能和值，并设置断点，修改参数或返回值，尝试逻辑攻击。 借助客户端组件或控件的调用代码，执行有目的的数据调用及输入或者进行模糊输入测试，并监控处理结果。 尝试发现各种隐藏的功能、参数或资源，通过开启功能或调用资源等获得服务器资源。 尝试通过组件功能获得其他相关信息（eg：对手信息、预发布信息等）。 逻辑漏洞挖掘之测试多阶段过程逻辑 逻辑漏洞挖掘之测试多阶段过程逻辑 应用程序的最终提交需要经过多个阶段的信息获取及确认（eg：找回密码、订单提交）。 针对这类功能，开发人员默认前一阶段提交过来的数据是可信的，这种假设也就造成了大量的多阶过程逻辑漏洞。 举例： 功能：一般的网上购物流程如下： 浏览商品并添加到购物车 确认订单 输入支付