CRV2 PoorLogic - Revision history

Gary David Robinson at 16:49, 7 June 2014

2014-06-07T16:49:09Z

Gary David Robinson at 16:29, 7 June 2014

2014-06-07T16:29:53Z

Gary David Robinson: Created page with "This is covered in the google doc"

2014-06-07T16:26:29Z

Created page with "This is covered in the google doc"

New page

This is covered in the google doc

@@ Line 1: / Line 1: @@
-Business Logic Decision
+'''Business Logic Decision'''
 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. Two such cases are listed below, it is important to look for such scenarios in the application while testing.
-.	Use of non-editable controls – Applications may use the values of non-editable controls, drop-down menus, hidden fields or query string parameters for business logic processing. If such fields contain values like the type of the user, nature of the request, status of the transaction, etc. the attackers will get a chance to manipulate them and perform unauthorized operations. The application developers must understand that such fields are non-editable only in the context of the proxy tool. The attackers can easily modify their values using a proxy editor tool and try to manipulate business logic.
+.        	Use of non-editable controls – Applications may use the values of non-editable controls, drop-down menus, hidden fields or query string parameters for business logic processing. If such fields contain values like the type of the user, nature of the request, status of the transaction, etc. the attackers will get a chance to manipulate them and perform unauthorized operations. The application developers must understand that such fields are non-editable only in the context of the proxy tool. The attackers can easily modify their values using a proxy editor tool and try to manipulate business logic.
-.	Business logic decision based on presence or absence of certain parameters - 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 hole 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. Secure Design Recommendation:
+.        	Business logic decision based on presence or absence of certain parameters - 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 hole 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. Secure Design Recommendation:
-●	The application must not expose such parameters to the client.
+●        The application must not expose such parameters to the client.
-●	If they are exposed, the application must not rely on request parameters for logical decisions. It must maintain a separate copy of such values at the server side and use the same for business logic processing.
+●        If they are exposed, the application must not rely on request parameters for logical decisions. It must maintain a separate copy of such values at the server side and use the same for business logic processing.
-●	Apply proper authorization checks on the server side for all transactions, wherever necessary. Do not depend on presence of a user input for such decisions.
+●        Apply proper authorization checks on the server side for all transactions, wherever necessary. Do not depend on presence of a user input for such decisions.
-−
-−
-−
-−
-−
-−
-−
-Business Logic Invocation Technique
+'''Business Logic Invocation Technique'''
 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.
 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. Image two
-−
 What is the flaw?
 A flaw in such a design could be unused configurations present in the configuration file. 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: Image three
@@ Line 27: / Line 27: @@
 Secure Design Recommendation:
 The applications must ensure to:
-●	Remove ALL redundant/test/unexposed business logic configurations from the file
+●        Remove ALL redundant/test/unexposed business logic configurations from the file
-●	Apply necessary authorization check before processing business logic method
+●        Apply necessary authorization check before processing business logic method
-●	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.
+●        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
 Understand the business logic invocation technique used in the design of any application. Check if the user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):
-●	Business logic class
+●        Business logic class
-●	Method names
+●        Method names
-●	View component
+●        View component

← Older revision		Revision as of 16:29, 7 June 2014
Line 1:		Line 1:
−	This is ~~covered~~ in the ~~google doc~~	+	Business Logic Decision
		+	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. Two such cases are listed below, it is important to look for such scenarios in the application while testing.
		+	1. Use of non-editable controls – Applications may use the values of non-editable controls, drop-down menus, hidden fields or query string parameters for business logic processing. If such fields contain values like the type of the user, nature of the request, status of the transaction, etc. the attackers will get a chance to manipulate them and perform unauthorized operations. The application developers must understand that such fields are non-editable only in the context of the proxy tool. The attackers can easily modify their values using a proxy editor tool and try to manipulate business logic.
		+	2. Business logic decision based on presence or absence of certain parameters - 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 hole 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. Secure Design Recommendation:
		+	● The application must not expose such parameters to the client.
		+	● If they are exposed, the application must not rely on request parameters for logical decisions. It must maintain a separate copy of such values at the server side and use the same for business logic processing.
		+	● Apply proper authorization checks on the server side for all transactions, wherever necessary. Do not depend on presence of a user input for such decisions.
		+
		+
		+
		+
		+
		+
		+
		+	Business Logic Invocation Technique
		+	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.
		+	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. Image two
		+
		+	What is the flaw?
		+	A flaw in such a design could be unused configurations present in the configuration file. 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: Image three
		+	Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application. Image four.
		+	Consider another scenario
		+	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. Image five
		+	What is the flaw?
		+	Here, the user can attempt to invoke the methods of the events that are not visible to the user.
		+	Secure Design Recommendation:
		+	The applications must ensure to:
		+	● Remove ALL redundant/test/unexposed business logic configurations from the file
		+	● Apply necessary authorization check before processing business logic method
		+	● 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
		+	Understand the business logic invocation technique used in the design of any application. Check if the user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):
		+	● Business logic class
		+	● Method names
		+	● View component