Privilege escalation (PR) from edit right through form elements in HTML macros

Steps to reproduce:

1. As a user without script or programming right, edit the sheet of a document or create a new sheet and bind it to a document. I suggest to edit Help.Applications.Movies.Code.MoviesSheet for the reproduction steps.
2. Change the content of the sheet to 

   {{html}}
   <input type="hidden" name="content" value="{{groovy}}println(&quot;Hello from Groovy!&quot;)" />
   {{/html}} 

3. Get an admin user to edit the document that uses the sheet.
4. View the edited document without sheet (add sheet= to the URL parameters).

Expected result:

No text Hello from Groovy! is displayed.

Actual result:

The text Hello from Groovy! is displayed.

The attack might seem a bit artificial as it seems unlikely for the admin to click the "Save"-button on an empty document. However, the attack can be adapted by, e.g., integrating some text in the sheet. Also, there could be inputs displayed. Without script right, I think it is not possible to differentiate between edit and view mode so everything would be displayed in both modes but I think in particular this broken view could actually get admins to perform an edit in order to attempt to fix the mess. Further, the attacker could also directly send the attacker to the edit action or the admin could get there, e.g., through a LiveTable that displays all entries and provides direct edit links. In this case, a plausible edit form could be constructed using the HTML macro that could even contain values for all properties (they would need to be static values, though).

In a similar attack, an attacker could create a fake login form that submits the login information to an attacker-controlled server.

The proposed fix is to forbid form-related HTML tags (form, input, select, submit, textarea, datalist) in the HTML sanitizer. This would affect only users without script right.