Difference between revisions of "Access control enforced by presentation layer"

From OWASP
Jump to: navigation, search
m
Line 1: Line 1:
 
{{Vulnerability}}
 
{{Vulnerability}}
  
==Overview==
+
==Description==
 
Enforcing access control in the presentation layer means that the developer does not show buttons and links for functions and assets that are not authorized for the user. An attacker, however, is not constrained by the buttons and links presented, and can forge requests for those functions and assets. [[Forced browsing]] is one attack that targets this type of vulnerability.
 
Enforcing access control in the presentation layer means that the developer does not show buttons and links for functions and assets that are not authorized for the user. An attacker, however, is not constrained by the buttons and links presented, and can forge requests for those functions and assets. [[Forced browsing]] is one attack that targets this type of vulnerability.
  
==Consequences ==
+
===Consequences ===
 
* Disclosure of unauthorized assets (confidentiality)
 
* Disclosure of unauthorized assets (confidentiality)
 
* Invocation of unauthorized business functions (integrity)
 
* Invocation of unauthorized business functions (integrity)
  
==Exposure period ==
+
===Exposure period ===
 
* Design phase
 
* Design phase
  
==Platform ==
+
===Platform ===
 
* Languages: any
 
* Languages: any
 
* Operating platforms: any
 
* Operating platforms: any
  
==Required resources ==
+
===Required resources ===
 
* Generally requires a user login, although not always
 
* Generally requires a user login, although not always
  
==Severity ==
+
===Severity ===
 
Very high -- can result in disclosure of sensitive information or the invocation of protected business functions.
 
Very high -- can result in disclosure of sensitive information or the invocation of protected business functions.
  
==Likelihood of exploit ==
+
===Likelihood of exploit ===
 
With the source code, this vulnerability is very likely
 
With the source code, this vulnerability is very likely
  
==Avoidance and mitigation ==
+
===Avoidance and mitigation ===
 
Access control must be performed in the business layer, not only the presentation layer.
 
Access control must be performed in the business layer, not only the presentation layer.
  
==Discussion ==
+
===Discussion ===
 
This vulnerability is similar in some ways to [[Validation performed in client]], as the same security checks are performed in two places. Doing validation in the business logic, like doing validation on the server, are critical to security. However, many web applications and web services only do access control in the presentation layer, allowing an attacker to easily access unprotected functions.
 
This vulnerability is similar in some ways to [[Validation performed in client]], as the same security checks are performed in two places. Doing validation in the business logic, like doing validation on the server, are critical to security. However, many web applications and web services only do access control in the presentation layer, allowing an attacker to easily access unprotected functions.
 +
 +
==Rick Factors==
 +
  
 
==Examples ==
 
==Examples ==
Line 35: Line 38:
 
  //FIXME: JSP example of not showing a link
 
  //FIXME: JSP example of not showing a link
  
==Related problems ==
+
==Related [[Attacks]]==
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 
* [[Validation performed in client]]
 
* [[Validation performed in client]]
 +
 +
 +
==Related [[Controls]]==
 +
* [[Control 1]]
 +
* [[Control 2]]
 +
 +
==Related [[Technical Impacts]]==
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
==References==
 +
TBD
 +
 +
 +
==Related problems ==
  
 
[[Category:Range and Type Error Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]

Revision as of 21:01, 15 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Description

Enforcing access control in the presentation layer means that the developer does not show buttons and links for functions and assets that are not authorized for the user. An attacker, however, is not constrained by the buttons and links presented, and can forge requests for those functions and assets. Forced browsing is one attack that targets this type of vulnerability.

Consequences

  • Disclosure of unauthorized assets (confidentiality)
  • Invocation of unauthorized business functions (integrity)

Exposure period

  • Design phase

Platform

  • Languages: any
  • Operating platforms: any

Required resources

  • Generally requires a user login, although not always

Severity

Very high -- can result in disclosure of sensitive information or the invocation of protected business functions.

Likelihood of exploit

With the source code, this vulnerability is very likely

Avoidance and mitigation

Access control must be performed in the business layer, not only the presentation layer.

Discussion

This vulnerability is similar in some ways to Validation performed in client, as the same security checks are performed in two places. Doing validation in the business logic, like doing validation on the server, are critical to security. However, many web applications and web services only do access control in the presentation layer, allowing an attacker to easily access unprotected functions.

Rick Factors

Examples

J2EE

//FIXME: JSP example of not showing a link

Related Attacks


Related Vulnerabilities


Related Controls

Related Technical Impacts

References

TBD


Related problems

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.