目录
攻击访问控制
简介：
1、应用程序核心安全机制的访问控制建立在验证和会话管理之上。应用程序如何首先核实用户的身份， 然后确认它收到的某个特殊的请求序列由该用户提出。应用程序之所以需要这样做， 至少从安全上讲， 是因为它必须决定是否允许某个请求执行特定的操作或访问它请求的资源。访问控制是应用程序的一个重要防御机制， 因为它们负责做出这些关键决定。如果访问控制存在缺陷， 攻击者往往能够攻破整个应用程序， 控制其管理功能并访问属于其他用户的敏感数据
2、不完善的访问控制中最常见的Web应用程序漏洞，发现应用程序做出一切努力执行稳定的验证与会话管理机制， 但由于没有在它们上面建立任何有效的访问控制，这种情况非常常见。这些漏洞如此普遍的一个原因在于， 需要对每一个请求， 以及特殊用户在特定时刻尝试对资源执行的每一项操作执行访问控制检查。且与许多其他类型的控制不同， 这一设计决策需要由人做出， 而无法采用技术来解决。
3、访问控制漏洞的概念非常简单：应用程序允许攻击者执行他没有资格执行的操作。各种漏洞之间的差异实际上可归结为这些核心漏洞表现方式上的不同， 以及检测它们所需要使用的技巧之间的差异。
1.1、常见漏洞
简述：
1、访问控制可分为三大类：垂直访问控制、水平访问控制和上下文相关的访问控制。
垂直访问控制：允许各种类型的用户访问应用程序的不同功能。在最简单的情况下， 应用程序通过这种控制界定普通用户和管理员。在更加复杂的情况下，垂直访问控制可能需要界定允许其访问特殊功能的各种不同类型的用户， 给每个用户分配一个单独的角色， 或一组不同的角色。
水平访问控制：允许用户访问一组相同类型的、内容极其广泛的资源。如Web邮件应用程序允许访问自己而非他人的电子邮件，电子银行允许转移自己账户内的资金， 工作流程应用程序允许更新分配给你的任务， 但只能阅读分配给他人的任务。
上下文相关的访问控制：可确保基于应用程序当前的状态， 将用户访问权限于所允许的内容。例如， 如果在某个过程中， 用户需要完成多个阶段的操作， 上下文相关的访问控制可以防止用户不按规定的顺序访问这些阶段。
2、一般垂直与水平访问控制相互交叠。如企业资源规划应用程序允许每个应付账会计文员支付某一个组织单元、而非其他单元的发票,但允许应付账经理支付任何单元的发票。且会计文员只能支付小额发票， 而大额支票必须由经理支付。财务总监可以查看公司每个组织单元的发票支付和收据， 但不得支付任何发票。
如果用户能够访问他无权访问的功能或资源， 就表示访问控制存在缺陷。主要有三种类型的以访问控制为目标的攻击，分别与三种访问控制相对应
A、如果一名用户能够执行某项功能， 但分配给他的角色并不具有这种权限． 就表示出现垂直权限提升漏洞。如果一名普通用户能够执行管理功能， 或者一位会计文员能够支付任何金额的发票， 就表示访问控制井不完善
B、如果一名用户能够查看或修改他没有资格查看或修改的资源， 就表示出现水平权限提升漏洞。如果用户能使用Web邮件应用程序阅读他人的电子邮件，或者如果一位会计文员可以处理自己所属组织单元以外的单元的发栗，那么访问控制也不完善。
C、如果用户可以利用应用程序状态机中的漏洞获得关键资源的访问权限，就表示出现业务逻辑漏洞。如用户能够进入购物结算序列中的支付步骤
3、应用程序水平权限划分中存在的漏洞可能会引起垂直权限提升攻击。如果一名用户能够以某种方式设登其他用户的密码，那么该用户就能攻击管理员的账户并控制整个应用程序。
4、上述中， 不完善的访问控制使获得某种用户权限的攻击者能够执行未授权操作或访问未授权数据。在最严重的情况下，不完善的访问控制可能允许完全未获授权的用户访问只有特权用户才能访问的功能或数据
1.2、完全不受保护的功能
简述：
1、在许多的访问控制不完善情况下， 敏感功能和数据可被任何知道相关URL的用户访问。例如，在许多应用程序中，任何人只需访问一个特定的URL就能够完全控制它的管理功能（https://xxxx.com/admin）
2、应用程序通常仅实施如下访问控制：以管理员身份登录的用户在他们的用户界面上看到一个该URL的链接， 而其他用户则无法看到这个链接。这种细微的差别是应用程序用于防止敏感功能被未授权使用的唯一机制。
3、允许用户访问强大功能的URL可能很难猜测， 甚至可能相当隐秘，假设攻击者无法知道或发现这个URL，管理功能就会因此受到保护。局外人很难攻破一个应用程序， 因为不太可能猜测出实现这种目的的URL
4、一些应用程序的敏感功能隐藏在各种不太容易猜测的URL之后， 但攻击者通过仔细检查客户端代码仍能发现这些URL。许多应用程序使用JavaScript在客户端动态建立用户界面。它一般建立各种与用户状态有关的标记， 然后根据这些标记在用户界面(UI)中增加不同的元素。攻击者只需检查JavaScript代码就可确定具备管理功能的URL，并尝试访问它们。在其他情况下． HTML注释中可能包含屏幕显示内容中没有链接的URL的引用或线索。
直接访问方法
1、如果应用程序披露实际用于远程调用API方法的URL或参数（通常由Java界面披露），可能出现功能不受保护的特例。在将服务器端代码移至浏览器扩展组件，并创建方法存根以便代码仍然能够调用它正常运行所需的服务器端方法时，往往会发生这种特例。除以上外，如果URL或参数使用getBalance和sExpired等标准Java命名约定，也可能会出现直接调用方法的情况。
2、与指定服务器端脚本或其他资源的请求相比， 并不需要完全确保指定要执行的服务器端API的请求的安全。但这种机制往往包含漏洞，客户端直接与服务器端API方法交互，并避开应用程序的正常访问控制或意外输入向量。如果其他功能从不由Web应用程序客户端直接调用， 则这些功能也可以通过上述方法调用，并不受任何控制的保护。一般用户只需要能够访问某些特定的方法，但他们却拥有访问所有方法的权限。原因在于开发者并不了解用户到底需要哪些方法，而向他们提供所有方法的访问权限，或是将用户映射到HTTP服务器的API默认提供访问所有方法的权限
从接口securityCheck中词用getCurrentUserRoles方法：public/securityCheck/getCurrentUserRoles
（还应检查是否存在其他类似命名的方法）
1.3、基于标识符的功能
简述：
1、当应用程序使用一项功能访问某个特殊的资源时， 被请求资源的标识符常常以请求参数的形式在URL查询字符串或POST请求主体中提交给服务器。例如， 应用程序可能使用URL显示一份属于某个用户的特殊文档（https://xxx.com/ViewDocument.php?docid=73453）
2、拥有这份文档的用户登录后， 这个URL的链接将会在该用户的"我的文档"页面显示。其他用户无法看到这个链接。但如果访问控制不完善， 那么请求相应URL的任何用户都能够像授权用户那样查看这份文档
当主应用程序连接一个外部系统或后端组件时通常会出现这类漏洞。可能很难在使用各种技术的不同系统之间共享一个基于会话的安全模型。往往会避免使用那种模型， 而使用客户端提交的参数做出访问控制决定
3、寻求获得未授权访问的攻击者不仅需要知道应用程序页面的名称(viewDocument.php)， 而且需要知道他想要查看的文档的标识符。一般应用程序生成的资源标识符非常难以预测，可能是随机选择的GUID (全局统一标识符）。在其他情况下，可能很容易猜测，可能是连续生成的数字。但无论是哪一种情况， 应用程序都易于遭受攻击。URL并不具有保密性， 资源标识符也同祥如此。希望发现其他用户资源标识符的攻击者可在应用程序的某个位置找到这些信息，如访问日志。即使在应用程序的资源标识符很难猜测的情况下，如果没有对那些资源实施合理的访问控制， 它们仍然易于受到攻击。如果标识符很容易预测，也更容易被攻击者所利用
4、应用程序日志通常是一个信息金矿， 其中包含大量可被用作标识符的数据项，可利用它们探查通过标识符访问的功能。应用程序日志中常见的标识符包括： 用户名、用户ID、账号、文档ID、用户群组与角色以及电子邮件地址
标识符除用于指代应用程序中基于数据的资源外， 这种标识符还常用于表示应用程序功能。应用程序可以通过单独一个页面提供各种功能， 它接受一个功能名称或标识符为参数，应用程序也只是在各种类型的用户界面中显示或隐藏一个特殊的URL, 实施肤浅的访问控制。如果攻击者能够确定某一敏感功能的标识符， 他就能像拥有高级权限的用户一样访问该功能。
1513
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
