Use of Non-Canonical URL Paths for Authorization Decisions
Description The software defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization. Extended DescriptionIf an application defines policy namespaces and makes authorization decisions based on the URL, but it does not require or convert to a canonical URL before making the authorization decision, then it opens the application to attack. For example, if the application only wants to allow access to http://www.example.com/mypage, then the attacker might be able to bypass this restriction using equivalent URLs such as:http://WWW.EXAMPLE.COM/mypagehttp://www.example.com/%6Dypage (alternate encoding)http://192.168.1.1/mypage (IP address)http://www.example.com/mypage/ (trailing /)http://www.example.com:80/mypageTherefore it is important to specify access control policy that is based on the path information in some canonical form with all alternate encodings rejected (which can be accomplished by a default deny rule). Enabling Factors for ExploitationAn application specifies its policy namespaces and access control rules based on the path information.Alternate (but equivalent) encodings exist to represent the same path information that will be understood and accepted by the process consuming the path and granting access to resources. Likelihood of Exploit: High Applicable PlatformsLanguage Class: Language-independentArchitectural Paradigm: Web-based Time Of Introduction
Common Consequences
Detection MethodsNone Potential Mitigations
Relationships
Demonstrative ExamplesNone Observed Examples
White Box Definitions None Black Box Definitions None Taxynomy Mappings
References:None |