Securing Decisions and Web Application Firewalls (Azure)

Overview

Decisions, as a company and product, has a commitment to security and security standards. There are regulatory controls around company software development practices, lifecycles, data center controls, and hosting operations for customers. These controls ensure that the product, once delivered, can be used in environments that have high standards for data and operational security. Decisions strongly recommend best practices and standards to customers because the application allows the customer to configure processes over which Decisions has no control. Customers installing Decisions to MS Azure may choose to use a Web Application Firewall (WAF) which adds a layer of security that enforces industry-standard web application security rules.

Configuration Changes Required for Decisions

Per SOC and PCI obligations, a secure guide is maintained that the company or company customers have.

Configuration and Rules in the WAF

Decisions can perform without issue behind the AZure Open Web Application Security Project (OWASP) Rule-based WAF with the following configuration changes made to ensure functional integrity.

Impact on the Product

If the configuration changes listed above are not made, Decisions can still function and most functions that users would use will work well. However, this functionality will depend heavily on the customer's use case.  For example, a case management process that requires a user to upload documents would not work well if Rule 920420 is left enabled since it will block all file uploads.

It is impossible to determine exactly what aspects of implementation will or will not be impacted by using the WAF due to the fact that Decisions allows customers to configure processes, data, and Rules to operate in the best way that suits the desired outcome. 

Inspect Request Body

Body Inspection adds additional security by interrogating the data sent to an application server behind the WAF.  Body Inspection is useful in creating a more secure environment, but many systems may send data that, because of the nature of the application, contains special or suspicious characters that will be blocked by the WAF.

A simple example of this is email content. In Decisions, users can configure an email message to be sent to another user that contains style elements, links to work the task, and maybe an image.  In order to configure this email step, Decisions needs to send those elements to the backend to be stored for future use. This content could easily trigger an error on the WAF and cause the request to fail. If the request body inspection is turned off, WAF does not evaluate the contents of the HTTP message body. In such cases, WAF continues to enforce WAF rules on headers, cookies, and URI providing security for the most common attack vectors.

The 128 KB Limit

In MS Azure, using Inspect Request Body forces a limit on all traffic to the backend to 128 KB. This becomes an issue because users can create Rules and Flows that easily and quickly exceed this size.  Enabling the 128 KB limit will make saving and testing the reliability of Flows and processes very difficult because there will be no clear way to know if the threshold may be exceeded. 

Enabling the 128 KB Limit

If this setting is enabled, any request over 128 KB will be rejected. This impacts the following features and functions: 

• Large Reports or Dashboards 
• Flows with many steps 
• Rules with many conditions 
• Testing sessions that deal with a lot of data. 

Disabling the 128 KB Limit

Disabling this setting allows Decisions to work normally.  This is less secure than running with the setting on because the Azure WAF will not be inspecting the bodies of the web requests before sending them to the backend. It is very important to consider that the WAF will still be running against every request and looking for anything that violates the OWASP rules with URIs, cookies, IP addresses, and Headers. This means that there’s still a level of security being provided by the WAF for the application. When any request is sent to the Decisions application server, the request must be authenticated and deserialized.

Even though Decisions use REST-based web services, the original implementation of Decisions used 100% SOAP services and a SOAP / WCF Service Layer.  This is a very important note because it means that the services are based on structured types and type-safe messages. Arbitrary data sent to Decisions simply cannot be processed.  This historical baseline means that there is little risk in SQL injection, cross-site scripting, cross-site forgery, or other attack vectors being leveraged when calling a Decisions-based service on the backend without body inspection turned on.

The Rule and Workflow Engine Web Application communicates with the application server exclusively through this service layer. There are no other entry points to the application server code which control the database, persistence, and user security aspects of the application.  These architectural aspects limit the need for the WAF to inspect message bodies to provide security. However, it is understood that some customers will still want to enforce this additional layer of security.

Understanding Web Service Calls 

The following entries are web service calls made from the web application to the workflow application server from the client browser.  This sequence of calls was taken from the path of working a task, reassigning a task, and browsing the Portal to get to a particular Dashboard. 

Each of the following requests includes the reasoning why Decisions does not believe that inspecting the post body of the request itself would provide any real security above and beyond the deserialization and validation of the data request by the Workflow and Rule engine.

1. Service Call: https://{ServerName}/decisions/Primary/API/ClientEventsService/js/RemoveFolderRegistration?rand=85

   {"userContext":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities",
   "SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "clientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "folderID":"43abb0fe-aa60-11e8-949f-00155d172301"}

   The data sent to Decisions from the web application above is a folder id that needs to be removed. The user context that is indicated by the session must be a valid and registered user session, and the user MUST have permission to delete this folder. Changing the data completely would be discarded and changing the folder id would require permissions.
   
   
2. Service Call: https://{ServerName}/decisions/Primary/API/ClientEventsService/js/WaitForEvents?rand=90
   

   {"userContext":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities",
   "SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "clientEventsSessionID":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "eventID":"32311c60-9114-11e8-bded-00155d172301"}

   Waiting for events requires a valid Client Event Session-Id, tied correctly to a valid Session-Id registered on the server. If the structure is modified, or either session is invalid - then the message is ignored.
3. Service Call: https://{ServerName}/decisions/Primary/API/Assignment/js/GetAllForAssigneesList?rand=64
   

   {"context":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities","SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "param":7}

   Getting all assignees requires access to the user list with a “Can Use” permission on the application server.
4. Service Call: https://{ServerName}/decisions/Primary/API/Assignment/js/ChangeAssignment?rand=65
   This web service call can only deal with assignments.  The Assignment Id and the assignees indicated must be accurate ids of objects in the Decisions environment for which the user has the appropriate access. If the body of this service call were compromised it may be possible that an attacker could cause the specific workflow task to be assigned to another valid user in the system by account id.
   
   

   {"context":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities",
   "SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "assignmentId":"238506b0-9874-4045-833f-c65d1dd342ee",
   "changeDto":
   {"AccountIDs": ["863c18c7-cadd-434c-923d-88de35f444e6"],
   "GroupIDs": ["681f6b25-a3fa-11e7-9431-00155d0afd03"],
   "Permissions":[],
   "Roles":[],
   "Priority":1,
   "NotificationMessage":"",
   "NotifyOnlyNewAssignees":false}
   }

5. Service Call: GET https://{ServerName}/decisions/HUI/API/Script/GroupService?rand=47
   
   This request is a GET and only provides data about the GroupsService.  Most simple queries are done via GET and there would not be subjected to body inspection in any way.
6. Service Call: https://{ServerName}/decisions/Primary/API/ClientEventsService/js/RemoveFolderRegistration?rand=7
   This service call removes a “notification subscription” from the client.  If an attacker were able to inject another folder id into this request they may be able to prevent in-browser pop-up notifications to a user about tasks that were being actively assigned.
   
   

   {"userContext":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities",
   "SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "clientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "folderID":"11c1fb54-419e-11e8-b3e8-00155d172301"}

7. Service Call: https://{ServerName}/decisions/Primary/API/ClientEventsService/js/PingWithFolders?rand=27
   This service call removes a “notification subscription” from the client.  If an attacker were able to inject another folder id into this request they may be able to prevent in-browser pop-up notifications to a user about tasks that were being actively assigned.
   
   

   {"userContext":
   {"__type":"SessionUserContext:#DecisionsFramework.ServiceLayer.Utilities",
   "SessionValue":"e8c70024-06cd-4af0-913d-f51aa676807d",
   "ClientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "DisplayType":"2",
   "StudioPortal":true,
   "BrowserUserAgent":null},
   "clientEventSessionId":"2e53c6b0-ffa0-4a2d-a14f-d24525959bb7",
   "folderID":"11c1fb54-419e-11e8-b3e8-00155d172301"}

In any of the above circumstances or cases that move far beyond these situations, it is very difficult to see how body inspection provides any real security to a company using Decisions. Every one of these calls to Decisions must be authenticated and that authenticated call MUST originate from the IP address of the logged-in user.  If the user can log in, and has appropriate permission, then that user could do far more damage much more quickly by simply logging into the application and using the app itself to mutate data. Since every call must conform to a contract that is type-safe and atomic, Decisions as a company does not believe that body inspection of POST calls to the application server back-end provides any real additional security to the customer.