Journal Article Editing does not escape user input

• Type: Bug
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: None
• Fix Version/s: None
• Component/s: None
• Labels: None
• Similar Issues: Show 5 results ; ;

  LEP-3479	Double quotes breaks Journal Article text inputs (and propable others too)
  LEP-5170	users cannot see save buttons for edit journal article
  LEP-1274	Journal Content portlet does not display "Add Article" icon for non-admin user
  LEP-3444	Image disappears when you edit the journal article
  LEP-2669	Journal Article Permissioning

User Input in Jounal Article Editing Text-Fields etc. is currently NOT escaped.

This allows editors to inject (harmful) code, i.e. going against CI defined by template, destroying whole site layout/design or even more evil things like injecting XSS Code.

In my opinion it's absolutly necessary to escape user input here - maybe expect Text Areas with WYSIWYG Editor, which allows HTML Code explicitly.

Injecting HTML Code is definitively possible and I promise that this works for SQL-Injections, too.

[Fabian Barney]

Did not find anything to edit this bug:
This issue affects Liferay version 5.1.0 at least.

[Gavin Wan]

Hi Fabian,
The text is in a <![CDATA[ ]]> wrap.
it's can not be save if the ' ]]>' in the text.
02:41:35,765 ERROR [JournalUtil:710] org.dom4j.DocumentException: Error on line 1 of document : The character sequence "]]>" must not appear in content unless used to mark the end of a CDATA section. Nested exception: The character sequence "]]>" must not appear in content unless used to mark the end of a CDATA section.
How can i save the inject codes?

[Raymond Auge]

This should be something like a per-field flag during structure creation, allowing the possibility to produce completely locked down/scrubbed article input forms.

But, we definitely still want to allow unlimited scripting in many cases.

We're in the process of re-writing the Journal Article/Structure Editing UI, and will have configurable per-field validation somewhere in the mix. I can see this being implemented as a validation option (something like "[on|off] Escape Input").

[Fabian Barney]

Hi,

take a structurre with a text input field.
Now insert something like:

Heading <script type="text/javascript" >alert("Hello, I can rewrite the whole page via DOM.");</script>

Since you can rewrite via such an injected Javascript the whole page, you can insert/rewrite any code you like at any point.
The String "]]>" can also be injected by Javascript - just split it in two or more commands like
document.write("]]");
document.write(">");

But this is not necessary - you'll see it when trying the example above.

What Ray says about further extensions sounds good for me. Currently it's not a good idea to give somebody an editor role, when you do not 100% trust him/her.

[Fabian Barney]

Just another suggestion for a solution:
Give Template Designer an extra VM-Method like '$xyz.getEscapedData()'.

I think it should be sufficient when this method returns the same String as 'getData()' but finally passed through Apache Commons StringEscapeUtils.escapeHtml(String) method.