Troubleshooting
Problem
Running a security-vulnerability scanning product such as IBM Security AppScan against your IBM Business Process Manager (BPM) environment can result in some false positives. To know what you should ignore as a false positive and what you should fix or report, compare your findings to the information in this technote.
Cause
Scanning your process applications for security flaws is key to ensuring that your infrastructure and your users' data is secure. Run a security-scanning software, such as IBM Security AppScan, and address reported findings.
IBM BPM is regularly tested by checking web interfaces for security vulnerabilities such as cross-site scripting (XSS) and SQL injection. A recent version of IBM Security AppScan Standard runs against IBM BPM to test the core product for application vulnerabilities and findings are fixed. IBM also provides security bulletins about vulnerabilities that are found and fixed after product release so that you know to apply fixes to the software and anything that you might have built on top of it. You can subscribe to receive security notices by e-mail at http://www.ibm.com/software/support/einfo.html.
IBM BPM V8.6 has been scanned with IBM Security AppScan V9.0.3 for application (not infrastructure) vulnerabilities. This technote explains why some findings can be categorized as false positives on base IBM BPM web interfaces. Because IBM BPM is a development tool that contains a set of components that you use to build process applications, AppScan cannot exercise all of the potential code that is part of your IBM BPM environment.
You install IBM BPM on your own infrastructure and you extend and customize IBM BPM web components with your process applications (custom coaches or JavaScript, for example). Therefore, it's important that you also regularly scan your system for application and infrastructure vulnerabilities by using a product such as IBM Security AppScan.
Some of the findings that security-scanning software reports are false positives. False positives occur because the scanning software looks for patterns that indicate possible vulnerabilities that, in some cases, are not actually at risk for exploitation or can be secured by using security-configuration settings. You must examine each finding to determine whether it is a true vulnerability.
Review the following information about false positives that IBM Security AppScan V9.0.3 finds in IBM BPM V8.6. Consider this information when you perform your own security scan and determine whether the findings are true or false positives for your business process management infrastructure and applications. Factors in your environment that produce additional security vulnerabilities include your hardware, operating system, and middleware infrastructure, the process applications you create, and the security-scanning software you choose.
IBM BPM is regularly tested by checking web interfaces for security vulnerabilities such as cross-site scripting (XSS) and SQL injection. A recent version of IBM Security AppScan Standard runs against IBM BPM to test the core product for application vulnerabilities and findings are fixed. IBM also provides security bulletins about vulnerabilities that are found and fixed after product release so that you know to apply fixes to the software and anything that you might have built on top of it. You can subscribe to receive security notices by e-mail at http://www.ibm.com/software/support/einfo.html.
IBM BPM V8.6 has been scanned with IBM Security AppScan V9.0.3 for application (not infrastructure) vulnerabilities. This technote explains why some findings can be categorized as false positives on base IBM BPM web interfaces. Because IBM BPM is a development tool that contains a set of components that you use to build process applications, AppScan cannot exercise all of the potential code that is part of your IBM BPM environment.
You install IBM BPM on your own infrastructure and you extend and customize IBM BPM web components with your process applications (custom coaches or JavaScript, for example). Therefore, it's important that you also regularly scan your system for application and infrastructure vulnerabilities by using a product such as IBM Security AppScan.
Some of the findings that security-scanning software reports are false positives. False positives occur because the scanning software looks for patterns that indicate possible vulnerabilities that, in some cases, are not actually at risk for exploitation or can be secured by using security-configuration settings. You must examine each finding to determine whether it is a true vulnerability.
Review the following information about false positives that IBM Security AppScan V9.0.3 finds in IBM BPM V8.6. Consider this information when you perform your own security scan and determine whether the findings are true or false positives for your business process management infrastructure and applications. Factors in your environment that produce additional security vulnerabilities include your hardware, operating system, and middleware infrastructure, the process applications you create, and the security-scanning software you choose.
Resolving The Problem
Explanations of AppScan potential vulnerability findings in IBM BPM V8.6
If you run AppScan or a similar security-scanning product against your environment and find a security vulnerability, compare it with the following information. If the vulnerability is not explained by (or fixed with) the following information, and it is a vulnerability in IBM BPM itself and not your customization or infrastructure, report it to IBM Support. Your support representative will request to see the findings report for the scanning software and as much detail as possible and as appropriate. For example, if you are using AppScan, the scan must include the Request/Response information, so be sure to select this option in AppScan before you generate the reports.
The first step in assessing potential vulnerabilities is to understand the exact findings and why they are potentially dangerous. The documentation from your scan tool will help. IBM Security AppScan documents a set of critical vulnerability types, but they tend to produce a significant amount of false positives. See Identify and avoid false positives with IBM AppScan.
Depending on the type of scan (application, infrastructure, etc.) and the scan tool that you use, you might see additional findings about HTTP response headers to enable or control browser protection features, such as X-Frame-Options or Content-Security-Policy. Such headers can be set by applying Security-hardening properties or by adding a header module to the web server in front of IBM BPM. It is strongly recommended that you review the list of possible headers and apply them in your environment as appropriate.
Vulnerability types
Some "types" of findings are reported for several web user interfaces. For those interfaces, the issue, assessment and possible mitigation (if applicable) are described here and referred to later in this document. Note that some findings were not reported in the latest scans. They are still included in this document, as other tools might still report similar findings.
Vulnerability type 1 - Cross-Site Request Forgery (CSRF)
In a CSRF attack, the attacker prepares a malicious web site that causes the victim's browser to send a request to a vulnerable server. For simple requests (HTTP GET and POST with a Content-Type as used in plain HTML form submissions), the victim's browser will just send the request and include all cookies associated with the target URL. The vulnerable server has no means of determining whether the request was sent intentionally by the end user or the end user was tricked into sending that request.
A widely effective protection is checking the HTTP request headers Referer and Origin against an allowlist (formerly called a allowlist). For cross-site requests, browsers include the URL of the current origin in the header. If you know that users access IBM BPM only by using bookmarks or links from some intranet portal, you can add these to an allowlist. For more information, see the Referer header values described in Security-hardening properties (ProcessServer.CsrfProtectionRefererallowlist):
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
The Referer header check has been improved with V8.6 to allow parameter-free GET requests so that other sites can link to web pages like the Process Portal landing page without being added to an allowlist.
The Origin header is typically added if the request was sent as an XMLHttpRequest. Some security researchers have argued that it is more reliable than the Referer header, so it can also be restricted using an allowlist. See Security-hardening properties (ProcessServer.CsrfProtectionOriginallowlist):
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfProtectionOriginallowlist', '-value',
'https://some.server.com, https://some.other.server.com'])
There are edge cases in which the Referer or Origin header check cannot provide full protection, thus penetration testers often demand protection using session-specific tokens. CSRF token protection has been added as an optional feature for URLs that are not public APIs. See Security-hardening properties (ProcessServer.CsrfSessionTokenSalt ProcessServer.CsrfSessionTokenProtectedUris):
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfSessionTokenSalt', '-value', 'verySecret'])
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfSessionTokenProtectedUris', '-value',
'/teamworks/ajaxCoach,/teamworks/cs_'])
Vulnerability type 2 - Inadequate Account Lockout
In IBM BPM, the external user repository (such as LDAP) handles the end-user account lockout. For more information, see Configuring the user registry.
An account lockout policy for end users (if desired) should be configured in the external user repository. This ensures account lockout even in cases where password guesses for the same user are entered in many different applications.
By default, at least two administrative (non-human) users are created in a WebSphere file-based repository, which does not provide an account lockout feature. This prevents attackers from locking out administrators, which ensures that the system can be operated at all times. If account lockout is required for these administrative users, it is possible to configure LDAP accounts for them.
Vulnerability type 3 - Session Identifier Not Updated
Web applications maintain session state using session cookies. In some web application frameworks, sensitive information might leak or malicious information might be injected if a session continues to be used after authentication.
IBM BPM enables WebSphere Application Server "session security integration" by default. This feature ensures that a server-side session object can only be accessed by the authenticated user owning the session. The owning user is either the current user that was active during session creation or -- in the case of transitioning from unauthenticated to authenticated state -- the user who first accesses the session. See Session management settings. As a result, sensitive information cannot leak out of session objects tracked by the JSESSIONID cookie by default and there is no need to update the value of JSESSIONID after login.
Characteristic URLs
Understanding the purpose of some URLs and URL patterns helps in the assessment of potential security vulnerabilities.
URLs that contain ibm_security_logout do not refer to a file, but instead refer to a generic URL component for logging users out. Variants of this URL pattern return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file. You might see findings like the following ones for this URL: Alternate Version of File Detected, Archive File Download, and Temporary File Download. These findings are false positives.
A URL that contains j_security_check is a URL pattern used for logging in. This URL triggers authentication on the base WebSphere Application Server product and generally does not involve any SQL execution in databases. Blind SQL injection has been reported for this URL pattern, because multiple variants of the same request returned the same response. This is expected during login and was thus declared a false positive.
URLs that start with /rest/bpm/wle/v1/coachflow/service/ indicate the invocation of a nested service inside a client-side human service (CSHS). While this REST API is implicitly invoked by the CSHS browser-side runtime, the selection of the server-side service (including the parameters it accepts) is part of a custom process application. Server-side services cannot be invoked by default. Nesting a server-side service in a CSHS exposes this service to users who are authorized to invoke the CSHS and who execute a currently active instance of the CSHS. If the server-side service has a very broad or generic interface, such as one that accepts a full SQL query or string parameters that are carelessly concatenated into SQL queries, then nesting such a server-side service in a CSHS creates an SQL injection vulnerability. SQL injection findings for these URL patterns tend to be real vulnerabilities, but caused by custom code. Inspect the service invocation and parameters to identify the vulnerable process app and ensure that you only nest services with very lean and specific interfaces into a CSHS.
SQL-like queries and CMIS
The Content Management Interoperability Services (CMIS) standard features an SQL-like query language that is used to interact with documents in the embedded IBM BPM document store. In certain circumstances, a service call invoked with a CMIS query input parameter can be flagged as an SQL injection vulnerability in a scan. However, it is generally a false positive.
The flagged vulnerability always involves a parameter value that uses SQL-like syntax, but the flagged vulnerability is specific to CMIS and its use in document interaction. Although this scenario does not permit SQL injection, the flagged vulnerability might indicate that a custom service is being used that accepts a CMIS query. If the contents of the entire query are accepted as input parameters, the custom service might be subject to injection attacks that will return more results than expected. The content integration services shipped with IBM BPM have been hardened to prevent more properties from being returned, but it does not prevent injection of a new where clause that could cause more documents to be returned.
Although a CMIS query in network traffic is not necessarily susceptible to SQL injection, you should determine whether a flagged vulnerability refers to custom code. If it does, you should determine whether the custom code allows remote users to control too much of the query that is ultimately executed.
In the IBM BPM use of CMIS, there are three different URL patterns that accept parameters. Depending on how syntax is expressed in the parameter values, using CMIS queries for service calls could result in a flagged vulnerability. The three URL patterns include:
Product web user interfaces
The following sections describe findings that have been observed when scanning the various user interfaces. Each finding is of one of the following types:
BPM Help
There are a number of keywords in the help system that trigger heuristics in AppScan:
Business Process Choreographer (BPC) Explorer (Advanced edition)
IBM BPM REST UI
Business Space
Performance Administration
Process Administration
Process Center Console
Heritage Portal
Process Portal
If you run AppScan or a similar security-scanning product against your environment and find a security vulnerability, compare it with the following information. If the vulnerability is not explained by (or fixed with) the following information, and it is a vulnerability in IBM BPM itself and not your customization or infrastructure, report it to IBM Support. Your support representative will request to see the findings report for the scanning software and as much detail as possible and as appropriate. For example, if you are using AppScan, the scan must include the Request/Response information, so be sure to select this option in AppScan before you generate the reports.
The first step in assessing potential vulnerabilities is to understand the exact findings and why they are potentially dangerous. The documentation from your scan tool will help. IBM Security AppScan documents a set of critical vulnerability types, but they tend to produce a significant amount of false positives. See Identify and avoid false positives with IBM AppScan.
Depending on the type of scan (application, infrastructure, etc.) and the scan tool that you use, you might see additional findings about HTTP response headers to enable or control browser protection features, such as X-Frame-Options or Content-Security-Policy. Such headers can be set by applying Security-hardening properties or by adding a header module to the web server in front of IBM BPM. It is strongly recommended that you review the list of possible headers and apply them in your environment as appropriate.
Vulnerability types
Some "types" of findings are reported for several web user interfaces. For those interfaces, the issue, assessment and possible mitigation (if applicable) are described here and referred to later in this document. Note that some findings were not reported in the latest scans. They are still included in this document, as other tools might still report similar findings.
Vulnerability type 1 - Cross-Site Request Forgery (CSRF)
In a CSRF attack, the attacker prepares a malicious web site that causes the victim's browser to send a request to a vulnerable server. For simple requests (HTTP GET and POST with a Content-Type as used in plain HTML form submissions), the victim's browser will just send the request and include all cookies associated with the target URL. The vulnerable server has no means of determining whether the request was sent intentionally by the end user or the end user was tricked into sending that request.
A widely effective protection is checking the HTTP request headers Referer and Origin against an allowlist (formerly called a allowlist). For cross-site requests, browsers include the URL of the current origin in the header. If you know that users access IBM BPM only by using bookmarks or links from some intranet portal, you can add these to an allowlist. For more information, see the Referer header values described in Security-hardening properties (ProcessServer.CsrfProtectionRefererallowlist):
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
The Referer header check has been improved with V8.6 to allow parameter-free GET requests so that other sites can link to web pages like the Process Portal landing page without being added to an allowlist.
The Origin header is typically added if the request was sent as an XMLHttpRequest. Some security researchers have argued that it is more reliable than the Referer header, so it can also be restricted using an allowlist. See Security-hardening properties (ProcessServer.CsrfProtectionOriginallowlist):
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfProtectionOriginallowlist', '-value',
'https://some.server.com, https://some.other.server.com'])
There are edge cases in which the Referer or Origin header check cannot provide full protection, thus penetration testers often demand protection using session-specific tokens. CSRF token protection has been added as an optional feature for URLs that are not public APIs. See Security-hardening properties (ProcessServer.CsrfSessionTokenSalt ProcessServer.CsrfSessionTokenProtectedUris):
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfSessionTokenSalt', '-value', 'verySecret'])
AdminTask.setBPMProperty(['-de', 'De1', '-name',
'ProcessServer.CsrfSessionTokenProtectedUris', '-value',
'/teamworks/ajaxCoach,/teamworks/cs_'])
Vulnerability type 2 - Inadequate Account Lockout
In IBM BPM, the external user repository (such as LDAP) handles the end-user account lockout. For more information, see Configuring the user registry.
An account lockout policy for end users (if desired) should be configured in the external user repository. This ensures account lockout even in cases where password guesses for the same user are entered in many different applications.
By default, at least two administrative (non-human) users are created in a WebSphere file-based repository, which does not provide an account lockout feature. This prevents attackers from locking out administrators, which ensures that the system can be operated at all times. If account lockout is required for these administrative users, it is possible to configure LDAP accounts for them.
Vulnerability type 3 - Session Identifier Not Updated
Web applications maintain session state using session cookies. In some web application frameworks, sensitive information might leak or malicious information might be injected if a session continues to be used after authentication.
IBM BPM enables WebSphere Application Server "session security integration" by default. This feature ensures that a server-side session object can only be accessed by the authenticated user owning the session. The owning user is either the current user that was active during session creation or -- in the case of transitioning from unauthenticated to authenticated state -- the user who first accesses the session. See Session management settings. As a result, sensitive information cannot leak out of session objects tracked by the JSESSIONID cookie by default and there is no need to update the value of JSESSIONID after login.
There are additional cookies that may appear as session tracking. BAYEUX_BROWSER is used by a messaging framework and does not have server side sensitive data associated.
IBM BPM enforces authentication for all "serious" use of the product. That is, unauthenticated users can only access login pages, help and a few other URLs that do not allow the storage of sensitive information in the session. As a result, nothing can be injected into session objects that will be associated with other users.
Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie
Most cookies in IBM BPM do not contain sensitive information or control sensitive product behavior. The two sensitive cookies in IBM BPM are: (1) the authentication cookie, LtpaToken2 by default, and (2) the session cookie, JSESSIONID by default. To prevent browsers from sending these sensitive cookies over non-secure (unencrypted) connections, theses cookies are marked secure by default.
IBM BPM enforces secure connections for all browser-facing web applications since V8.5.7.201703. This change allowed the restriction of the sensitive cookies to secure connections by default, so this type of finding should not appear for the authentication cookie or session cookie.
Some cookies are set by WebSphere Application Server. The WASReqURL cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
IBM BPM enforces authentication for all "serious" use of the product. That is, unauthenticated users can only access login pages, help and a few other URLs that do not allow the storage of sensitive information in the session. As a result, nothing can be injected into session objects that will be associated with other users.
Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie
Most cookies in IBM BPM do not contain sensitive information or control sensitive product behavior. The two sensitive cookies in IBM BPM are: (1) the authentication cookie, LtpaToken2 by default, and (2) the session cookie, JSESSIONID by default. To prevent browsers from sending these sensitive cookies over non-secure (unencrypted) connections, theses cookies are marked secure by default.
IBM BPM enforces secure connections for all browser-facing web applications since V8.5.7.201703. This change allowed the restriction of the sensitive cookies to secure connections by default, so this type of finding should not appear for the authentication cookie or session cookie.
Some cookies are set by WebSphere Application Server. The WASReqURL cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
Characteristic URLs
Understanding the purpose of some URLs and URL patterns helps in the assessment of potential security vulnerabilities.
URLs that contain ibm_security_logout do not refer to a file, but instead refer to a generic URL component for logging users out. Variants of this URL pattern return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file. You might see findings like the following ones for this URL: Alternate Version of File Detected, Archive File Download, and Temporary File Download. These findings are false positives.
A URL that contains j_security_check is a URL pattern used for logging in. This URL triggers authentication on the base WebSphere Application Server product and generally does not involve any SQL execution in databases. Blind SQL injection has been reported for this URL pattern, because multiple variants of the same request returned the same response. This is expected during login and was thus declared a false positive.
URLs that start with /rest/bpm/wle/v1/coachflow/service/ indicate the invocation of a nested service inside a client-side human service (CSHS). While this REST API is implicitly invoked by the CSHS browser-side runtime, the selection of the server-side service (including the parameters it accepts) is part of a custom process application. Server-side services cannot be invoked by default. Nesting a server-side service in a CSHS exposes this service to users who are authorized to invoke the CSHS and who execute a currently active instance of the CSHS. If the server-side service has a very broad or generic interface, such as one that accepts a full SQL query or string parameters that are carelessly concatenated into SQL queries, then nesting such a server-side service in a CSHS creates an SQL injection vulnerability. SQL injection findings for these URL patterns tend to be real vulnerabilities, but caused by custom code. Inspect the service invocation and parameters to identify the vulnerable process app and ensure that you only nest services with very lean and specific interfaces into a CSHS.
SQL-like queries and CMIS
The Content Management Interoperability Services (CMIS) standard features an SQL-like query language that is used to interact with documents in the embedded IBM BPM document store. In certain circumstances, a service call invoked with a CMIS query input parameter can be flagged as an SQL injection vulnerability in a scan. However, it is generally a false positive.
The flagged vulnerability always involves a parameter value that uses SQL-like syntax, but the flagged vulnerability is specific to CMIS and its use in document interaction. Although this scenario does not permit SQL injection, the flagged vulnerability might indicate that a custom service is being used that accepts a CMIS query. If the contents of the entire query are accepted as input parameters, the custom service might be subject to injection attacks that will return more results than expected. The content integration services shipped with IBM BPM have been hardened to prevent more properties from being returned, but it does not prevent injection of a new where clause that could cause more documents to be returned.
Although a CMIS query in network traffic is not necessarily susceptible to SQL injection, you should determine whether a flagged vulnerability refers to custom code. If it does, you should determine whether the custom code allows remote users to control too much of the query that is ultimately executed.
In the IBM BPM use of CMIS, there are three different URL patterns that accept parameters. Depending on how syntax is expressed in the parameter values, using CMIS queries for service calls could result in a flagged vulnerability. The three URL patterns include:
- The document controls that are calling the Ajax service. For example, the .../portal/jsp/callService.do service call and its following parameters:
- serviceRef=1.458aa3a5-2d40-4629-b146-75cb8dcf6569
- snapshotId=2064....
- input=...cmisQuery%22%3ASELECT%20cmis%3Aname%2C%20IBM_BPM_Document_FileNameURL...FROM...WHERE...ORDER%20BY...
- The above parameters would vary. However, the value of "input" would include an SQL-like syntax that would mislead the scan tools.
- The REST API for invoking services: /rest/bpm/wle/v1/service/<some_service_ID>
- The REST API for invoking services as part of client-side human service (CSHS) processing: /rest/bpm/wle/v1/coachflow/<some_service_ID>
Product web user interfaces
The following sections describe findings that have been observed when scanning the various user interfaces. Each finding is of one of the following types:
- type: false_positive: can be ignored
- type: config: can be addressed by configuration
- type: assess: needs to be assessed for your environment
BPM Help
There are a number of keywords in the help system that trigger heuristics in AppScan:
- Credit Card Number Pattern Found in
/BPMHelp/topic/com.ibm.wbpm.admin.doc/topics/customizing_offline_install_C.html (type: false _positive): The page defines the width of a table in percent. The decimals happen to match the format of a credit card number. - Database Error Patterns in /BPMHelp/index.jsp (type: false_positive): The keyword "SQL Error" was found on a help page.
- Directory Listing Pattern in /BPMHelp/topic/com.ibm.wbpm.ref.doc/topics/rbpmconfig.html (type: false_positive): The page contains the keyword "parent directory", which is typical for directory listings. However, in this instance it is just part of a text description.
Business Process Choreographer (BPC) Explorer (Advanced edition)
- Cross-Site Request Forgery (type: config): Address this finding by configuration, as described in Vulnerability type 1 - Cross-Site Request Forgery (CSRF).
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- Blind SQL Injection (type: false_positive): The BPCTZ parameter in /bpc/faces/pages/Default.jsp is not used in SQL queries. Under certain circumstances, AppScan monitors this parameter during successful logoff requests. With logoff redirects, several variants of parameter combinations will cause matching HTTP responses. This is a false positive.
- Cacheable SSL Page Found (type: false_positive): Even though it contains a request parameter, the URL /bpc/faces/javax.faces.resource/oamSubmit.js?ln=org.apache.myfaces does not return sensitive dynamic content. Caching is the intended behavior, even if the communication uses HTTPS.
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- oam.Flash.REDIRECT cookie: This cookie does not contain sensitive information.
- Query Parameter in SSL Request (type: false_positive): The following findings refer to parameters that are not sensitive:
- BPCTZ
- ibm_security_logout parameter logoutExitPage
- oamSubmit.js parameter
- Web Application Source Code Disclosure Pattern Found (type: false_positive): AppScan is flagging the content of comments in JavaScript code, not actual source code.
IBM BPM REST UI
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- Credit Card Number Pattern Found (type: false_positive): AppScan flags a number used in IBM BPM that coincidentally matches a credit card number pattern. It is not a credit card number.
- Query Parameter in SSL Request (type: false_positive): The following findings refer to parameters that are not sensitive:
- login.jsp parameter errorMessage
Business Space
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- digest.ignore.state.userID cookie: This cookie does not contain sensitive information.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- HTTP PUT Method Site Defacement (type: false_positive): If you run the security scan as an administrative user with the authority to create pages, AppScan flags this feature as a way for malicious users to deface pages. For users with proper authority, this feature is working as designed and secure.
- Permanent Cookie Contains Sensitive Session Information (type: false_positive): digest.ignore.state.userID cookie: This cookie does not contain sensitive information.
- Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive (type: false_positive):
- /mum/loader parameter path
- /mum/mycontenthandler parameter uri
- /mum/loader parameter type
- /mum/loader parameter name
- /mum/loader parameter locale
- /mum/mycontenthandler parameter digest
Performance Administration
- Cross-Site Request Forgery (type: config): Address this finding by configuration, as described in Vulnerability type 1 - Cross-Site Request Forgery (CSRF).
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- Blind SQL Injection (type: false_positive): This is a false positive. The following parameters in the AppScan findings are not used in SQL queries:
- /PerformanceAdmin/console/instrumentation/refresh parameter userVisibleOnly
- /PerformanceAdmin/console/UpdateDataTransferErrors.do parameter deleteAll
- /PerformanceAdmin/console/UpdateLoadQueue.do parameter deleteAll
- Compressed Directory Found (type: false_positive): This is a false positive. The folders /PerformanceAdmin/console/instrumentation/admin/ and /PerformanceAdmin/console/instrumentation/ are part of a generic URL that accepts additional path parameters, but has a default response for anything else.
Process Administration
- Cross-Site Request Forgery (type: config): Address this finding by configuration, as described in Vulnerability type 1 - Cross-Site Request Forgery (CSRF).
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- isBidi cookie: This cookie does not contain sensitive information.
- Teamworks cookie: This cookie does not contain sensitive information.
- lombardi.locale.name cookie: This cookie does not contain sensitive information.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- MongoDB NoSQL Injection for URL /bpm/system/login (type: false_positive): There is no interaction with any persistence layer for this API call. It merely calculates and returns a token. This is a false positive.
Process Center Console
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
Heritage Portal
- Cross-Site Request Forgery (type: config): Address this finding by configuration, as described in Vulnerability type 1 - Cross-Site Request Forgery (CSRF).
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- BusinessSpaceHelp/advanced/search.jsp cookies wset_criteria1, synchToc, wset_contents1, filter, cookiesEnabled: These cookies do not contain sensitive information.
- BAYEUX_BROWSER cookie: This cookie does not contain sensitive information.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- HTTP PUT Method Site Defacement (type: false_positive): If you run the security scan as an administrative user with the authority to create pages, AppScan flags this feature as a way for malicious users to deface pages. For users with proper authority, this feature is working as designed and secure.
- Session Not Invalidated After Logout (type: false_positive): By design, IBM WebSphere Application Server does not invalidate LTPA tokens, but rather directs the browsers to reset their values. The following default settings protect the LTPA cookie to an extent that only an attacker with physical access to the client machine or acting as a man-in-the-middle (like burp suite where the user "clicks away" the certificate warning) can see and copy the LTPA cookie:
- Business Automation Workflow forces HTTPS connections so that there is no unencrypted http:// traffic.
- The LTPA cookie has the secure flag set, which instructs browsers to never send the cookie over an unencrypted connection.
- The LTPA cookie has the httpOnly flag set, which instructs browsers to never expose the cookie or its value when browser side JavaScript (regardless from which origin) attempts to access the list of cookies on the current site. This mitigates cross-site-scripting threats.
- WebDAV MKCOL Method Site Defacement (type: false_positive): If you run the security scan as an administrative user with the authority to create pages, AppScan flags this feature as a way for malicious users to deface pages. For users with proper authority, this feature is working as designed and secure. In IBM BPM 8.6, WebDAV HTTP methods need to be explicitly enabled.
- MongoDB / NoSQL injection for a URL starting with /rest/bpm/wle/v1/service/1.5d7ad0de-b56d-4d07-a2c4-b58584b42eeb for parameter searchFilter (type: false_positive): AppScan manipulated the searchFilter and observed different sets of tasks in the response. This is expected if different sets of tasks qualify depending on the searchFilter parameter.
Process Portal
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- oam.Flash.REDIRECT cookie: This cookie does not contain sensitive information.
- BAYEUX_BROWSER cookie: This cookie does not contain sensitive information.
- Typical findings for ibm_security_logout (type: false_positive): File Detected, Archive File Download, and Temporary File Download.
- Typical findings for j_security_check (type: false_positive): Blind SQL Injection.
- Cacheable SSL Page Found (type: false_positive): Even though it contains a request parameter, the login page and the main /ProcessPortal/portal URL does not return sensitive dynamic content. Caching is acceptable.
- Query Parameter in SSL Request (type: false_positive): The following findings refer to parameters that are not sensitive: /teamworks/script/coachNG/dojo/1.10.4/dojo/dojo.js?build=201601161247
- MongoDB / NoSQL injection for a URL starting with /rest/bpm/wle/v1/service/1.5d7ad0de-b56d-4d07-a2c4-b58584b42eeb for parameter searchFilter (type: false_positive): AppScan manipulated the searchFilter and observed different sets of tasks in the response. This is expected if different sets of tasks qualify depending on the searchFilter parameter.
- Blind SQL injection for:
-
- /rest/bpm/wle/v1/service/1.66c1cf8c-410f-429c-88df-5d2acdb3468f parameter searchFilter (type: false_positive): The value of this parameter is not used directly in SQL queries. It contributes a filter condition for a full text index search and thus might impact the final query result. Malicious characters from this parameter value cannot be used in SQL.
- /teamworks/executeServiceByName parameter processApp (type: false_positive): The parameter value is properly neutralized before being used in an SQL query.
- /teamworks/executeServiceByName parameter tw.local.processAppId (type: false_positive): The parameter value is properly neutralized before being used in an SQL query.
-
- Inadequate Account Lockout (type: assess): See Vulnerability type 2 - Inadequate Account Lockout.
- Session Identifier Not Updated (type: false positive): See Vulnerability type 3 - Session Identifier Not Updated.
- Missing Secure Attribute in Encrypted Session (SSL) Cookie (type: false_positive): See Vulnerability type 4 - Missing Secure Attribute in Encrypted Session (SSL) Cookie.
- BAYEUX_BROWSER: This cookie does not contain sensitive information.
- lombardi.locale.name: This cookie does not contain sensitive information.
- isBidi: This cookie does not contain sensitive information.
- Password Parameter in Query for several URLs starting with /rest/bpm/wle/pd/v1, parameter avoidBasicAuthChallenge (type: false_positive): This parameter is an indicator for server-side code that the client is a browser and would like to treat expiration of the authentication session in its JavaScript code - rather than triggering the implicit browser challenge caused by a HTTP 401 response with response header www-authenticate set to Basic. No passwords are transmitted.
[{"Product":{"code":"SSFPJS","label":"IBM Business Process Manager"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"8.6.0.0","Edition":"IBM Business Process Manager Server;IBM Business Process Manager Server Express","Line of Business":{"code":"LOB45","label":"Automation"}}]
Product Synonym
BPM
Was this topic helpful?
Document Information
Modified date:
14 September 2022
UID
swg22008626