IBM Business Automation Workflow, Security Vulnerability Analysis Part2: Examples from my experience

Published in

IBM Digital Business Automation Tips and Assets

12 min readJul 14, 2020

A practical approach to creating secure environments is to be proactive and defensive and most companies today strive to protect their systems from security threats. At the same time, they adapt to the latest technologies and trends.

In this two-part article, I will share approaches and experience in addressing security risks and vulnerabilities. In part 1:IBM Business Automation Workflow, Security Vulnerability Analysis Part1: The Method, I described the method and steps towards securing BAW environments. In this second part, I shall share my experience in addressing vulnerabilities using examples that I have seen and worked with clients.

It is not uncommon to see message interactions that appear malicious (especially the ones from Burp collaborator servers) in the application logs. But, this is often evidence that there that vulnerability assessment is occurring. Most customers employ security teams to run vulnerability scans repeatedly to uncover any risks posed by their systems and solutions.

I have been engaged with customers to help mitigate security vulnerabilities in situations where traces of security risks were found at the firewall or appeared in the application logs.

My experience with Security Vulnerabilities

The following are a few examples of common security vulnerabilities, I have encountered in BAW solutions and how I have addressed them in my recent projects

Most of these examples are from environments from IBM BPM version 8.6 with cumulative fix 2018.03. However, these do apply to later versions of Business Automation Workflow as well.

Path-Based Vulnerability -Path disclosure

Threat: Users can discover web server paths and gain access to potentially sensitive files, directories, or directory listings.
Example URLs,

/ProcessPortal/dashboards/SYSRP/1052/rest/bpm/wle/v1/users/

Configuration settings in the application server (Web Container) or the web server can mitigate this risk. We handled this in IBM HTTP Server by disabling directory browsing as specified in Disabling Directory Browsing.
Later versions of WAS have directory browsing disabled by default. However, any contradicting configuration in a deployed application can override the server defaults for that application.

For instance, a property setting <enable-directory-browsing value=” true”/> in an application’s ibm-web-ext.xml overrides the default behavior of WAS. In these cases, the value of the setting ‘enable-directory-browsing value’ has to be changed to false.

The below applications in IBM BAW have Directory browsing property enabled:

IBM_BPM_Teamworks
BSpaceEAR

Slow HTTP POST — Denial of Service vulnerability (DoS)

Threat: An application-level DoS that consumes server resources by maintaining open connections for an extended period by slowly sending traffic to the server.

This vulnerability can be posed due to many reasons as seen in the page Denial Of Service. The mitigation steps to be taken depends upon the cause of the attack

My customer faced this vulnerability due to slow HTTP POST. Specifying timeouts for receiving request headers and body in the IBM HTTP Server configuration mitigated this risk. Refer to the HTTP Server manual for more details.

Cross-Site Request Forgery vulnerability (CSRF)

Threat: Forms /assets are susceptible to CSRF attack
Example URL,

/ProcessPortal/dashboards/SYSRP/1004

The standard CSRF countermeasure is to include a hidden form field with a random value specific to the user’s current session, which is then validated by the application on the server-side. Protect all forms within the application from CSRF attacks.

My customer mitigated CSRF attacks by setting Workflow Security hardening properties,

Whitelist a list of Referer /Origin headers.
Use Session tokens for CSRF Filtering.

Whitelist a list of Referer /Origin headers.
Requests with headers that do not match the whitelisted (Referer or Origin) values will be blocked. Requests that do not have Referer and or Origin headers specified are allowed.

To be able to set this property, you need to inspect the Referer and the Origin headers in between requests. Besides, an understanding of the use cases that could be affected by this setting is necessary.

Things to keep in mind,

It is not advisable to whitelist a very long list of Referers.
It’s a good practice to review the existing headers using Developer tools (F12/fiddler) before you whitelist them. If any value for the Referer or origin is wrongly whitelisted, valid requests may get blocked.

Figure 1: Illustration of reviewing headers using Fiddler

In cases where a web server sits in front of a Workflow Server cluster, and when there is a need to access a page (e.g. Process Admin console ) on individual nodes, bypassing the web server, the respective hosts have to be added to the referer list as well.
Customers may utilize remote locations (e.g., Kiosks, or other systems at outlets) to leverage IBM BAW services. Investigate the probability of the requests getting blocked due to CORS (Cross-Origin Resource Sharing), and apply measures to avoid invalid blockage.

Whitelist Referer and Origin headers by using the following commands as given in IBM BAW Security Hardening properties.

Security.CsrfProtectionRefererWhitelist Security.CsrfProtectionOriginWhitelist

The Referer and Origin whitelisting takes the form of’ hostname’ and ‘protocol://hostname: port’ respectively.
For example, ‘myhost.domain’ or ‘myhost’ for a Referer and https://myhost.domain:port’ for an origin
Note that ‘hostname.domain’ is not same as ‘hostname’

Use Session Tokens For CSRF Filtering
Often a stream of /teamworks/ajaxCoach related URLs could pose as suspected attacks. Customers should evaluate complete URLs and ensure they are valid requests related to coaches built by them.

In some cases, it may be difficult to pinpoint which of these requests are malicious and hence may find its way past the firewall. Protecting IBM BAW systems from these become crucial in such cases.

CSRF blocking can be enabled for these URLs, in addition to Process Monitor console URLs, by setting the following BPM Properties

Security.CsrfSessionTokenSalt with a Value ‘verySecret’Security.CsrfSessionTokenProtectedUris for URIs /teamworks/ajaxCoach and /teamworks/_cs

Please refer to IBM BAW Security Hardening properties for more information.

Session Cookie (Authentication Related) Does Not Contain The “HTTPOnly” Attribute

Threat: The session cookie used to identify authenticated users of the Web application does not contain the “HTTPOnly” attribute.

Session Cookie (Authentication Related) Does Not Contain The “HTTPOnly” Attribute is a common vulnerability reported for IBM BAW workflows. Ignore Session cookies that contain no sensitive information. Interpreting IBM Security AppScan findings documents an enumeration of a few cookies of this kind.

In the absence of evidence and documentation, you will need to complete further investigation. For instance, if the vulnerability complains about XSRF-TOKEN cookie not set as HTTPOnly, then this is as per design. The presence of HTTPOnly header in this case inhibits the creation of an intermediate token. In this case, valid POST requests may be blocked when session token-based CSRF filtering is active.

It is advisable to contact the IBM support team to understand the vulnerability posed by any session token not otherwise listed anywhere.
com.ibm.bpm. servlet. LaunchDashboardServlet.avatarKey cookie is another example that doesn’t carry any sensitive information.

If needed, session cookies like JSESSIONID can be configured as Secure and HTTPOnly in the Session Management section, if not already set, as shown below.

Figure 2: Session tokens Properties: Secure and HTTPOnly

Cross-Site Scripting (XSS )

Threat: HTML injection attacks such as cross-site scripting (XSS) use characters such as single quotes, double quotes, and angle brackets.

Example URLs,

rest/bpm/wle/v1/searches/tasks/%22%3e%3cimg%20src%3dq%20on error%3dalert (9)%3e/rest/bpm/wle/v1/coachflow/instancedata/ProcessPortal/login.jsp?errorMessage=”><script>alert(String.fromCharCode(88,83,83))</script>/rest/bpm/wle/v1/tasks [name JSON parameter]/rest/bpm/wle/v1/user/current [value parameter]/rest/bpm/wle/v1/system/rep/Mashups_ConfigService [ JSON parameter within the properties parameter]

Someone could add Script tags to request URL or the request parameters. The choice of request URL or request parameters can alter the Response.

A typical task of addressing this kind of vulnerability is to repeat the request. In almost all cases that we tested, BAW did NOT execute the injected script determining that the injected script was ignored and not honored by IBM BPM/BAW systems.

Protection for XSS can be configured in the Web Server (IBM HTTP Server) or IBM BAW through BPM Property setting for X-XSS protection as given below,

Value of Security.XXssProtectionHeaderValue can be set to 1 and mode=block.

Please refer to IBM BAW Security Hardening properties for more information.

Path-relative style sheet import (PRSSI) vulnerability
Threat: Relative URLs can be dangerous since the browser may not determine the correct directory. If the HTML uses path-relative CSS links, it may be susceptible to Path Relative Style Sheet Import (PRSSI) vulnerabilities. It could allow an attacker to take advantage of CSS imports with relative URLs by overwriting their target file.

Example URLs,

/ProcessPortal/login.jsp

Setting the following IBM BPM/BAW security hardening properties as given below mitigated PRSSI vulnerability.

Set response header X-Frame-Options: ‘DENY’. Since my customer used a lot of client-side human services, a more compromised setting of ‘SAME ORIGIN’ was set. Set the property as given below,
Security.XFrameOptionsHeaderValue with a value “DENY” or “SAMEORIGIN”
To avoid sniffing on the web page, set response header X-Content-Type-Options;
Security.XContentTypeOptionsHeaderValue with a value “nosniff”

Information on the above settings can be found in IBM BAW Security Hardening properties.

Use Web server settings as an alternative configuration option. But preference should be to have them set only in one place.

SQL Injection
Threat: The data JSON parameter within the ‘params’ parameter appears to be vulnerable to SQL injection attacks.

Example URLs,

/rest/bpm/wle/v1/service/1./teamworks/cfecontroller/rest/bpm/wle/v1/coachflow/service/1.

This vulnerability needs to be tried and reviewed to see whether the parameters with any injected query can cause harm to the system. It is not desirable if it either writes to a database or returns sensitive information. Please note that the service could return data that, in turn, can be used to extract sensitive information from any other system.

The exact same request with the exact same parameters as reported needs to be tested. Replacement of single quotes by double quotes in the same parameters can lead to a completely different response.

The Interpreting AppScan findings document mentions a few cases that fall in this category, such as injected URLs with CMIS like SQL Queries. These URLs, unless stated very clearly with the request, are subject to trial.

In my recent project, one of the requests for /teamworks/cfecontroller, had a CMIS -like a query in the JSON Parameter and was observed to cause a task completion replay. Seek help from IBM Support if you see similar behaviors.

Mitigate SQL injection by following good Programming practices, a few examples include:

Always use parameterized queries.
Double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is to prevent the insertion of malformed data from terminating the string. However, this may fail if the data is numeric.
Use stored procedures. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks, such as in the case of dynamically constructed SQL.

Cross-Domain Referer Leakage
Threat: An attacker may be able to inject links referring to a domain they control, to capture data from URLs used within the application, primarily when the content within the application has been authored.

Example URLs,

/ProcessPortal/login.jsp with customized links

When a web browser requests for a resource, it typically adds an HTTP header, called the “Referer” header, indicating the URL of the resource from which the request originated.

If requested resources reside in a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information gets transmitted to the other domain. If the receiving domain is not trusted, this may lead to security compromises.

Whether domains are trusted, and the data transmitted is necessary must be reviewed.

In my customer’s scenario, the cross-domain was a fully trusted domain and well within the organization’s control and limits. It, therefore, posed no vulnerability. However, set Referrer policies in the web server should this be an issue.

For instance, a ‘no-referrer’ policy can set so that no referrer information is sent with requests made to a cross-domain site, omitting the header entirely.

By default, the Referrer-Policy in WAS and IBM BPM is ‘no-referrer-when-downgrade’, which allows the headers to be sent only in cases of strict HTTP transport situations.

Cache-able HTTPS response
Threat: Local caches storing sensitive information found in responses makes them vulnerable to being seen by users who are not supposed to view it.

Example URLs,

/rest/bpm/wle/v1/coachflow/1./teamworks/generatecoachng

Unless directed otherwise, browsers may store a locally cached copy of content received from web servers — some browsers, including Internet Explorer, cache content accessed via HTTPS.

The responses from the application should contain caching directives instructing browsers not to store local copies of any sensitive data.

Prevent caching for relevant paths within the webroot by configuring the web server (IBM HTTP Server refer to HTTP Caching Guide).

Responses with HTTP cache-control headers, set to no-cache or no-store, are not cached in either the memory or file system cache. The value of private prevents public caching servers from caching content for more than one user.

Observation revealed that most responses did have a private cache control and, in some cases, no-store by default.

However, in cases like /teamworks/generatecoachng, it was desirable to have a cache-control value set to the public to avoid performance issues. Set expiration and age limit configurations to reduce the severity of this compromise.

Performance is affected when several files are loaded directly from the IBM Business Process Manager (BPM) server instead of the files being cached.

Error Responses Contain The Error Codes / Detailed Messages

Threat: Users can make attacks against the system based on knowledge gleaned from information found in error messages.

Example URLs,

/teamworks/generatecoachng/rest/bpm/wle/v1/service/1/teamworks/cfecontroller

For example, if a user sees an HTTP/1.1 500 Internal Server error, they may gain information on the types of servers being used and use it to design a more specific attack. Similarly, in some cases of SQL injection, error Messages that contain SQL exception codes give a potential attacker insight that they can use to alter and plan their next attack.

One defense mechanism to this could be sending out responses that are not indicative of an error.

In one of my customers’ scenario, the error message from BPM was intercepted and masked with normal successful responses by the Web Application Firewall System.

Troubleshooting Tips

This section talks about the troubleshooting techniques that were employed in order to analyze and mitigate any particular vulnerability.

Debugging on the Console with the browser provided developer tools e.g. F12.
The browser-specific web developer tools are useful to debug client-side errors especially to inspect values like
1. Request headers like Referers and Origins, cookies, and tokens.
2. Response headers that contain instructions to browsers on request handling.For example. Strict HTTP transport, cookies set to secure, HTTPOnly, caching, etc.
It could be useful to use tools like Fiddler to be able to inspect the entire request message with parameters and data.
Employing BPM Rest API UI tester (//host:port/bpmrest-ui) and other tools.
It has been observed that most of the internal scans done on the BAW systems to uncover vulnerabilities are done using a privileged user. It is then difficult to say if a particular finding is really a vulnerability or can be deemed false-positive.
Many such requests can be tried and verified for other roles and users using the REST tester UI Web Application provided by IBM BPM.
This can also be complemented by the use of tools like SOAP UI testers and chrome extensions to cover varied user scenarios and derive analysis results.
Enabling trace strings on the BPM Server to trace out the headers, token generation, and other details. These can be enabled in the ‘Runtime’ tab in IBM BPM servers, under ‘Logging and Tracing’ per JVM.
The trace strings, I found useful were ,
com.ibm.bpm.rest.*=all and com.ibm.bpm.servlet.filters.*=all

In summary

This two-part article focused on methods and procedures that could be followed for addressing security vulnerabilities with a few illustrations in the second part.

In addition to the security hardening configurations, provided by IBM BAW properties, there are a number of security fixes on IBM BPM/BAW and WAS that aim at remediating known vulnerabilities. A few of the BPM/BAW fixes, my customers have used are listed in the section “Useful references and links”.

Security is a very technical and complex area. Hence, it is recommended to engage experts from the field while accessing the environment.

This concludes part 2 for “IBM Business Automation Workflow, Security Vulnerability Analysis Part 2: Examples from my experience”.

Useful References and links

This section lists a number of useful links that I found handy during my security vulnerability engagements.

IHS Vulnerability reports

http://publib.boulder.ibm.com/httpserv/ihsdiag/vulnerabilities.html#general-guidance-on-scan-and-pentest-reports

IBM BPM Vulnerability listing

https://www.cvedetails.com/vulnerability-list/vendor_id-14/product_id-25452/IBM-Business-Process-Manager.html

Cross-Site Request forgery Cheat Sheet by OWASP

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Cross-Origin Resource Sharing

Denial of service

SQL injection

10 most common web-security vulnerabilities

IBM BPM/BAW Security Fixes

IBM Business Automation Workflow, Security Vulnerability Analysis Part2: Examples from my experience

My experience with Security Vulnerabilities

Path-Based Vulnerability -Path disclosure

Slow HTTP POST — Denial of Service vulnerability (DoS)

Cross-Site Request Forgery vulnerability (CSRF)

Session Cookie (Authentication Related) Does Not Contain The “HTTPOnly” Attribute

Cross-Site Scripting (XSS )

Error Responses Contain The Error Codes / Detailed Messages

Troubleshooting Tips

In summary

Useful References and links

Written by Smitha venugopal