This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Top 10 2010-A8-Failure to Restrict URL Access"
From OWASP
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A7-Insecure Cryptographic Storage|next=A9-Insufficient Transport Layer Protection}} | {{Top_10_2010:TopTemplate|useprev=2010PrevLink|usenext=2010NextLink|prev=A7-Insecure Cryptographic Storage|next=A9-Insufficient Transport Layer Protection}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack. | + | {{Top_10_2010:SummaryTableHeaderBeginTemplate}} |
| − | + | {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} | |
| − | + | {{Top_10_2010:SummaryTableValue-3-Template|Prevalence|UNCOMMON}} | |
| + | {{Top_10_2010:SummaryTableValue-2-Template|Detectability|AVERAGE}} | ||
| + | {{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}} | ||
| + | {{Top_10_2010:SummaryTableHeaderEndTemplate}} | ||
| + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Anyone with network access can send your application a request. Could anonymous users access a private page or regular users a privileged page?</td> | ||
| + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected.</td> | ||
| + | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Applications are not always protecting page requests properly. Sometimes, URL protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.<br/><br/>Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack.</td> | ||
| + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.</td> | ||
| + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the exposed functions and the data they process.<br/><br/>Also consider the impact to your reputation if this vulnerability became public.</td> | ||
| + | {{Top_10_2010:SummaryTableEndTemplate}} | ||
| − | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=8}} | |
| − | | | ||
| − | |||
| − | {{Top_10_2010: | ||
The best way to find out if an application has failed to properly restrict URL access is to verify '''every''' page. Consider for each page, is the page supposed to be public or private. If a private page: | The best way to find out if an application has failed to properly restrict URL access is to verify '''every''' page. Consider for each page, is the page supposed to be public or private. If a private page: | ||
#Is authentication required to access that page? | #Is authentication required to access that page? | ||
#Is it supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page? | #Is it supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page? | ||
External security mechanisms frequently provide authentication and authorization checks for page access. Verify they are properly configured for every page. If code level protection is used, verify that code level protection is in place for every required page. Penetration testing can also verify whether proper protection is in place. | External security mechanisms frequently provide authentication and authorization checks for page access. Verify they are properly configured for every page. If code level protection is used, verify that code level protection is in place for every required page. Penetration testing can also verify whether proper protection is in place. | ||
| − | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=2|risk=8}} | |
| − | {{Top_10_2010: | ||
Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), all of the following are recommended: | Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), all of the following are recommended: | ||
# The authentication and authorization policies be role based, to minimize the effort required to maintain these policies. | # The authentication and authorization policies be role based, to minimize the effort required to maintain these policies. | ||
| Line 39: | Line 25: | ||
# The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page. | # The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page. | ||
# If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access. | # If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access. | ||
| − | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=3|risk=8}} | |
| − | {{Top_10_2010: | ||
The attacker simply force browses to target URLs. Consider the following URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page. | The attacker simply force browses to target URLs. Consider the following URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page. | ||
| − | + | {{Top_10_2010:ExampleBeginTemplate}}<nowiki>http://example.com/app/getappInfo</nowiki><br/><nowiki>http://example.com/app/admin_getappInfo</nowiki>{{Top_10_2010:ExampleEndTemplate}} | |
| − | |||
If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages. | If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages. | ||
Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target. | Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target. | ||
| − | {{Top_10_2010: | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=8}} |
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}} | {{Top_10_2010:SubSubsectionOWASPReferencesTemplate}} | ||
* [[Top_10_2007-Failure_to_Restrict_URL_Access | OWASP Top 10-2007 on Failure to Restrict URL Access]] | * [[Top_10_2007-Failure_to_Restrict_URL_Access | OWASP Top 10-2007 on Failure to Restrict URL Access]] | ||
| Line 58: | Line 42: | ||
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}} | {{Top_10_2010:SubSubsectionExternalReferencesTemplate}} | ||
*[http://cwe.mitre.org/data/definitions/285.html CWE Entry 285 on Improper Access Control (Authorization)] | *[http://cwe.mitre.org/data/definitions/285.html CWE Entry 285 on Improper Access Control (Authorization)] | ||
| − | {{Top_10_2010: | + | {{Top_10_2010:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|useprev=2010PrevLink|usenext=2010NextLink|prev=A7-Insecure Cryptographic Storage|next=A9-Insufficient Transport Layer Protection}} |
[[Category:OWASP Top Ten Project]] | [[Category:OWASP Top Ten Project]] | ||
Latest revision as of 05:12, 2 May 2010
NOTE: THIS IS NOT THE LATEST VERSION. Please visit the OWASP Top 10 project page to find the latest edition.
| ← A7-Insecure Cryptographic Storage | Top 10 Risks |
A9-Insufficient Transport Layer Protection → |
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| Application Specific | Exploitability EASY |
Prevalence UNCOMMON |
Detectability AVERAGE |
Impact MODERATE |
Application / Business Specific |
| Anyone with network access can send your application a request. Could anonymous users access a private page or regular users a privileged page? | Attacker, who is an authorized system user, simply changes the URL to a privileged page. Is access granted? Anonymous users could access private pages that aren’t protected. | Applications are not always protecting page requests properly. Sometimes, URL protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack. |
Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted. | Consider the business value of the exposed functions and the data they process. Also consider the impact to your reputation if this vulnerability became public. |
|
|
Am I Vulnerable To 'Failure to Restrict URL Access'?
The best way to find out if an application has failed to properly restrict URL access is to verify every page. Consider for each page, is the page supposed to be public or private. If a private page:
External security mechanisms frequently provide authentication and authorization checks for page access. Verify they are properly configured for every page. If code level protection is used, verify that code level protection is in place for every required page. Penetration testing can also verify whether proper protection is in place. |
How Do I Prevent 'Failure to Restrict URL Access'?
Preventing unauthorized URL access requires selecting an approach for requiring proper authentication and proper authorization for each page. Frequently, such protection is provided by one or more components external to the application code. Regardless of the mechanism(s), all of the following are recommended:
|
|
Example Attack Scenarios
The attacker simply force browses to target URLs. Consider the following URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page. http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages. Such flaws are frequently introduced when links and buttons are simply not displayed to unauthorized users, but the application fails to protect the pages they target. |
References
OWASP
For additional access control requirements, see the ASVS requirements area for Access Control (V4) External |
| ← A7-Insecure Cryptographic Storage | Top 10 Risks |
A9-Insufficient Transport Layer Protection → |
