OWASP Secure Application Design Project - Revision history

Johanna Curiel: /* Classifications */

2015-07-06T19:41:38Z

‎Classifications

Johanna Curiel: /* Classifications */

2015-07-06T19:40:55Z

‎Classifications

Johanna Curiel at 19:37, 6 July 2015

2015-07-06T19:37:25Z

Ashish Rao: /* Business Logic Invocation Technique */

2015-06-09T18:36:11Z

‎Business Logic Invocation Technique

Ashish Rao: /* Placement of Security Controls */

2015-06-09T18:34:45Z

‎Placement of Security Controls

Ashish Rao: /* Placement of Security Controls */

2015-06-09T18:34:13Z

‎Placement of Security Controls

Ashish Rao: /* Model Object Binding Technique */

2015-06-09T18:17:15Z

‎Model Object Binding Technique

Ashish Rao: /* Business Logic Invocation Technique */

2015-06-09T18:15:09Z

‎Business Logic Invocation Technique

Ashish Rao: /* Business Logic Invocation Technique */

2015-06-09T18:14:44Z

‎Business Logic Invocation Technique

Ashish Rao at 18:05, 9 June 2015

2015-06-09T18:05:23Z

@@ Line 72: / Line 72: @@
     | colspan="2" align="center"  | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
     |-
-    | colspan="2" align="center"  | [[File:Project_Type_Files_DOCUMENTS.jpg|link=]]
+    | colspan="2" align="center"  | [[File:Project_Type_Files_DOC.jpg|link=]]
     |}

@@ Line 72: / Line 72: @@
     | colspan="2" align="center"  | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
     |-
-    | colspan="2" align="center"  | [[File:Project_Type_Files_CODE.jpg|link=]]
+    | colspan="2" align="center"  | [[File:Project_Type_Files_DOCUMENTS.jpg|link=]]
     |}

@@ Line 1: / Line 1: @@
 =Main=
-<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div>
+<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[File:Incubator_big.jpg|link=OWASP_Project_Stages#tab=Incubator_Projects]]</div>
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-

@@ Line 184: / Line 184: @@
 A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it.
 An unused configuration present in the configuration file of the application is shown below:
 [[File:Design2.jpg]]
@@ Line 196: / Line 197: @@
 '''What is the flaw?'''
 Here, the user can attempt to invoke the methods of the events that are not visible to the user.

← Older revision		Revision as of 18:34, 9 June 2015
Line 254:		Line 254:

	Consider a MVC based given in the figure below.		Consider a MVC based given in the figure below.
		+
	[[File:Design7.png]]		[[File:Design7.png]]

@@ Line 253: / Line 253: @@
 It thus seems logical that if you restrict the users at the page/view level they won’t be able to perform any operation in the application. But what if instead of requesting for a page/view an unauthorized user tries to request for an internal action like to action to add/modify any data in the application? It will get processed but the resultant view will be denied to the user; because the flaw lies in just having a view based access control in the applications. I am sure you will agree that a lot of processing for a request is done before the “view” comes into picture in any design. So the request to process any action will get processed successfully without authorization.
-Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages.
+Consider a MVC based given in the figure below.
 Observe that neither the controller servlet (central processing entity) nor the action classes have any access control checks. So here, if the user requests for an internal action like add user details, etc. without authentication it will get processed, but the only difference is that the user will be shown an error page as resultant view will be disallowed to the user.
 '''Insecure POST-BACK’s in ASP.NET'''
 A similar flaw is predominantly observed in ASP.NET applications where the developers tend to mix the code for handling POSTBACK’s and authentication checks. Usually it is observed that the authentication check in the ASP.NET pages are not applied for POSTBACKs, as indicated below. Here, if an attacker tries to access the page without authentication an error page will be rendered. Instead, if the attacker tries to send an internal POSTBACK request directly without authentication it would succeed. A detailed explanation is present here -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]
 '''Secure Design Recommendation:'''

@@ Line 222: / Line 222: @@
 Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here the request parameters get directly bound to the variables of the corresponding business/command object. Binding here means that the instance variables of such classes get automatically initialized with the request parameter values based on their names.
 Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.
 '''What is the flaw?'''
@@ Line 227: / Line 229: @@
 The flaw in such design could be that the business objects may have variables that are not dependent on the request parameters. Such variables could be key variables like price, max limit, role etc. having static values or dependent on some server side processing logic.
 A threat in such scenarios is that an attacker may supply additional parameters in request and try to bind values for unexposed variable of business object class.  As illustrated in the figure below, the attacker sends an additional “price” parameter in the request and binds with the unexposed variable “price” in business object, thereby manipulating business logic.
 '''Secure Design Recommendation:'''

@@ Line 177: / Line 177: @@
 Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.
 [[File:Design1.png]]
@@ Line 183: / Line 184: @@
 A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it.
 An unused configuration present in the configuration file of the application is shown below:
 [[File:Design2.jpg]]
 Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.
 [[File:Design3.jpg]]

@@ Line 172: / Line 172: @@
 ==Business Logic Invocation Technique==
-''Introduction''
+'''Introduction'''
 In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application.
@@ Line 179: / Line 179: @@
 <img1>
-''What is the flaw?''
+'''What is the flaw?'''
 A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it.
@@ Line 186: / Line 186: @@
 Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.
-''Consider another scenario - Method Invocation''
+'''Consider another scenario - Method Invocation'''
 In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.
-''What is the flaw?''
+'''What is the flaw?'''
 Here, the user can attempt to invoke the methods of the events that are not visible to the user.
@@ Line 197: / Line 197: @@
 •	Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.
-''Review Criteria''
+'''Review Criteria'''
 With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):
@@ Line 291: / Line 291: @@
 During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:
-''CASE 1:'' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing.
+'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing.
 The users can easily alter such parameter values and try to manipulate business logic.
-''CASE 2:'' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.
+'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.
 The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application.
-''CASE 3:'' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic.
+'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic.
 Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.