Testing for Privilege escalation (OTG-AUTHZ-003) - Revision history

Tony Hsu HsiangChih at 02:23, 8 February 2017

2017-02-08T02:23:57Z

Tony Hsu HsiangChih at 02:12, 8 February 2017

2017-02-08T02:12:19Z

Tony Hsu HsiangChih at 02:06, 8 February 2017

2017-02-08T02:06:57Z

Tony Hsu HsiangChih: /* How to test */

2017-02-08T02:00:17Z

‎How to test

Andrew Muller: Andrew Muller moved page Testing for Privilege escalation (OTG-AUTHZ-004) to Testing for Privilege escalation (OTG-AUTHZ-003)

2014-08-08T11:57:11Z

Andrew Muller moved page Testing for Privilege escalation (OTG-AUTHZ-004) to Testing for Privilege escalation (OTG-AUTHZ-003)

Andrew Muller: Andrew Muller moved page Testing for Privilege escalation (OWASP-AZ-003) to Testing for Privilege escalation (OTG-AUTHZ-004): Align with Common Numbering

2014-08-05T13:17:06Z

Andrew Muller moved page Testing for Privilege escalation (OWASP-AZ-003) to Testing for Privilege escalation (OTG-AUTHZ-004): Align with Common Numbering

Jane O'Connor: Added Andrew's changes.

2014-08-01T20:24:52Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-14T19:01:29Z

Final edit

Lvsteche: Minor corrections.

2014-03-25T11:46:27Z

Minor corrections.

David Fern: Added more detail to Wiki entry

2012-11-06T16:17:40Z

Added more detail to Wiki entry

@@ Line 83: / Line 83: @@
 For example:
   /../.././userInfo.html
 == References ==

@@ Line 17: / Line 17: @@
 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), can 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 functions as another user in order to verify 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).
-=== Case 1: Manipulation of user group ===
+=== Manipulation of user group ===
 For example:<br>
 The following HTTP POST allows the user that belongs to grp001 to access order #0001:
@@ Line 30: / Line 30: @@
 Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.
-=== Case 2: Manipulation of user profile ===
+=== Manipulation of user profile ===
 For example:<br>
@@ Line 56: / Line 56: @@
 What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
-=== Case 3: Manipulation of condition value ===
+=== Manipulation of condition value ===
 For example:<br>
@@ Line 70: / Line 70: @@
 <br><br>
-=== Case 4: Manipulation of IP Address ===
+=== Manipulation of IP Address ===
 Some webistes uses IP address to limit the access or count the number of error login based on IP address.
@@ Line 77: / Line 77: @@
 In this case, if the website uses the value of 'X-forwarded-For' as client IP address, tester may change the IP value of the 'X-forwarded-For' HTTP header to workaround the IP source identification.
 == References ==

@@ Line 17: / Line 17: @@
 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), can 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 functions as another user in order to verify 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).
+=== Case 1: Manipulation of user group ===
 For example:<br>
 The following HTTP POST allows the user that belongs to grp001 to access order #0001:
@@ Line 30: / Line 30: @@
 Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.
 For example:<br>
@@ Line 54: / Line 55: @@
 What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
 For example:<br>
@@ Line 66: / Line 69: @@
 In this condition, verify that it is not possible to escalate privileges by modifying the parameter values. In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.
 <br><br>
 == References ==

@@ Line 54: / Line 54: @@
 What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
 For example:<br>
@@ Line 64: / Line 63: @@
 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 `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== 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 or roles inside the application in ways that could allow privilege escalation attacks.
 Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed, and such elevation or 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.
@@ Line 15: / Line 13: @@
-== Black Box testing and example ==
+== How to test ==
 '''Testing for role/privilege manipulation''' <br>
 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), can 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 functions as another user in order to verify 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).
@@ Line 74: / Line 72: @@
 '''Whitepapers'''<br>
 * Wikipedia - Privilege Escalation: http://en.wikipedia.org/wiki/Privilege_escalation<br>
-'''Tools'''<br>
 * OWASP WebScarab: [[OWASP WebScarab Project]]

← Older revision	Revision as of 11:57, 8 August 2014
(No difference)

← Older revision	Revision as of 13:17, 5 August 2014
(No difference)

@@ Line 1: / Line 1: @@
-{{Template:OWASP Testing Guide v3}}
+{{Template:OWASP Testing Guide v4}}
 == Brief Summary ==
@@ Line 22: / Line 22: @@
   ...
-  gruppoID=grp001&ordineID=0001
+  groupID=grp001&orderID=0001
 </pre>
-Verify if a user that does not belong to grp001 can modify the value of the parameters ‘gruppoID’ and ‘ordineID’ to gain access to that privileged data.
+Verify if a user that does not belong to grp001 can modify the value of the parameters ‘groupID’ and ‘orderID’ to gain access to that privileged data.
 For example:<br>
@@ Line 41: / Line 41: @@
   Connection: close
-  <form  name=“autoriz" method="POST" action = “visual.jsp">
+  <form  name="autoriz" method="POST" action = "visual.jsp">
-  <input type="hidden" name="profilo" value="SistemiInf1">
+  <input type="hidden" name="profile" value="SysAdmin">
   <body onload="document.forms.autoriz.submit()">
   </td>
   </tr>
-What if the tester modifies the value of the variable "profilo" to “SistemiInf9”? Is it possible to become administrator?
+What if the tester modifies the value of the variable "profile" to "SysAdmin"? Is it possible to become administrator?
 For example:<br>
 In an environment in which the server sends an error message contained as a value in a specific parameter in a set of answer's codes, as the following:
-  @0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValido`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`
+  @0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`
   StateExecToolBar`0`0`0`FlagsToolBar`0
 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.
+In this particular example, by modifying the `PVValid` value from '-1' to '0' (no error conditions), it may be possible to authenticate as administrator to the server.
 <br><br>
 == References ==
@@ Line 68: / Line 64: @@
 * Wikipedia - Privilege Escalation: http://en.wikipedia.org/wiki/Privilege_escalation<br>
 '''Tools'''<br>
-* OWASP WebScarab: [[OWASP_WebScarab_Project]]
+* OWASP WebScarab: [[OWASP WebScarab Project]]