[MGNLFORM-243] HTML is escaped in form fields resulting in HTML characters in passwords (and other fields) ending up in JCR in their escaped form Created: 11/Aug/14  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Closed
Project: Magnolia Form Module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Christian Ringele Assignee: Federico Grilli
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
duplicate
duplicates MGNLFORM-236 Html escaping of form fields should b... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

A customer who looked deep into the Form module validation and field value submission rose this topic (SUPPORT-3873):

1. As for preventing XSS attacks in the form module all inputs are html escaped,
a similar approach should also be considered within the AdminCentral forms. In the AdminCentral all form fields are open to XSS attacks.
It would be favorable, it the used solution would be aligned/comparable to the (new) implementation used in the form module.

2. Which leads to the second points:
He suggests to rethink the XSS html escaping implementation currently used in the form module. It might not be the best way to prevent such attacks.

As this topic is involving two modules, I created it here in the UI section (point 1 seems more important).



 Comments   
Comment by Edgar Vonk [ 12/Aug/14 ]

As a reporter of the original support request my 2 cents: normally to prevent XSS vulnerabilities in a web platform you would implement input validation and output escaping.

The current implementation in the Magnolia Form module supports input validation (using validators such as the NoHTMLValidator) which is nice and does what I guess you could call input escaping. I guess the idea behind the latter is: better safe than sorry; let's HTML escape all form input fields as soon as they come in so that these fields are now safe whatever happens next. Something like that? I guess not such a bad idea except that you certainly do not want to escape all form fields (like passwords), or at least you want to unescape certain fields before you do stuff with them (like put them in the JCR). Maybe the idea here was also to perform the escaping as soon as possible in order to prevent users from forgetting output escaping (which is easy to do)? This seems similar to how rich text content fields (with HTML) are stored by Magnolia in the JCR: escaped. When you want to display them in your template script you need to unescape them first (using cmsfn:decode).

I am not sure what the preferred solution to this issue would be but as mentioned it should allow the following:

  • It should be possible to disable HTML escaping for selected textual form fields (or it should be easy to unescape them before use).
  • The way HTML escaping is done by the Form Module should be aligned by how it is done (currently not at all I think) by the corresponding apps in the centradm (like the security app) when using the same JCR data (such as user passwords or user text fields).
Generated at Mon Feb 12 05:38:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.