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 "J2EE Misconfiguration: Weak Access Permissions"
Weilin Zhong (talk | contribs) (Added contents from Fortify.) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | Permission to invoke EJB methods should not be granted to the ANYONE role. | ||
If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible. | If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible. | ||
| − | ==Examples == | + | |
| + | ==Risk Factors== | ||
| + | |||
| + | * Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen | ||
| + | * Discuss the technical impact of a successful exploit of this vulnerability | ||
| + | * Consider the likely [business impacts] of a successful attack | ||
| + | |||
| + | |||
| + | ==Examples== | ||
The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary(). | The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary(). | ||
| Line 29: | Line 45: | ||
</pre> | </pre> | ||
| − | |||
| − | ==Related Attacks== | + | ==Related [[Attacks]]== |
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[:Category:Access Control]] | ||
| + | |||
| + | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | TBD | ||
| + | |||
| + | |||
| + | [[Category:FIXME|add links | ||
| + | |||
| + | In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki> | ||
| + | |||
| + | Availability Vulnerability | ||
| + | |||
| + | Authorization Vulnerability | ||
| + | |||
| + | Authentication Vulnerability | ||
| + | |||
| + | Concurrency Vulnerability | ||
| + | |||
| + | Configuration Vulnerability | ||
| + | |||
| + | Cryptographic Vulnerability | ||
| + | |||
| + | Encoding Vulnerability | ||
| + | |||
| + | Error Handling Vulnerability | ||
| + | |||
| + | Input Validation Vulnerability | ||
| + | |||
| + | Logging and Auditing Vulnerability | ||
| − | + | Session Management Vulnerability]] | |
| − | + | __NOTOC__ | |
| − | |||
| − | + | [[Category:OWASP ASDR Project]] | |
[[Category:Environmental Vulnerability]] | [[Category:Environmental Vulnerability]] | ||
[[Category:Access Control Vulnerability]] | [[Category:Access Control Vulnerability]] | ||
Revision as of 17:34, 26 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Last revision (mm/dd/yy): 09/26/2008
Vulnerabilities Table of Contents
Description
Permission to invoke EJB methods should not be granted to the ANYONE role.
If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.
Risk Factors
- Talk about the factors that make this vulnerability likely or unlikely to actually happen
- Discuss the technical impact of a successful exploit of this vulnerability
- Consider the likely [business impacts] of a successful attack
Examples
The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary().
<ejb-jar> ... <assembly-descriptor> <method-permission> <role-name>ANYONE</role-name> <method> <ejb-name>Employee</ejb-name> <method-name>getSalary</method-name> </method-permission> </assembly-descriptor> ... </ejb-jar>
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD