参考: The Web Application Hacker’s Handbook Chapter 8

1.Static Files

在大多数情况下，用户通过向服务器上执行的动态页面发出请求来访问受保护的功能和资源。每个此类页面都有责任执行适当的访问控制检查，并确认用户具有相关权限才能执行他或她尝试的操作。

但是，在某些情况下，对受保护资源的请求是直接向位于服务器Web根目录中的静态资源本身发出的。例如，在线出版商可以允许用户浏览其图书目录并购买电子书以进行下载。付款后，会将用户定向到如下所示的下载URL：

https://wahh-books.com/download/9780636628104.pdf

因为这是完全静态的资源，所以如果将其托管在传统的Web服务器上，则其内容将直接由服务器直接返回，并且不执行任何应用程序级代码。因此，资源无法实现任何逻辑来验证发出请求的用户具有所需的特权。当以这种方式访问静态资源时，很可能没有有效的访问控制来保护它们，并且任何知道URL命名方案的人都可以利用它来访问他想要的任何资源。在目前的情况下，文档名称看起来像是ISBN，这使攻击者能够快速下载出版商生产的每本电子书！

某些类型的功能特别容易出现此类问题，包括提供访问公司静态文档（例如年度报告）的金融网站，提供可下载二进制文件的软件供应商以及提供对静态日志文件和其他敏感数据的访问的管理功能。在应用程序内收集。

2.Platform Misconfi guration

某些应用程序使用Web服务器或应用程序平台层的控件来控制访问。通常，根据用户在应用程序中的角色来限制对指定URL路径的访问。例如，不在管理员组中的用户可能拒绝对/ admin路径的访问。原则上，这是控制访问的完全合法的方法。但是，平台级控件的配置中的错误通常会导致未经授权的访问发生。

平台级配置通常采用类似于防火墙策略规则的规则形式，这些规则基于以下条件允许或拒绝访问：

HTTP request method
URL path
User role

如第3章所述，GET方法的最初目的是检索信息，而POST方法的目的是执行更改应用程序数据或状态的操作。

如果不注意设计基于正确的HTTP方法和URL路径准确允许访问的规则，则可能导致未经授权的访问。例如，如果创建新用户的管理功能使用POST方法，则平台可能具有拒绝规则，该规则禁止POST方法并允许所有其他方法。但是，如果应用程序级代码未验证是否确实使用POST方法对该功能的所有请求，则攻击者可能能够通过使用GET方法提交相同的请求来规避控件。由于大多数用于检索请求参数的应用程序级API都不了解请求方法，因此攻击者可以在GET请求的URL查询字符串内简单地提供所需的参数，以未经授权地使用该功能。

从表面上看，更令人惊讶的是，即使平台级规则拒绝访问GET和POST方法，应用程序仍然容易受到攻击。发生这种情况是因为使用其他HTTP方法的请求最终可能会由处理GET和POST请求的同一应用程序代码处理。 HEAD方法就是一个例子。根据规范，服务器应使用与响应相应的GET请求相同的标头来响应HEAD请求，但没有消息正文。因此，大多数平台都通过执行相应的GET处理程序来正确处理HEAD请求，并仅返回生成的HTTP标头。 GET请求通常可用于执行敏感操作，这是因为应用程序本身为此目的使用了GET请求（与规范相反），或者是因为它不验证是否正在使用POST方法。如果攻击者可以使用HEAD请求添加管理用户帐户，则他或她可以活下来而不会在响应中收到任何消息正文。

在某些情况下，平台只需将它们传递给GET请求处理程序，即可处理使用无法识别的HTTP方法的请求。在这种情况下，可以通过在请求中指定任意无效的HTTP方法来绕过仅拒绝某些指定的HTTP方法的平台级控件。

第18章包含Web应用程序平台产品中出现的此类漏洞的特定示例。

3.Insecure Access Control Methods

某些应用程序使用根本上不安全的访问控制模型，其中访问控制决策是基于客户端提交的请求参数或攻击者控制范围内的其他条件做出的。

3.1 Parameter-Based Access Control

在此模型的某些版本中，应用程序在登录时确定用户的角色或访问级别，从此以后，该信息将以隐藏形式的字段，cookie或预设的查询字符串参数通过客户端传输此信息（请参阅第5章）。在处理每个后续请求时，应用程序将读取此请求参数，并相应地决定授予用户访问权限。

例如，使用该应用程序的管理员可能会看到以下URL：

https://wahh-app.com/login/home.jsp?admin=true

普通用户看到的URL包含不同的参数，或者根本不包含。任何知道分配给管理员的参数的用户都可以在自己的请求中简单地对其进行设置，从而获得对管理功能的访问权限.

有时很难检测这种访问控制，而无需实际将应用程序用作高特权用户并标识发出了哪些请求。当仅以普通用户身份工作时，第4章中描述的用于发现隐藏的请求参数的技术可能会成功地发现该机制。

3.2 Referer-Based Access Control

在其他不安全的访问控制模型中，应用程序使用HTTP Referer标头作为制定访问控制决策的基础。例如，应用程序可以根据用户的权限严格控制对主管理菜单的访问。但是，当用户请求单个管理功能时，应用程序可以简单地检查是否从管理菜单页面引用了该请求。它可能假定用户必须已经访问了该页面，因此具有所需的特权。当然，此模型从根本上被破坏了，因为Referer标头完全在用户的控制之下，并且可以设置为任何值。

3.3 Location-Based Access Control

许多企业都有法规或业务要求，以根据用户的地理位置限制对资源的访问。这些不仅限于金融部门，还包括新闻服务和其他。在这种情况下，公司可能会采用各种方法来定位用户，最常见的方法是对用户当前IP地址的地理位置进行定位。

基于位置的访问控制相对容易被攻击者规避。以下是一些绕过它们的常用方法：

使用基于所需位置的Web代理
使用在所需位置终止的VPN
使用支持数据漫游的移动设备
客户端机制的直接操纵

Chapter 8 Attacking Access Controls(1)-Common Vulnerabilities(1)
Chapter 8 Attacking Access Controls(2)-Attacking Access Controls(1)