Use of Non-Canonical URL Paths for Authorization Decisions
The product 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.
Description
If 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/mypage
http://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/mypage
Therefore 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).
Demonstrations
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Example One
Example from CAPEC (CAPEC ID: 4, "Using Alternative IP Address Encodings"). An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions.
See Also
Weaknesses in this category are related to access control.
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT Oracle Secure Coding Standard for Java.
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have th...
This view (slice) covers all the elements in CWE.
This view (slice) lists weaknesses that can be introduced during implementation.
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.