In every portion of the application where a user can create information in the database(a payment, add a contact, send a message), to receive information (statement of account, order details, etc.) or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such function as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

+

In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), to receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such function as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

For example:<br>

For example:<br>

−

The following HTTP POST permits to the user that belongs to grp001 to access order #0001:

+

The following HTTP POST allows the user that belongs to grp001 to access order #0001:

POST /path/viewMyOrder.jsp HTTP/1.1

POST /path/viewMyOrder.jsp HTTP/1.1

Line 53:

Line 53:

</tr>

</tr>

−

What if the tester modifies the value of the variable "profilo" with “SistemiInf9”?

+

What if the tester modifies the value of the variable "profilo" to “SistemiInf9”? Is it possible to become administrator?

−

It is possible to become administrator?

+

For example:<br>

For example:<br>

Line 63:

Line 62:

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.

−

In this condition, verify that by modifying the parameter values it is not possible to escalate privileges.

+

In this condition, verify that it is not possible to escalate privileges, by modifying the parameter values.

−

In this particular example modifying the `PVValido` value from '-1' to '0' (no error conditions) it may be possible to authenticate as administrator to the server.

+

In this particular example, by modifying the `PVValido` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.

<br>

<br>

'''Result Expected:'''<br>

'''Result Expected:'''<br>

−

The tester should verify execution of successful privilege escalation attempts.<br><br>

+

The tester should verify the execution of successful privilege escalation attempts.<br><br>

Brief 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 application 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 normally 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 privileges 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 without 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 application, accessing information related to a different user).

Black Box testing and example

Testing for role/privilege manipulation
In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), to receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such function as another user in order to verify, for example, if it is possible to access a function that should not be permitted by the user's role/privilege (but might be permitted as another user).

For example:
The following HTTP POST allows the user that belongs to grp001 to access order #0001:

The server gives an implicit trust to the user. It believes that the user will answer with the above message closing the session.
In this condition, verify that it is not possible to escalate privileges, by modifying the parameter values.
In this particular example, by modifying the `PVValido` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.

Result Expected:
The tester should verify the execution of successful privilege escalation attempts.