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
EFF Application Penetration Testing Page 79 of 133
to circumvent the authorization mechanism. Authorization is a process that comes after a successful au- thentication, 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 privileg- es assigned to the tester.
Testing for Path Traversal (EFF-AZ-001)
First, we test if it is possible to find a way to execute a path traversal attack and access reserved infor- mation
Testing for bypassing authorization schema (EFF-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.
Testing for Privilege Escalation (EFF-AZ-003)
During this phase, the tester should verify that it is not possible for a user to modify his or her privileg- es/roles inside the application in ways that could allow privilege escalation attacks
2.5.1
Testing for Path Traversal (EFF-SEC-AZ-001)
SUMMARY
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read/write files that are not intended to be accessible. In particular situations, it could be possible to ex- ecute arbitrary code or system commands.
DESCRIPTION OF THE ISSUE
Traditionally, web servers and web applications implement authentication mechanisms in order to con- trol access to files and resources. Web servers try to confine users' files inside a "root directory" or "web document root" which represent a physical directory on the file system; users have to consider this direc- tory as the base directory into the hierarchical structure of the web application. The definition of the privileges is made using Access Control Lists (ACL) which identify which users or groups are supposed to be able to access, modify, or execute a specific file on the server. These mechanisms are designed to pre- vent access to sensitive files from malicious users (for example, the common /etc/passwd file on a Unix- like platform) or to avoid the execution of system commands.
Many web applications use server-side scripts to include different kinds of files: it is quite common to use this method to manage graphics, templates, load static texts, and so on. Unfortunately, these applica- tions expose security vulnerabilities if input parameters (i.e., form parameters, cookie values) are not correctly validated.
EFF Application Penetration Testing Page 80 of 133
In web servers and web applications, this kind of problem arises in path traversal/file include attacks. By exploiting this kind of vulnerability, an attacker is able to read directories or files which he/she normally couldn't read, access data outside the web document root, or include scripts and other kinds of files from external websites.
We will just consider the security threats related to web applications and not to web servers (e.g., the infamous "%5c escape code" into Microsoft IIS web server). We will provide further reading suggestions in the references section, for interested readers.
This kind of attack is also known as the dot-dot-slash attack (../), directory traversal, directory climbing, or backtracking. During an assessment, in order to discover path traversal and file include flaws, we need to perform two different stages:
• Input Vectors Enumeration (a systematic evaluation of each input vector)
• b) Testing Techniques (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability)
RECOMMENDED TOOLS
• Web Proxy (Burp Suite, Paros, WebScarab) • Enconding/Decoding tools
• String searcher "grep" - http://www.gnu.org/software/grep/
2.5.2
Testing for bypassing authorization schema (EFF-SEC-AZ-002)
SUMMARY
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
DESCRIPTION OF THE ISSUE
For every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify:
• Is it possible to access that resource even if the user is not authenticated? • Is it possible to access that resource after the log-out?
• Is it possible to access functions and resources that should be accessible to a user that holds a dif- ferent role/privilege?
• Try to access the application as an administrative user and track all the administrative functions. Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?
• Is it possible to use these functionalities for a user with a different role and for whom that action should be denied
EFF Application Penetration Testing Page 81 of 133
2.5.3
Testing for Privilege Escalation (EFF-SEC-AZ-003)
SUMMARY
This section describes the issue of escalating privileges from one stage to another. During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the appli- cation in ways that could allow privilege escalation attacks
DESCRIPTION OF THE ISSUE
Privilege escalation occurs when a user gets access to more resources or functionality than they are nor- mally allowed, and such elevation/changes should have been prevented by the application. This is usually caused by a flaw in the application. The result is that the application performs actions with more privi- leges than those intended by the developer or system administrator.
The degree of escalation depends on which privileges the attacker is authorized to possess, and which privileges can be obtained in a successful exploit. For example, a programming error that allows a user to gain extra privilege after successful authentication limits the degree of escalation, because the user is already authorized to hold some privilege. Likewise, a remote attacker gaining superuser privilege with- out any authentication presents a greater degree of escalation.
Usually, we refer to vertical escalation when it is possible to access resources granted to more privileged accounts (e.g., acquiring administrative privileges for the application), and to horizontal escalation when it is possible to access resources granted to a similarly configured account (e.g., in an online banking ap- plication, accessing information related to a different user).
RECOMMENDED TOOLS
• OWASP WebScarab: OWASP_WebScarab_Project