Difference between revisions of "Testing for Authorization"

From OWASP
Jump to: navigation, search
(New page: {{Template:OWASP Testing Guide v3}} '''This is a draft of a section of the new Testing Guide v3''' == Brief Summary == <br> ..here: we describe in "natural language" what we want to test...)
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:OWASP Testing Guide v3}}
 
{{Template:OWASP Testing Guide v3}}
  
'''This is a draft of a section of the new Testing Guide v3'''
+
''' 4.6 Authorization Testing '''
 +
----
  
== Brief Summary ==
+
Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization means understanding how the authorization process works, and using that information to circumvent the authorization mechanism.<br>
<br>
+
Authorization is a process that comes after a successful authentication, so the tester will verify this point after he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester.
..here: we describe in "natural language" what we want to test.
+
 
<br>
+
[[Testing for Path Traversal  (OWASP-AZ-001)|4.6.1 Testing for Path Traversal  (OWASP-AZ-001)]]<br>
== Description of the Issue ==
+
First, we test if it is possible to find a way to execute a path traversal attack and access reserved information
<br>
+
 
...here: Short Description of the Issue: Topic and Explanation
+
[[Testing_for_Bypassing_Authorization_Schema  (OWASP-AZ-002)|4.6.2 Testing for bypassing authorization schema  (OWASP-AZ-002)]]<br>
<br>
+
This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.
== Black Box testing and example ==
+
 
'''Testing for Topic X vulnerabilities:''' <br>
+
[[Testing_for_Privilege_escalation (OWASP-AZ-003)|4.6.3 Testing for Privilege Escalation  (OWASP-AZ-003)]]<br>
...<br>
+
During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.
'''Result Expected:'''<br>
+
...<br><br>
+
== Gray Box testing and example ==
+
'''Testing for Topic X vulnerabilities:'''<br>
+
...<br>
+
'''Result Expected:'''<br>
+
...<br><br>
+
== References ==
+
'''Whitepapers'''<br>
+
...<br>
+
'''Tools'''<br>
+
...<br>
+

Revision as of 15:06, 13 December 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here


4.6 Authorization Testing


Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization means understanding how the authorization process works, and using that information to circumvent the authorization mechanism.
Authorization is a process that comes after a successful authentication, so the tester will verify this point after he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester.

4.6.1 Testing for Path Traversal (OWASP-AZ-001)
First, we test if it is possible to find a way to execute a path traversal attack and access reserved information

4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)
This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.

4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)
During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.