目录
攻击访问控制
1.3、有限访问权限进行测试
简述：
如果只有一个用户级账户可用于访问应用程序（或根本没有任何账户）， 要测试访问控制的效率， 还需要完成其他工作。无论在什么情况下， 要想执行全而彻底的测试， 都需要完成其他工作。在应用程序中， 可能存在一些未受到严格保护的功能， 而且任何用户界面均未明确提供这些功能的链接。可能有一些旧功能尚未删除， 或者新功能已部署但未向用户公布。
过程：
1、使用内容查找技巧确定尽可能多的应用程序功能。以权限较低的用户进行查找就足以枚举并直接访问敏感功能
2、如果确定可能向普通和管理用户提供不同功能或链接的应用程序页面（如控制面板、我的主页），尝试在URL查询字符串和POST请求主体中插入admin=true之类的参数，确定这样做是否可发现或访问任何其他所拥有的用户权限正常无法访问的功能
3、测试应用程序是否基于Referer消息头做出访问控制决策。对于获得授权访问的关键应用程序功能， 尝试删除或修改Referer消息头并确定是否仍然能够成功提出请求。如果不能，应用程序可能以某种不安全的方式信任Referer消息头。如果使用Bp的主动扫描器扫描请求， Bp会尝试删除每个请求的Referer消息头， 并通知你这样做是否会在应用程序的响应中造成对应的相关差异
4、检查所有客户端HTML与脚本， 查找隐藏功能或可从客户端进行操纵的功能的引用，如基于脚本的用户界面。反编译所有浏览器扩展组件， 查找任何服务器端功能的引用
一旦枚举出所有可访问的功能， 就有必要测试应用程序是否正确划分每名用户访问资源的权限。如果应用程序允许用户访问一组内容广泛的相同类型的资源（如文档， 订单、电子邮件和个
人资料），则用户就有机会未授权访问其他资源1、无论应用程序使用何种标识符（文档ID 、账号等）指定用户所请求的资源，应尝试找到没有权限访问的资源的标识符。
2、如果有可能生成一系列紧密相连的标识符（如通过创建几个新文档或订单），则可以针对会话令牌，尝试在应用程序生成的标识符中查找任何可预测的序列。
3、如果无法生成任何新标识符， 那么只能通过分析已经发现的标识符， 或纯粹使用猜测方法查找标识符。如果标识符为GUID形式， 则基于猜测的尝试将无法取得成功。但如果标识符是一个相对较小的数字，则可以尝试使用与它相差不大的另一个数字， 或数字位相同的另一个随机数字
4、如果发现访问控利并不完善， 而且资源标识符可以预测， 可以发动自动攻击获取应用程序的敏感资源和信息。设计一次定制自动攻击， 以获取所需的数据
如果"账户信息"页面在显示用户个人资料的同时还显示他的用户名和密码， 则这种漏洞可能会造成灾难性的后果。虽然输入的密码在屏幕上隐藏显示， 但它仍然以明文形式传送至浏览器。通常可以快速遍历账户标识符的所有可能值范围， 从而获得所有用户， 包括管理员的登录证书。
如果检测到访问控制漏洞， 先尝试通过攻破一个具有管理权限的用户账户来进一步提升自己的权仅。可以通过各种技巧查找管理账户。利用访问控制缺陷， 可以获得数百个用户证书， 并尝试手动登录每一个账户，直到找到管理员用户。但如果账户以连续的数字ID为标识符， 则应用程序通常会将最小的数字账户分配给管理员。登录几个最先注册的用户， 往往就可以确定应用程序管理员账户。如果这种方法不可行， 一种有效的方法是在应用程序中查找其访问权限被水平隔离的功，如每名用户呈现的主页。编写一段脚本，使用截获的每个证书登录， 然后尝试访问自己的主页。很可能管理用户能够查看每一名用户的主页， 如果用于登录的是管理账户，立即就会发觉
1.4、测试"直接访问方法"
简述：
如果应用程序使用直接访问服务器端API方法的请求， 一般使用上述技巧即可确定这些方法中的访问控制漏洞。但还应该进行测试， 以确定是否存在其他可能未受到正确保护的API
过程：
1、确定任何遵循Java命名约定（如get、set 、add、update、is或has后接大写单词）或明确指定包结构（如com. companyname.xxx.yyy.ClassName)的参数。记下所有你能够发现的被引用的方法
2、找到某个列举可用接口或方法的方法。在代理服务器历史记录中进行搜索，看应用程序的正常通信是否调用了该方法，如果该方法未被调用， 则尝试使用观察到的命名约定猜测该方法。
3、在公共资源（如搜索引擎和论坛站点）中查找， 以确定任何其他可以访问的方法
4、猜测其他方法名称
5、尝试使用各种用户账户访问收集到的所有方法（包括未授权访问）
6、如果不知道某些方法需要的参数的数量或类型，可以寻找那些不大可能使用参数的方法
1.5、测试对静态资源的控制
简述：
如果受应用程序保护的静态资源最终可以通过指向资源文件本身的URL直接访问， 这时你应该进行测试， 以确定未授权用户是否可以直接请求这些URL
过程：
1、遍历访问受保护静态资源的正常过程， 获取用于最终访问该资源的URL示例
2、使用不同的用户账户（如权限较低的用户或没有购买所需商品的账户）， 尝试使用已确定的URL直接访问该资源
3、如果这种攻击取得成功，尝试了解受保护的静态资源所使用的命名方案。如果可能，设计一个自动攻击， 获取可能有用或可能包含敏感数据的内容
1.6、测试对HTTP方法实施的限制
简述：
虽然并没有现成的方法可用于检测应用程序的访问控制是否对HTTP方法实施了平台级控制， 但可以通过一些简单的步骤来确定任何漏洞
过程：
1、使用一个权限较高的账户， 确定一些执行敏感操作的特权请求． 如添加新用户或更改
用户的安全角色的请求。2、如果这些请求未受到任何反CSRF令牌或类似功能的保护， 可以使用权限较高的账户确定， 如果HTTP方法被修改， 应用程序是否仍然执行请求的操作。应测试的HTTF方法包括：POST、GET、HEAD、任何无效的HTTP方法
3、如果应用程序执行任何使用与最初的方法不同的HTTP法的请求，则应使用上述技巧，通过权限较低的账户对针对这些请求实施的访问控制进行测试
1713
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
