OC home page not loading due to changes in wasp content security policy
Article ID: 440972
Updated On:
Products
Issue/Introduction
This case has been opened to track if these vulnerabilities were 100% covered in CU7.
1.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWEID 89):
Description:
This database query contains a SQL injection flaw. The function call constructs a dynamic SQL query using a variable derived from untrusted input. An attacker could exploit this flaw to execute arbitrary SQL queries against the database.
2.Inclusion of Functionality from Untrusted Control Sphere (CWE ID 829)
3.Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') (CWE ID757)
Environment
- DX UIM 23.4 CU5
Cause
- vulnerabilities
Resolution
Update on the three vulnerabilities mentioned in the defect:
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWEID 89):
This has been addressed in the CU7 release.
Here is the mitigation plan for the two other vulnerabilities mentioned.
CWE ID 829:
To secure our UIM web application, we implement a Content Security Policy (CSP) header. A CSP is an HTTP response header that instructs browsers on which sources of content, such as scripts, styles, and images, are trusted and allowed to load. This serves as a critical defense against Cross-Site Scripting (XSS) and data injection attacks by enabling site operators to restrict resource origins and significantly reduce the attack surface.
As part of our CSP configuration, we currently use the directives 'unsafe-inline' and 'unsafe-eval'.
'unsafe-inline' permits the use of inline <script> tags, inline event handlers (e.g., onclick), and inline <style> tags.
'unsafe-eval' allows execution of dynamically generated code through functions such as eval(), setTimeout(), and new Function().
However, both directives have some security risks, so the customer scans show those as vulnerable. To mitigate these risks, more secure alternatives such as nonces or hashes should be used.
Nonces have already been partially implemented in OC and AC. We will coordinate with Product Management to initiate a feature request for fully implementing nonce-based CSP as a replacement for the current use of 'unsafe-inline' and 'unsafe-eval'.
CWE ID 757:
Whenever the customer has enabled HTTPS, during a TLS handshake, the client (browser) sends a list of supported cipher suites to the server. The server compares this list with its own supported cipher suites, configured in the wasp.cfg https_ciphers setting and selects the most secure mutually supported suite. Both parties then use this agreed-upon cipher suite for the remainder of the session.
We maintain a list of supported cipher suites in wasp.cfg that are used during the handshake process. With each release, this list is reviewed and updated to remove any vulnerable or deprecated ciphers.
If a customer is running an older version of UIM, it may still include cipher suites that are now considered insecure. As a result, security scans may flag these as vulnerabilities.
In such cases, customers can manually remove the insecure cipher suites from the wasp.cfg file manually (no other alternative for this). However, the set of usable cipher suites also depends on the CA certificate and the overall TLS configuration in use.
Vulnerabilities status in CU7 release:
This is planned for work under feature ID F166346: Migrate from using unsafe directives to nonces in CSP.
Timeline is currently TBD - will try to get it covered by DX UIM 23.4 CU10, pending prioritization.
Feedback
