Residual risk after limiting the usage of unsafe-eval and unsafe-inline

Issue

• Can the derivatives unsafe-eval and unsafe-inline be exploited? If yes, how it is done?
• What is the residual risk associated with this?
• Can Content Security Policy (CSP) be resolved by adding a reverse Proxy?

Environment

• Liferay DXP [all versions]

Resolution

1. Unfortunately, the DXP may not be able to fully function without unsafe-inline and unsafe-eval once the Content-Security-Policy HTTP header has been defined.
2. The nonce has been implemented already in the portal also but the hash is not.
3. Meanwhile, there are also some parts of the CSP support implemented that are still in Beta status and it is not supported.
4. Applying the nonce, which has already been implemented in the portal (but also in Beta) can be an alternative way of handling unsafe-inline and unsafe-eval that users can try, but there is no guarantee that the portal will properly work with it.
5. However, there are plans to work on finalizing the support of the CSP step by step under the LPD-16463 initiative.
6. The current planned steps are in the LPD-18227 epic within the initiative.
7. With the current existing implementation of the Content Security Policy (CSP), it is a must to allow the derivatives 'unsafe-eval' and 'unsafe-inline'.
8. Moreover, if the attacker can inject style or script (exploiting a vulnerability in some frontend library), then they can make the browser run inline scripts for example (eg. onclick="something()")
9. Liferay has an alternative option of generating the nonce, however, that is still in beta status as a feature. It does not count if the user sets directives to the CSP header in the portal with the beta feature or in a reverse proxy, the result is going to be the same.
10. DXP has originally not been designed with the CSP in mind and this is difficult to refactor such an application like the DXP according to a new “standard” like CSP. This is why Liferay always tries to address specific potential vulnerabilities one by one.
11. Talking about the residual risk, the weak points are the 3rd parties and reflected XSS that may be somewhere in DXP still undiscovered.
12. As for 3rd parties, the most obvious example is the CKEditor v4 which is integrated in the DXP and doesn’t support CSP at all. Even if self for script-src is used, the unsafe-inline has to be used, which may keep the doors open through contents edited through the CKEditor v4. However, Liferay has been working on changing that to v5 which might take some time.
13. Regarding undiscovered XSS, this case is not different from any kind of vulnerability in general. Liferay is handling all of them one by one according to the general security vulnerability handling process handling all of them according to a well-defined, standard-like risk assessment.
14. Applying nonce is a nice partial mitigation even when unsafe-inline could be exploited. That works out of the box only if the CSP support beta feature is enabled, though.
15. Unfortunately, Liferay cannot give such a residual risk assessment which could be reliable. As mentioned earlier, the problems that might come are still undiscovered, hence Liferay can analyze and assess vulnerabilities when they become known.

Additional Information

• CSP headers are not working on DXP-7.4
• Content-Security-Policy Header Integration