深信服应用层安全培训-Web渗透测试系列-X-逻辑攻击课件.pptx

1、Web渗透测试系列_逻辑攻击1.逻辑缺陷概述2.逻辑攻击框架3.应用程序解析4.逻辑攻击测试5.商业逻辑攻击6.逻辑攻击防御7.逻辑探测工具8.总结培训提纲逻辑缺陷概述逻辑缺陷概述逻辑缺陷的出现 所有的应用程序都通过逻辑实现各种功能。而编程实际上就是将这些功能分解成独立、简单的逻辑单元，并用代码结构表示。 大量的逻辑操作加上不同背景的开发人员，增加了逻辑缺陷出现的概率。逻辑缺陷的本质 主要源于设计者或者开发者在思考过程中做出的特殊假设存在明显或隐含的错误。逻辑缺陷概述逻辑缺陷的特点 普遍存在性：由于功能的实现需要大量的逻辑操作，同时受制于程序员的背景，这类缺陷普遍存在于各类应用程序中。 不固定

2、性：或者称作“十分有针对性”，因为每一种逻辑缺陷似乎都是唯一的，它是基于逻辑操作，不同的功能逻辑不同，因此无法用一般的工具发现他们。 隐蔽性：大多数的逻辑漏洞都十分隐蔽，它存在于操作关系当中，甚至是属于应用程序正常的功能逻辑攻击框架逻辑攻击框架图应用程序解析概述攻击一个应用程序，首先要分析这个应用程序，了解清楚了其本身的功能、行为以及使用的技术，有针对性的攻击，那么成功的机会就变大了。下面就有从逻辑攻击的角度说明应用程序分析中应该考虑的方面。应用程序分析确定应用程序功能确定数据的进入点确定所使用的技术确定应用程序功能大多数情况下，应用程序的功能我们可以通过web浏览的方式获得，其基本方法就是从

3、主页面开始，然后每个链接及多阶页面遍历。确定应用程序功能实际分析中可参考以下基本步骤： 确定为使程序正常运行而建立的核心功能及每项功能的操作； 确定应用程序采用的核心安全机制及他们的工作原理。重点了解处理身份认证、会话管理与访问控制的关键机制以及支持他们的功能，如用户注册和账户恢复； 确定所有较外围的功能和行为，如重定向的使用、站外链接、错误消息、管理日志功能等； 确定任何与应用程序在其他方面使用的标准GUI外观、参数命名或导航机制不一致的功能，然后将其挑选出来以进行深入测试；确定数据的进入点通过HTTP请求过程中的参数获得大部分的数据输入点通过对输入点的分析确定数据处理的逻辑过程，从而确定数

4、据进入点确定数据的进入点实际分析中可参考以下基本步骤： 确定在应用程序中引入用户输入的所有进入点，包括URL、查询字符串参数、POST数据、cookie以及其他由应用程序处理的HTTP消息头； 分析应用程序使用的所有定制数据传输或编码机制，如，非常规的查询字符串格式。了解被提交的数据是否包含参数名及参数值，或者是否使用了其他表示方法； 确定所有在应用程序中引入用户可控制或其他第三方数据的带外通道，eg，处理和显示通过SMTP收到的消息的Web邮件应用程序；确定所使用的技术通常，我们可以通过很多线索和指标确定应用程序所采用的技术。通过以上的内容我们可以初步判断，服务器支持PHP技术，同时由目录可

5、以判断对端是Wordpress平台的典型应用，同时可以知道后端很大概率有Mysql数据库。确定所使用的技术实际分析中可参考以下基本步骤： 确定客户端技术，如表单、脚本、cookie、Java applet、ActiveX控件与Flash对象； 确定服务器端技术，包括脚本语言、应用程序平台、数据库及电子邮件系统等后端组件的交互； 检查应用程序响应中的HTTP Server消息头。 运行扫描工具对服务器做“指纹识别”； 分析所有获得信息，包括文件扩展名、目录或 前台URL序列。检查所有会话令牌和其他cookie名称等； 获取分析第三方代码组件的脚本、参数及行为等，发现应用程序隐藏的内容和功能；逻辑

6、攻击测试概述测试客户端数据传输测试客户端输入验证测试客户端组件逻辑测试多阶段过程逻辑测试不完整输入处理测试信任边界测试业务逻辑测试客户端数据传输应用程序通常以终端用户无法查看或修改的方式向服务器传送数据。通常开发者认为所采用的传输机制将保证传输过程中数据不被修改。一般通过客户端传送数据的方式有隐藏表单字段、HTTP cookie、URL 参数、Referer消息头、模糊数据、ASP.NET ViewState 等。测试客户端数据传输举例： 功能：当前有一个用户登录系统，登录成功后会显示用户欢迎，用户名等信息以POST方式提交： 假设：开发者假设用户数据传输过程中是安全的。测试客户端数据传输 攻

7、击：如果我们使用Burp Suite Proxy拦截传输过程中请求：测试客户端数据传输 修改用户名和密码后forward，查看结果：测试客户端数据传输实际分析中可参考以下基本步骤： 在应用程序中，确认隐藏表单字段、cookie和URL参数明显用于客户端传送数据的所有情况； 根据以上数据出现的位置极其名称与值，尝试确定其在应用程序逻辑中发挥的作用； 修改数据在应用程序相关功能中的值，确定应用程序是否处理字段中提交的任意值，并确定这样做是否可以干扰其正常逻辑； 如果应用程序通过客户端传输模糊数据，我们依然可以使用各种方式攻击它。Eg：如果模糊处理，则可以尝试破解算法，提交任意数据。如果采用安全加密

8、，则可使用其他加密块替换提交以攻击程序逻辑；测试客户端输入验证在客户端输入上，常采用的手段是HTML表单、客户端脚本以及一些禁用元素等。这些方法的使用假设为：用户的输入经过了客户端的限制，从而可以保证数据的合法性。测试客户端输入验证举例： 功能：页面输入字段为防止各类攻击（eg：SQL注入），采用了单引号转义，将两个单引号构成一个原义单引号，同时限制了输入长度为128字符。 假设：对于攻击的防御采用转义，则攻击者无法实现单引号的输入攻击。 攻击：考虑以下情况，如果经过应用程序单引号转义后的字符串，提交给了截断功能，那么是否可以绕过限制。测试客户端输入验证 如果我们考虑用户名修改为：adminn

9、nnnnn 127个字符 由于先做转义再截断，则输入数据依然是 adminnnnnnn 127个字符 配合password字段输入 or 1=1- - ，则查询语句变成： SELECT * FROM users WHERE name= adminnnnnnn127个字符 and password= or 1=1- - 由于在数据库中连个单引号作为转义，所以会被当做数据而非结构，则数据库实际查询的用户名为：adminnnnnnn 127个字符 and password= 因此我们可以构造 or 1=1 - -部分，实现注入查询。测试客户端输入验证实际分析中可参考以下基本步骤： 在用户输入提交给服

10、务器之前，确定使用长度限制和JavaScript检查等方式进行的数据输入检查； 通过提交客户端限制的输入，轮流测试每一个受影响的字段，确定服务器是否使用相同的输入确认； 检查确认HTML表单禁用元素，修改其数据，与其他表单一起提交，以确定该元素是否会对应用程的逻辑产生影响； 删除或修改客户端脚本，确定服务器是否只依赖客户端的检查； 利用客户端本身的功能，eg：转义、长度限制等进行避开输入改变程序逻辑；测试客户端组件逻辑客户端组件及控件也是一种收集、确认并提交用户数据的主要方法由于速度和用户体验方面的原因，之前在服务器端处理的任务将在客户端执行，这将有意无意的增加客户端的风险开发者假设操作的用户

11、都是可信任的或者浏览器扩展会自行防御恶意企图由于相对HTML表单和JavaScript确认机制，控件方式更加不透明，这也使得开发者认为控件的确认更加难以避免测试客户端组件逻辑举例： 功能：购物网站一般都有购物车功能，这些功能大多是由控件实现，同时控件中会加载一些购物策略，eg：购物满多少可以打几折等，通过分析我们也许可以直接获得低折扣的商品价格。同时在结算页面确认时还可以选择商品数量及退订商品。 假设：当购物车的商品满1000元的时候，可以享受8折优惠，当满2000元的时候可以享受7折优惠，同时在提交结算页面时计算最终折扣。测试客户端组件逻辑 攻击：以上假设没有考虑到购物者放入商品后结算确认时

12、再修改商品的情况，因此购物者可以将大量商品放入购物车以获得最优折扣，在结算确认页面再将部分商品退掉或修改商品数量，这样就可以获得最优的折扣。 以上的例子举的比较浅显，实际的控件功能逻辑更加复杂，同时数据可能会采取模糊或者加密处理，因此实际的分析中应当更加严谨。测试客户端组件逻辑实际分析中可参考以下基本步骤： 使用代理工具对客户端和服务器端的流量进行监视。如果发现数据被序列化，则可以使用某种去序列化工具或插件； 浏览控件在客户端的所有功能，并使用代理修改关键请求或者服务器响应，以确认任何可以改变数据逻辑的功能； 反编译客户端控件，分析相关代码，确认其中的输入限制及其他逻辑方式；测试客户端组件逻辑

13、 附加调试器，查找监视关于安全及业务逻辑的功能和值，并设置断点，修改参数或返回值，尝试逻辑攻击； 借助客户端组件或控件的调用代码，执行有目的的数据调用及输入或者进行模糊输入测试，并监控处理结果； 尝试发现各种隐藏的功能、参数或资源，通过开启功能或调用资源等获得服务器资源； 尝试通过组件功能获得其他相关信息（eg：对手信息、预发布信息等）；测试多阶段过程逻辑应用程序的最终提交需要经过过个阶段的信息获取及确认（eg：找回密码功能）针对这类功能，开发人员默认前一阶段提交过来的数据是可信的，这种假设也就造成了大量的多阶过程逻辑漏洞举例： 功能：一般的网上购物流程如下 浏览商品并添加到购物车 确认订单

14、输入支付信息 输入交货信息测试多阶段过程逻辑 假设：开发者会认为用户总会按照预定的顺序执行每一个步骤，因为这是应用程序通过显示在浏览器中的导航链接和表单向用户提供的处理顺序。因此，开发者认为任何完成订购过程的用户一定已经提交了正确的支付信息。 攻击：这里开发者的假设存在明显的缺陷，用户控制着他们向应用程提出的每一个请求，因此能够以任何顺序访问订购过程的每一个阶段。如果直接从步骤 2进入步骤 4，攻击者就可以生成一个最终确定交货但实际并未支付的订单。以上的攻击方法叫做强制浏览，包括突破浏览器导航对应用程序功能访问顺序实施的任何限制测试多阶段过程逻辑实际分析中可参考以下基本步骤： 如果一个多阶过程

15、需要按照预定的顺序提交一系列请求，尝试按其他顺序提交这些请求。尝试完全省略某个阶段，几次访问同一个阶段，或者推后访问前一个阶段； 确保应用程序访问不同阶段所使用的机制。这些阶段可能通过一系列指向特殊URL的GET或POST请求进行访问，或者向同一个URL提交不同的参数。被访问的阶段可以通过提交的参数中指定名称或索引来确定；测试多阶段过程逻辑 尝试提取某一阶段的参数，并在另一个阶段中提交这些参数。如果相关数据被应用程序更新，应当确定是否可以利用这种行为破坏应用程序的逻辑； 根据执行功能的情形，了解开发者做出的假设及主要攻击面的位置。设法找到违反这些假设以在应用程序造成反常行为的方法； 如果应用程

16、序表现出一系列异常现象，eg：提示错误、变量未赋值或初始化等。寻找有用的错误消息及调试结果，可以通过他们进一步了解该功能的内部机制，从而调整攻击方向和方法；测试不完整输入处理客户端完成对用户输入的收集及确认，必要时会对数据进行计算或简单的功能处理，部分情况下应用程序的处理过程和某些数据是否输入有关，eg：不勾选发票项，则不走发票流程。这些功能的处理是本着用户并不知情关键数据对功能具体影响的前提假设（客户端对用户屏蔽处理机制），这也会引入大量安全问题。测试不完整输入处理举例： 功能：应用程序为用户提供密码修改功能。它要求用户填写用户名、当前密码、新密码以及新密码确认。同时应用程还为管理员提供密码

17、修改功能，它允许管理员修改任何用户的密码，而不需要提供用户当前密码。这两个功能在同一个服务器端脚本中执行。测试不完整输入处理 假设：应用程序为用户和管理员提供的界面仅有一点不同：在管理员界面中没有用于填写现有密码的字段。而后端采用的是同一个脚本。它通过请求中是否包含当前密码来确认请求是来自用户还是管理员。 攻击：一旦确定了假设，攻击就变得十分容易。普通用户可以通过提交不包含现有密码的请求修改任何用户的密码，从而完全控制用户账户。测试不完整输入处理实际分析中可参考以下基本步骤： 轮流测试每一个参数，从请求中删除参数的名称或值，监控应用程序的响应，查找所有行为异常或错误消息，以获得和应用程序逻辑有

18、关的信息； 一次仅攻击一个参数，确保达到应用程序中所有与参数相关的代码路径； 如果所操纵的请求属于一个多阶过程，应测试整个过程。因为应用程序可能将前一个阶段的数据保存在会话中，然后在后一个阶段处理；测试信任边界信任边界指在什么地方更改信任级别，大部分情况下表现为访问控制权限的更改。应用程序对信任边界的状态转换处理往往存在着看似安全的假设，因此分析清楚应用程序的信任边界将有助于发现此类逻辑缺陷。举例： 功能：应用程序使用一种安全、多阶的登录机制，要求用户提供多个不同的证书才能获得访问权限。测试信任边界 假设：应用程序在实现登录认证的过程中将通过验证用户的有关标示符临时保存在一个静态（非会话）变量

19、中，然后执行其他“准备”工作，之后应用程序再读取这个变量的值。由于这个间隔时间十分短暂，因此开发者认为是安全的。 攻击：如果出现这样一种情况：用户集中登录，这个时候就会出现，变量改写后，又被另一个登录用户改写，因此当前一个用户回来取变量值的时候，用户分配到的就是后一个登录者的会话，同时获得后者的访问权限。测试信任边界实际分析中可参考以下基本步骤： 了解应用程如何处理不同用户信任状态之间的转换； 通过在一个区域积累相关状态，在信任边界之间进行不恰当的转换，然后以正常不被允许的方式切换到另一个区域； 确定是否可以利用更高权限的功能直接或间接访问或者猜测某些信息；测试业务逻辑业务逻辑攻击，其特点是利

20、用正常的、合法的业务流程进行攻击，而非破坏逻辑 举例： 功能：用户登录为防止自动化登录攻击而设定了锁定次数，当正常登录错误达到一定次数后则封锁该用户一段时间。 假设：此功能的假设是防止恶意登录攻击，从而保护用户账户安全。测试业务逻辑 攻击：我们考虑另一种情况，假设某电商网站做活动，进行某件商品的竞拍，出价最高者获得此商品。如果在接近竞拍结束的时候，竞争对手的价格比自己高，而再次出价竞争对手也可能加价，这种情况下我们就可以利用业务逻辑攻击，故意使用错误的密码登陆对手账户另其锁定，无法再次出价，从而顺利的获得该商品。测试业务逻辑实际分析中可参考以下基本步骤： 分析应用程的正常逻辑、目的以及使用场景

21、； 尽量将其应用场景进行扩展，并结合具体业务内容进行分析； 分析是否可以使用一连串的交易达到一种状态，从而完成预期目的（eg：多次低额转账代替单次大额转账）； 如果应用程序根据用户控制的数据或操作确定处理方式或其他敏感内容，应首先分析应用程序使用的算法及需要调整的逻辑； 努力想办法操纵应用程序的行为，使应用程序进行的调整与开发者最初设定的标准相矛盾；商业逻辑攻击概述当前应用逻辑攻击发展出来的一种新型攻击方式称之为 BLA，即 Business Logic Attacks(商业逻辑攻击)的缩写，这是由世界著名数据安全公司 Imperva 在 2011 年 6 月至 11月期间所发现的一种新型网络

22、攻击方式(详情参阅黑客发现攻击新手段关注业务逻辑攻击)，而这种攻击很可能将成为未来互联网世界里商战的雏形。商业逻辑攻击攻击分析攻击分类攻击目的攻击手段实际案例未来分析商业逻辑攻击攻击分析 这种攻击不同于传统攻击方式，它一般不以破坏程序或数据为手段，而大多使用正常操作的方式，达到收集用户信息，获得商业情报，控制商业进程等目的，因此比较难区分。 不管是网络行为还是攻击过程都比较隐蔽，部分攻击往往在用户不知情的情况下进行，即使用户受到攻击也无法察觉，同时一旦成功影响比较大。商业逻辑攻击攻击分类 现在有两类商业逻辑攻击比较流行：电子邮件提取和垃圾评论。 未来还会出现以操纵商业进程为目的的攻击手段，这类

23、攻击一旦发展起来，将对互联网商业造成巨大的威胁。攻击目的 电子邮件提取：建立垃圾邮件发送列表。 垃圾评论：一方面导入流量，使得其获益的网站在搜索引擎的排名靠前，一方面让搜索引擎更多搜到获益网站，从而潜在诈骗消费者。商业逻辑攻击攻击手段 电子邮件提取：通过电子邮件地址抽取实现的攻击，它模拟真实用户访问客户网站(论坛、博客、社交网络)，对客户 Web 网站中的电子邮件地址进行简单抽取和分类，而这一系列动作与正常用户访问几乎完全一样，很难辨识出其真实目的。 垃圾评论：攻击者会在某些排名靠前的论坛注册，发表、回复某些言论，内嵌恶意链接地址来改变搜索引擎结果。为了让所发帖子处于显著位置被更多网友看到，恶

24、意攻击者会发起投票，或想办法设置成置顶帖。商业逻辑攻击实际案例在2006年，一家移动运营商（假设叫 FlawedP）为其客户增加了一项webmail+SMS的服务，开通和使用流程如下： 新客户可以凭 SIM 卡开通一个以 FlawedP 为域名的免费、永久 email账户； 这个 email 账户在用户 SIM 卡转到其他运营商时仍会保留； 由于 SIM卡注册到了 FlawedPhone ，所以每次收到 email 邮件，FlawedPhone都会给客户发送一条 SMS，内容包括发件人和邮件主题； 同时 SMS 程序会每 8 个小时检查一下当前合法用户列表；商业逻辑攻击攻击步骤： 攻击者买一张

25、新的 FlawedPhone SIM 卡； 攻击者马上将卡转到另一个运行商，这个运营商会在客户每收到一条SMS信息时支付给客户 0.05 欧元； 一旦转卡完成，攻击者就会向 FlawedPhone 的 email 账户发送数以千计的邮件； 在 email+SMS 应用程序检查并更新合法用户列表前，攻击者最多拥有8个小时的空档； 到发送截止时，攻击者的账户上大约已经有 50-100 欧元了，然后这个SIM卡就可以放到 eBay上出售了；商业逻辑攻击未来分析 据统计，这些商业逻辑攻击在恶意攻击流量中占到 14% 黑客可以利用应用程序截获私人信息，进行扭曲，并外泄给其他更多的用户，而这些行为通常不受

26、安全控制 一旦商业逻辑攻击(BLA)与高级可持性(APT)类攻击相结合，所爆发出来的网络商战威力将不容小视逻辑攻击防御概述鉴于逻辑缺陷的本质，即使实施安全开发标准、使用代码审查工具或常规渗透测试，我们仍然无法避免这种缺陷。逻辑漏洞的多样性特点使得探查与防止他们往往需要从各个不同的角度思考问题，这预示着在很长一段时期内，逻辑缺陷仍将大量存在。基于开发流程及设计的预防基于网络行为识别的防御基于开发流程及设计的预防遵循以下最佳实践可以显著降低在应用程序中出现逻辑缺陷的风险： 确保将应用程序中各个方面的设计信息清楚、详细的记录在文档中，以方便其他人员了解设计者做出的每个假设； 要求所有源代码提供清楚的

27、注释，包含但不限于以下内容： 每个代码组件的用户和预计用法； 每个组件对它无法直接控制内容做出的假设； 清楚记录所有调用组件的代码效果；基于开发流程及设计的预防 在以安全为中心的应用程序设计审核中，考虑在设计中做出的每一个假设，并想象假设被违背的每种情况。 在以安全为中心的代码审查过程中，从各个角度考虑一下两个因素： 应用程序如何处理用户的反常行为和输入； 不同代码组件与应用程序功能之间相互依赖、相互操作可能造成的不利影响；基于网络行为识别的防御虽然这种防御存在一定的精确性，但可以弥补应用程序开发过程中遗漏或忽视的安全问题。 信誉机制的监测：获得并使用信任来源的主机IP黑名单； 高点击率：流量

28、整形是自动化攻击最基本的指示。一旦超过与其相关的临界值(例如，每分钟点击3次)，应用程序就应该延迟或阻止与应用客户端信息交换； 访问流量的技术属性：软件工具产生的流量通常具有技术特征(例如特定的HTTP头)，不同于一般浏览器所产生的流量。如果这不是预期的使用场景，阻止该流量；基于网络行为识别的防御 攻击流量的地理信息对即时做出数据安全对策有所帮助。例如，经分析的业务逻辑攻击拥有独特的地理特征； 商业行为的重复：例如，多次登陆失败表明密码受到恶意攻击。当然，你的Web应用安全设备必须能够识别出这些“差异或者异常的表现”； 质疑应用程序的网络客户端：测试你的应用程序是否真的与浏览器进行交互。例如“

29、虚假”浏览器没有对Java语言的执行能力； 检测确有真人在操作：通过CAPTCHA(全自动区分计算机和人类的图灵测试)检测终端用户是否是真人；逻辑探测工具逻辑探测工具Burp SuiteFirebug逆向及调试工具Burp SuiteBurp Suite 具有 HTTP 协议分析的多个组合套件，在实际的分析过程中灵活应用，将会给分析工作带来极大的便利。FirebugFirebug 是一款跨平台的浏览器插件，提供灵活的 Web页面分析方式，支持各种形式展现源代码，同时可直接修改或添加、删除脚本提交服务器，对输入验证及本地组件调试帮助极大。逆向及调试工具对应用程序的分析中，组件及控件的分析有时候需要进行逆向或附加调试，以获得应用程序的调用过程和功能逻辑。针对不同的编程语言及控件技术有不同的调试方法，由于这里不是重点，暂不做工具推荐。总结总结介绍了逻辑缺陷出现的原因、本质以及特点介绍了逻辑缺陷的测试框架介绍了逻辑缺陷的分类及具体分析方法，并举例加深理解介绍了逻辑攻击的防御方法介绍了逻辑探测的常用工具