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 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.5.6 has been scanned with IBM Security AppScan V9.0.1 for application (not infrastructure) vulnerabilities. This technote describes the false positives reported by AppScan on base IBM BPM web interfaces, which means not process applications built on top of IBM BPM. Because IBM BPM is a development tool that contains a set of components you use to build process applications, AppScan cannot exercise all of the potential code that is part of IBM BPM.
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.1 finds in IBM BPM V8.5.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 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.5.6 has been scanned with IBM Security AppScan V9.0.1 for application (not infrastructure) vulnerabilities. This technote describes the false positives reported by AppScan on base IBM BPM web interfaces, which means not process applications built on top of IBM BPM. Because IBM BPM is a development tool that contains a set of components you use to build process applications, AppScan cannot exercise all of the potential code that is part of IBM BPM.
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.1 finds in IBM BPM V8.5.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.5.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 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.
Business Process Choreographer (BPC) Explorer (Advanced edition)
Alternate Version of File Detected: URLs that contain ibm_security_logout do not refer to a file, but 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.
Archive File Download: URLs that contain ibm_security_logout do not refer to a file, but to a generic URL component for logging users out. Variants of this URL pattern that include file extensions such as .arc or .zip return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file.
Blind SQL Injection: The BPCTZ parameter in /bpc/faces/pages/Default.jsp is not used in SQL queries. Under certain circumstances, AppScan monitors this parameter during successful log off requests. With log off redirects, several variants of parameter combinations will cause matching HTTP responses. This is a false positive.
Cacheable SSL Page Found: 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.
Cross-Site Request Forgery: Multiple findings that you can fix by configuring the environment to allowlist (formerly called allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive:
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Temporary File Download: URLs that contain ibm_security_logout do not refer to a file, but to a generic URL component for logging users out. Variants of this URL pattern that include file extensions such as .arc or .zip return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file.
Web Application Source Code Disclosure Pattern Found: AppScan is flagging the content of comments in JavaScript code, not actual source code.
IBM BPM REST UI
Blind SQL Injection: The ibm_security_check parameter is not used in SQL queries. Under certain circumstances, AppScan monitors this parameter during successful log off requests. With log off redirects, several variants of parameter combinations will cause matching HTTP responses. This is a false positive.
Credit Card Number Pattern Found: AppScan flags a number used in IBM BPM that coincidentally matches a credit card number pattern. It is not a credit card number.
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive:
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Business Space
HTTP PUT Method Site Defacement: 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.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
Permanent Cookie Contains Sensitive Session Information:
Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive:
Performance Administration
Alternate Version of File Detected: URLs that contain ibm_security_logout do not refer to a file, but 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.
Blind SQL Injection: This is a false positive. The following parameters in the AppScan findings are not used in SQL queries:
Compressed Directory Found: 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.
Cross-Site Request Forgery: You can fix this finding by configuring the environment to allowlist (formerly called a allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Unencrypted Login Request: Remove this finding by disabling HTTP in your web server configuration.
Process Administration
Blind SQL Injection: This is a false positive. The j_security_check parameters in the AppScan findings are not used in SQL queries.
Cross-Site Request Forgery: You can fix this finding by configuring the environment to white-list acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Process Center Console
Blind SQL Injection: This is a false positive. The j_security_check parameters in the AppScan findings are not used in SQL queries.
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Process Portal
Cross-Site Request Forgery: You can fix this finding by configuring the environment to allowlist (formerly called a allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
HTTP PUT Method Site Defacement: 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: This is a 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:
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
WebDAV MKCOL Method Site Defacement: 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.
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 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.
Business Process Choreographer (BPC) Explorer (Advanced edition)
Alternate Version of File Detected: URLs that contain ibm_security_logout do not refer to a file, but 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.
Archive File Download: URLs that contain ibm_security_logout do not refer to a file, but to a generic URL component for logging users out. Variants of this URL pattern that include file extensions such as .arc or .zip return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file.
Blind SQL Injection: The BPCTZ parameter in /bpc/faces/pages/Default.jsp is not used in SQL queries. Under certain circumstances, AppScan monitors this parameter during successful log off requests. With log off redirects, several variants of parameter combinations will cause matching HTTP responses. This is a false positive.
Cacheable SSL Page Found: 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.
Cross-Site Request Forgery: Multiple findings that you can fix by configuring the environment to allowlist (formerly called allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
- WASReqURL cookie: This cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
- oam.Flash.REDIRECT cookie: This cookie does not contain sensitive information.
- LTPA cookie: Configure your environment to require SSL for Lightweight Third Party Authentication (LTPA). See Single sign-on settings.
- JSESSIONID: Configure your environment to require SSL for session cookies, see Cookie settings.
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive:
- BPCTZ
- ibm_security_logout parameter logoutExitPage
- oamSubmit.js parameter in
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Temporary File Download: URLs that contain ibm_security_logout do not refer to a file, but to a generic URL component for logging users out. Variants of this URL pattern that include file extensions such as .arc or .zip return an HTTP 200 (OK) status code, which AppScan falsely interprets as successful access to a similarly named file.
Web Application Source Code Disclosure Pattern Found: AppScan is flagging the content of comments in JavaScript code, not actual source code.
IBM BPM REST UI
Blind SQL Injection: The ibm_security_check parameter is not used in SQL queries. Under certain circumstances, AppScan monitors this parameter during successful log off requests. With log off redirects, several variants of parameter combinations will cause matching HTTP responses. This is a false positive.
Credit Card Number Pattern Found: AppScan flags a number used in IBM BPM that coincidentally matches a credit card number pattern. It is not a credit card number.
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
- WASReqURL cookie: This cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
- LTPA cookie: Configure your environment to require SSL for Lightweight Third Party Authentication (LTPA). See Single sign-on settings.
- JSESSIONID: Configure your environment to require SSL for session cookies, see Cookie settings.
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Query Parameter in SSL Request: The following findings refer to parameters that are not sensitive:
- login.jsp parameter errorMessage
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Business Space
HTTP PUT Method Site Defacement: 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.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
- digest.ignore.state.userID cookie: This cookie does not contain sensitive information.
Permanent Cookie Contains Sensitive Session Information:
- 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:
- /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
Alternate Version of File Detected: URLs that contain ibm_security_logout do not refer to a file, but 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.
Blind SQL Injection: 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: 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.
Cross-Site Request Forgery: You can fix this finding by configuring the environment to allowlist (formerly called a allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Unencrypted Login Request: Remove this finding by disabling HTTP in your web server configuration.
Process Administration
Blind SQL Injection: This is a false positive. The j_security_check parameters in the AppScan findings are not used in SQL queries.
Cross-Site Request Forgery: You can fix this finding by configuring the environment to white-list acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
- WASReqURL cookie: This cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
- 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.
- LTPA cookie: Configure your environment to require SSL for Lightweight Third Party Authentication (LTPA). See Single sign-on settings.
- JSESSIONID: Configure your environment to require SSL for session cookies, see Cookie settings.
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Process Center Console
Blind SQL Injection: This is a false positive. The j_security_check parameters in the AppScan findings are not used in SQL queries.
Inadequate Account Lockout: In IBM BPM the external user repository, for example LDAP, handles the end user account lockout. For more information, see Configuring external security providers.
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
Process Portal
Cross-Site Request Forgery: You can fix this finding by configuring the environment to allowlist (formerly called a allowlist) acceptable REFERER header values. For example, use the following Jython:
AdminTask.setBPMProperty(['-de', 'De1', '-name', 'ProcessServer.CsrfProtectionRefererallowlist', '-value', 'server1.example.com, server2.example.com'])
For more information, see Configuring Cross-Site Request Forgery (CSRF) protection in IBM Business Process Manager (BPM).
HTTP PUT Method Site Defacement: 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: This is a 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.
Missing Secure Attribute in Encrypted Session (SSL) Cookie:
- WASReqURL cookie: This cookie does not contain sensitive information. For more information, see WASRequrl cookie does not contain any sensitive information.
- BusinessSpaceHelp/advanced/search.jsp cookies wset_criteria1, synchToc, wset_contents1, filter, cookiesEnabled: These cookies do not contain sensitive information.
- LTPA cookie: Configure your environment to require SSL for Lightweight Third Party Authentication (LTPA). See Single sign-on settings.
- JSESSIONID: Configure your environment to require SSL for session cookies, see Cookie settings.
Forcing the Secure flag for cookies ensures that browsers do not transmit the cookie over an unencrypted HTTP connection. Configure the web server in front of IBM BPM to accept only HTTPS traffic so that the Secure flag can be added with no functional impact. Adding the Secure flag in an environment that accepts unencrypted HTTP traffic can break some browser scenarios.
For example, use the following Jython:
AdminTask.configureSingleSignon('-requiresSSL true')
for cookie in AdminUtilites.convertToList(AdminConfig.list('Cookie')):
AdminConfig.modify(cookie, [['secure','true']])
Session Identifier Not Updated: With session security integration enabled (the default), anonymous users cannot access a session that a named user owns. For more information, see Session management settings.
WebDAV MKCOL Method Site Defacement: 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.
[{"Product":{"code":"SSFTN5","label":"IBM Business Process Manager Advanced"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"8.5.6","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSFTBX","label":"IBM Business Process Manager Express"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Security","Platform":[{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"8.5.6","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSFTDH","label":"IBM Business Process Manager Standard"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"","label":"Linux zSeries"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"8.5.6","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Product Synonym
BPM
Was this topic helpful?
Document Information
Modified date:
01 March 2022
UID
swg21697146