Test integrity checks (OTG-BUSLOGIC-003) - Revision history

Andrew Muller at 13:05, 8 August 2014

2014-08-08T13:05:46Z

Jane O'Connor: Added Andrew's changes.

2014-08-01T21:19:16Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-19T11:21:02Z

Final edit

David Fern at 16:03, 22 December 2013

2013-12-22T16:03:03Z

David Fern at 03:27, 17 December 2013

2013-12-17T03:27:12Z

David Fern at 03:26, 17 December 2013

2013-12-17T03:26:16Z

David Fern at 13:32, 16 December 2013

2013-12-16T13:32:40Z

David Fern at 18:37, 16 October 2013

2013-10-16T18:37:30Z

David Fern: Created page with "== Brief Description == == Issue == == Example == == Testing Method == == Test Tools == == Related Test Cases == == References == == Remediation =="

2013-10-10T18:10:28Z

Created page with "== Brief Description == == Issue == == Example == == Testing Method == == Test Tools == == Related Test Cases == == References == == Remediation =="

New page

== Brief Description ==

== Issue ==

== Example ==

== Testing Method ==

== Test Tools ==

== Related Test Cases ==

== References ==

== Remediation ==

← Older revision		Revision as of 13:05, 8 August 2014
Line 70:		Line 70:
	== Related Test Cases ==		== Related Test Cases ==

−	~~4.8 Data~~ Validation ~~Testing~~	+	All [[Testing for Input Validation\|Input Validation]] test cases

−	~~4.11.1 Test time synchronization (OTG-LOG-001) formerly "Incorrect time"~~
−
−	~~4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)~~

@@ Line 1: / Line 1: @@
-== Brief Description ==
+== Summary ==
 Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden. However, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server side controls must be smart enough to perform relational or server side edits to ensure that the proper data is allowed to the server based on user and application specific business logic.
@@ Line 9: / Line 9: @@
 Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.
 The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, system artifacts such as logs must be “protected” from unauthorized read, writing and removal.
@@ Line 38: / Line 36: @@
-== Testing Method ==
+== How to Test ==
 Generic Testing Method
@@ Line 70: / Line 68: @@
-== Test Tools ==
+== Related Test Cases ==
-• Various system/application tools such as editors and file manipulation tools.
+.8 Data Validation Testing
-• ''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
+.11.1 Test time synchronization (OTG-LOG-001) formerly "Incorrect time"
-ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
+.11.2 Test user-viewable log of authentication events (OTG-LOG-002)
-== Related Test Cases ==
+== Tools ==
-.8 Data Validation Testing
+• Various system/application tools such as editors and file manipulation tools.
-.11.1 Test time synchronization (OTG-LOG-001) formerly "Incorrect time"
+• ''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
-.11.2 Test user-viewable log of authentication events (OTG-LOG-002)
+ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

@@ Line 3: / Line 3: @@
 Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden. However, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server side controls must be smart enough to perform relational or server side edits to ensure that the proper data is allowed to the server based on user and application specific business logic.
-Finally, aside application/system data, log systems must be secured to prevent read, writing and updating.
+Additionally, the application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing because these fields remain non-editable only in the context of the browsers. Users may be able to edit their values using proxy editor tools and try to manipulate business logic. If the application exposes values related to business rules like quantity, etc. as non-editable fields it must maintain a copy on the server side and use the same for business logic processing. Finally, aside application/system data, log systems must be secured to prevent read, writing and updating.
 Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.
 == Issue ==
 The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, system artifacts such as logs must be “protected” from unauthorized read, writing and removal.
 == Example ==
@@ Line 34: / Line 36: @@
 Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated by attackers either intentionally or accidentially having their integrity destroyed?
 == Testing Method ==
@@ Line 74: / Line 77: @@
 ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.
 == Related Test Cases ==
@@ Line 82: / Line 86: @@
 .11.2 Test user-viewable log of authentication events (OTG-LOG-002)
 == References ==
@@ Line 94: / Line 99: @@
 Tamper Evidence Logging - http://tamperevident.cs.rice.edu/Logging.html
 == Remediation ==
 The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, any component that can be edited must have mechanisms in place to prevent unintentional/intentional writing or updating.

@@ Line 5: / Line 5: @@
 Additionally, the application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing because these fields remain non-editable only in the context of the browsers. Users may be able to edit their values using proxy editor tools and try to manipulate business logic. If the application exposes values related to business rules like quantity, etc. as non-editable fields it must maintain a copy on the server side and use the same for business logic processing.
-Finally, aside from data system functionality and log systems must be secured in such a manner to prevent read, writing and removal.
+Finally, aside application/system data, log systems must be secured to prevent read, writing and updating.
-Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to edit these artifacts with specific types of data/information at specific times per the business process logic.
+Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.
 == Issue ==
@@ Line 33: / Line 33: @@
 Example 4
-Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated having their integrity destroyed?
+Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated by attackers either intentionally or accidentially having their integrity destroyed?
 == Testing Method ==
@@ Line 43: / Line 43: @@
 • For each identified component determine what type of data/information is logically acceptable and what types the application/system should guard against. Also, consider who according to the business logic is allowed to  insert, update and delete data/information and in each component.
-• Attempt to insert, update or editdelete the data/informationvalues with invalid data/information into each component (i.e. input, database, or log) by users that .should not be allowed per the businesbusiness logic workflow.
+• Attempt to insert, update or edit delete the data/information values with invalid data/information into each component (i.e. input, database, or log) by users that .should not be allowed per the busines logic workflow.
@@ Line 62: / Line 62: @@
 Specific Testing Method 3
-•       List components of the application or system that could be edited, for example logging.
+•       List components of the application or system that could be edited, for example logs or databases.
 •       For each component identified, try to read, edit or remove its information. For example log files should be identified and Testers should try to manipulate the data/information being collected.
@@ Line 97: / Line 97: @@
 == Remediation ==
-The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end
+The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, any component that can be edited must have mechanisms in place to prevent unintentional/intentional writing or updating.

@@ Line 14: / Line 14: @@
 == Example ==
 Example 1
 Imagine an ASP.NET application GUI application that only allows the admin user to change the password for other users in the system. The admin user will see the username and password fields to enter a username and password while other users will not see either field. However, if a non admin user submits information in the username and password field through a proxy they may be able to “trick” the server into believing that the request has come from an admin user and change password of other users.
 Example 2
 Most web applications have dropdown lists making it easy for the user to quickly select their state, month of birth, etc. Suppose a Project Management application allowed users to login and depending on their privileges presented them with a drop down list of projects they have access to. What happens if an attacker finds the name of another project that they should not have access to and submits the information via a proxy. Will the application give access to the project? They should not have access even though they skipped an authorization business logic check.
 Example 3
 Suppose the motor vehicle administration system required an employee initially verify each citizens documentation and information when they issue an identification or driver's license. At this point the business process has created data with a high level of integrity as the integrity of submitted data is checked by the application. Now suppose the application is moved to the Internet so employees can log on for full service or citizens can log on for a reduced self-service application to update certain information. At this point an attacker may be able to use an intercepting proxy to add or update data that they should not have access to and they could destroy the integrity of the data by stating that the citizen was not married but supplying data for a spouse’s name. This type of inserting or updating of unverified data destroys the data integrity and might have been prevented if the business process logic was followed.
 Example 4
@@ Line 47: / Line 51: @@
 •	If a hidden field is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.
 Specific Testing Method 2
@@ Line 53: / Line 58: @@
 •	If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.
 Specific Testing Method 3