WW-5084: Add Content Security Policy support to Struts

[salcho]

Hello Struts Devs!

This PR adds Content Security Policy support for Struts 2. A very popular security mitigation against XSS and other injection vulnerabilities. CSP comes in many flavours, but we've chosen to add support for the most robust of them: nonce-based, strict-dynamic CSP.

Here's a summary of these changes:

• Allows users to configure whether CSP is enabled in reporting or enforcement modes and lets them set a report URI, where violation reports will be sent by the browser.
• Implements a CSP Interceptor that generates a nonce-based, strict-dynamic policy and adds it to HTTP responses according to the user's configuration.
• Implements custom <script> and <link> JSP and FTL tags. These (<s:script> in taglib, for instance) set the nonce attribute on script and link blocks automatically, so that they match the nonce set in the policy. This feature allows developers to use both existing and new script blocks that are compatible with CSP with minimal refactoring.
• Provides a default implementation of a CSP violation report collection endpoint. This allows developers to see CSP reports as they happen in their logs out of the box, with minimal effort. This behaviour is extensible, so developers can customise the processing of CSP reports.
• With these tools, developers can enable CSP in reporting mode, collect reports and identify and refactor existing code that is incompatible with CSP from these reports. Finally, developers will be able to switch CSP to enforcing mode, which will provide a very robust defense against XSS.

Co-authored-by: Ecenaz Jen Ozmen - [email protected]
Co-authored-by: Giannis Chatziveroglou - [email protected]
Co-authored-by: Santiago Diaz - [email protected]

[coveralls]

Coverage increased (+0.3%) to 49.628% when pulling bf80254 on salcho:post-ww-5083 into a55e9ed on apache:master.

[salcho]

This PR is associated with a follow up that refactors existing FTL and JSP files in Struts to make them CSP-ready. This will make it much easier to adopt CSP on an existing application. Please find a draft of this PR here: salcho#6

[lukaszlenart]

LGTM 💯

[salcho]

That's great news @lukaszlenart! Is there anything else we can do to get these merged? :)

[lukaszlenart]

I'm just giving some time to others to allow them review your work :)

[aleksandr-m]

@salcho @lukaszlenart Do we need CspReportAction in the Struts itself? Seems like it is too implementation specific.

[salcho]

Hi @aleksandr-m @lukaszlenart,

Re: CspReportAction. In our experience, many developers are put off of adopting CSP in their applications because collecting reports adds more overhead. We decided to add the CspReportAction class with a default implementation to give those developers the option to either use an out of the box (and useful, since the reports can be seen in logs) implementation or subclass the action and implement custom logic.

Alex, I've pushed a new commit that addresses your comment. Thanks for flagging!

[salcho]

Friendly ping! @aleksandr-m @lukaszlenart

[lukaszlenart]

I'm fine with the current state, LGTM 👍 (but I will let @aleksandr-m hit the button :)

[TheFergus]

@lukaszlenart Hi, for <s: script><s:/script>, if the src of the tags needs variables, what should I do?
<s:script src="${myUrl}"></s:script>

[lukaszlenart]

@TheFergus already answered here struts-community-plugins/struts2-jquery#318 (comment)