目录
1.4、多阶段功能
简述：
1、应用程序的许多功能通过几个阶段执行， 并在执行过程中由客户端向服务器发送许多请求。如添加新用户功能可能包括从用户维护菜单中选取这个选项， 从下拉列表中选择部门和用户职位， 然后输入新用户名、初始密码和其他信息。
2、许多应用程序常常会努力防止这种敏感功能被未授权访问， 但由于其误解了这种功能的使用方式， 因而实施了不完善的访问控制。
如果一名用户试图加载用户维护菜单并从中选取“添加新用户” 选项， 应用程序就会核实该用户是否拥有必要的权限， 如果用户未获授权， 就阻止其进行访问。但是， 如果攻击者直接进入核实用户所属部门和其他细节的阶段， 可能就没有有效的访问控制对其加以限制。任何到达验证过程后续阶段的用户一定已经拥有相关的权限， 因为前面的阶段已经验证了这些权限。通过这种方法， 任何应用程序用户都能够添加一个新的管理用户账户， 因而完全控制整个应用程序， 访问许多其他已经实施完善的访问控制的功能
即使在许多电子银行使用的安全性能很关键的Web应用程序中， 转账通常包括几个阶段， 部分原因是为了防止用户在请求转账时无意出错。这个多阶段过程需要在每个阶段收集各种与用户有关的数据。这些数据在初次提交后将接受严格检查， 然后使用HTML表单字段提交给随后的阶段。但如果应用程序并不在最后阶段重新确认这些数据， 攻击者就可能会避开服务器检查。如应用程序可能会核实进行转账的来源账户是否属于当前用户， 然后询问与目的账户有关的细节和转账的金额，如果用户拦截这个过程中的最后一个POST请求， 并修改来源账号，就能实现水平权限提升， 从其他用户的账户中转移资金
1.5、静态文件
简述：
1、在绝大多数情况下， 用户都是通过向在服务器上执行的动态页面发布请求来访问受保护的功能和资源，每个动态页面负责执行适当的访问控制检查， 并确认用户拥有执行相关操作所需的权限。
2、有时用户会直接向位于服务器Web根目录下的静态资源提出请求， 要求访问这些受保护的资源。如一个在线出版商允许用户浏览他的书籍目录并购买电子书进行下载。支付费用后， 应用程序就将用户指向下载URL
因为这是一个完全静态的资源， 所以它并不在服务器上运行， 它的内容直接由Web服务器返回。资源自身并不能执行任何检查以确认提出请求的用户拥有必要的权限。如果可以通过这种方式访问静态资源， 那么这些资源很可能没有受到有效的访问控制机制的保护， 任何知晓URL命名方案的人都可以利用这种缺陷访问任何所需的资源。文档名称可能是一个ISBN, 利用这个信息， 攻击者能够任意下载由该出版商制作的每一本电子书。某些功能特别容易出现这种问题， 包括提供公司年度报表之类静态文档的金融Web站点、提供可下载二进制代码的软件供应商以及通过其访问应用程序中静态日志文件和其他敏感数据的管理功能
1.6、平台配置错误
简述：
1、一些应用程序在Web服务器或应用程序平台层使用控件来控制访问。通常应用程序会根据用户的角色来限制对特定URL路径的访问。如果用户不属于“管理员” 组， 访问／admin路径的清求可能会遭到拒绝，这是完全合法的访问控制方法。但如果在配置平台级控件时出现错误，就可能导致未授权访问。（GET方法是检索俏息，POST方法的目的是执行更改应用程序的数据或状态的操作）
2、一般平台级配置与防火墙策略规则类似，基于以下条件允许或拒绝访问请求：HTTP请求方法、URL路径、用户角色
3、如果没有配置以基于正确的HTTP方法和URL路径允许访问， 就可能会导致未授权访问。如果用于创建新用户的管理功能使用POST方法，平台可能具有禁止POST方法并允许所有其他方法的拒绝规则。但如果应用程序级脚本并不验证针对此功能的所有请求是否使用POST方法， 则攻击者就可以通过使用GET方法提交同一请求来避开这种控制。由于大多数用于检索请求参数的应用程序级APl对于请求方法并无限制，攻击者只需要在GET请求的URL查询字符串中提供所需参数， 就可以未授权使用上述功能。
4、即使平台级规则拒绝访问GET和POST方法， 应用程序仍有可能易于受到攻击。因为使用其他HTTP方法的请求可能最终由处理GET和POST请求的相同应用程序代码来处理。HEAD方法就是一个典型的例子。根据规范， 服务器应使用它们用于响应对应的GET请求的相同消息头（但不包含消息主体）来响应HEAD请求。大多数平台都能够正确处理HEAD请求， 即执行对应的GET处理程序并返回生成的HTTP消息头。通常GET请求可用于执行敏感操作， 这或者是因为应用程序本身将GET请求用于这一目的（与规范不符）， 或者是因为它并不验证是否使用了POST方法。如果攻击者能够使用HEAD请求增加一个管理用户账户， 那么即使在请求中未收到任何消息主体， 他仍然能够成功实施攻击。
有时对于使用无法识别的HTTP方法的请求，平台会直接将它们交由GET请求处理程序处理。在这种情况下， 通过在请求中指定任意无效的HTTP方法， 就可以避开拒绝某些指定的HTTP方法的平台级控制
1.7、访问控制方法不安全
简述：
一些应用程序使用一种极其不安全的访问控制模型， 基于客户端提交的请求参数或受攻击者控制的其他条件做出访问控制决定。
基于参数的访问控制
模型中， 应用程序在用户登录时决定用户的角色或访问级别， 并在登录后通过隐藏表单字段， cookie或者预先设定的查询字符串参数由客户端传送这些信息。应用程序在处理随后请求的过程中读取这个请求参数， 并为用户分配相应的访问级别。如使用应用程序的管理员看到的URL：https://xxx.com/login/home.jsp?admin=true
但普通用户看到的URL中包含一个不同的参数， 或者根本不包含任何参数。任何知道分配给管理
员的参数的用户只需在他自己的请求中使用这个参数， 就可以访问管理功能。如果不以高级权限用户的身份实际使用应用程序， 并确定在使用过程中提出了哪些请求， 这种类型的访问控制可能很难探测出来。作为普通用户，可以使用尝试发现隐藏请求参数的技巧成功查明这种机制
基于Referer的访问控制
在其他不安全的访问控制模型中，应用程序使用HTTP Referer消息头做出访问控制决定。如应用程序可能会根据用户的权限， 严格控制用户访问主维护菜单。但如果某名用户提出请求， 要求访问某项管理功能， 应用程序可能只是检查该请求是否由管理菜单页面提出， 如果确实出该页面提出， 即认为该用户一定已经访问过那个页面， 并因此已经拥有了必要的权限。这种模型并不安全， 因为Referer消息头完全由用户控制， 并可设定为任何值
基于位置的访问控制
1、有的公司管理或业务要求， 根据用户的地理位置限制对资源的访问。会采用各种方法来确定用户的位置， 其中最常用的是用户当前IP地址的地理位置
2、攻击者能够轻易突破基于位置的访问控制：
使用位于所需位置的Web代理服务器
使用在所需位置终止的VPN
使用支持数据漫游的移动设备
直接修改客户端用于确定地理位过的机制