RTE is shortening div tags | Community
Skip to main content
J
josiahh94050133
Level 2
March 22, 2019
Solved

RTE is shortening div tags

  • March 22, 2019
  • 4 replies
  • 3261 views

We use the source edit options (misctools) in an overlaid Rich Text Editor component.

It works well for the most part, however empty div tags are getting shortened, so:

<div class="some-data-class"></div>

becomes:

<div class="some-data-class" />

This is breaking inclusion of dynamic markup via our javascript.

The div tag is not a void element, so I'm wondering why this is happening.

I've looked into settings for the RTE, but have yet to find a setting that would be related.

I think it may be related more to the XSS API. If I change the sightly display context to "unsafe" the issue goes away.

We cannot leave it in this context though as we need to ensure the XSS policy is enforced in all our RTEs.

Is there a XSS rule I can apply to prevent the shortening?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by josiahh94050133

I figured out the issue,

The problem was caused by this line in the XSS policy:

<directive name="useXHTML" value="true" />

Per the OSASP documentation, this will output the sanitized data in XHTML format as opposed to just regular HTML:

https://www.owasp.org/index.php/AntiSamy_Directives

Changing the value to "false" allows the sanitized markup to be output as standard HTML.

Block level elements are not shortened and made invalid.

4 replies

U
Adobe Employee
user05162Adobe Employee
Adobe Employee
March 22, 2019

Check the error.log for an error similar to [1].

If thats the case, You can overlay the "/libs/cq/xssprotection/config.xml" and update the security rules as per your business needs but that will expose AEM instance to cross-site scripting and not recommended by Adobe

For more details check [2]

[1]

25.02.2019 18:29:31.815 *INFO* [10.98.144.110 [1551119371795] GET /content/support/en_US/security.html HTTP/1.1] org.apache.sling.xss.impl.HtmlToHtmlContentContext AntiSamy warning: The a tag contained an attribute that we could not process. The rel attribute had a value of "noopener noreferrer". This value could not be accepted for security reasons. We have chosen to remove this attribute from the tag and leave everything else in place so that we could process the input.

[2] https://helpx.adobe.com/ca/experience-manager/6-2/sites/developing/using/security.html

Gaurav-Behl
Gaurav-Behl
Level 10
March 22, 2019

If changing it to unsafe fixes the issue then its xss issue

refer - Re: RTE Plugin modifying HTML || Removing JS functions like onClick=""

J
josiahh94050133Author
Level 2
March 22, 2019

Hi. Thank you for responding.

I'm already overlaying the xss policy configuration, as we have some custom attributes that need to be allowed in certain tags.

Note, this does not expose an instance to XSS attacks as the policy is still enforced.

When I view the error.log file while loading the page with this issue, I don't see any messages generated related to AntiSamy, or package org.apache.sling.xss.impl.HtmlToHtmlContentContext.

So either the issue is not caused by the XSS policy, or the Granite XSS API is only logging attribute filters and not tag/elements themselves.

Is there a XSS rule that would prevent a closing tag from being shortened?

Since divs are block level tags, this is not valid HTML:

<div class="some-data-class" />

J
josiahh94050133AuthorAccepted solution
Level 2
March 22, 2019

I figured out the issue,

The problem was caused by this line in the XSS policy:

<directive name="useXHTML" value="true" />

Per the OSASP documentation, this will output the sanitized data in XHTML format as opposed to just regular HTML:

https://www.owasp.org/index.php/AntiSamy_Directives

Changing the value to "false" allows the sanitized markup to be output as standard HTML.

Block level elements are not shortened and made invalid.

Terms & ConditionsAccessibility statement

Loading footer...