[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836331#comment-16836331
]
Jacques Le Roux edited comment on OFBIZ-10187 at 5/9/19 12:24 PM:
------------------------------------------------------------------
h3. Sorry for the digressions in both Jiras below. I needed to clear my mind
and put notes somewhere...
A last note, in OFBIZ-10054 I wrote
{quote}
Actually there are 2 ways used in OFBiz:
# To prevent saving stored XSS scriptings in DB we reject them before. This is
achieved with UtilCodec.checkStringForHtmlStrictNone(). Most of the possible
XSS attacks rely on the less-than (<) and greater-than (>) symbols. But as
shown with the current issue there are other types of possibles attacks.
# Filter HTML texts and remove the unwanted parts. This is done using policies
with HtmlEncoder::sanitize. The default policy is not much permissive. Since
OFBIZ-10187 it's easier to create own more permissive policies. An example
inspired by eBay is available OOTB.. To be safer a policy inspired by Slashdot
could be used. Anyway it's up to you... I should note here though that
currently the AntiSamy API is not used in OFBiz. This is something that still
need to be clarified with the authors of OFBIZ-10187. Maybe it was easier for
them to adapt from XML to Java...
These 2 ways (reject or filter) are somehow discussed here:
https://github.com/OWASP/java-html-sanitizer/blob/master/docs/html-validation.md
{quote}
The most interesting part is at the bottom and says
{quote}
One use case for validation seems to be to allow a comment edit window to warn
about markup that violates a policy instead of dumping a sanitized output on
them and asking them to look past cosmetic differences like changes in case and
entity encoding.
Knowing that an input is invalid does not help narrow down the problematic part
of the input.
This use case seems to be addressable via
{code:java}
String normalizedButNotFiltered = policyThatAllowsEverything.sanitize(input);
String filtered = policy.sanitize(input);
boolean violatedPolicy = !normalizedButNotFiltered.equals(filtered);
{code}
and those two can be structurally compared to narrow down the problematic part.
{quote}
I will have nother look at OFBIZ-10054 and decide if we can't use this way. I
1st wanted to make it works and handling js events in a policy is another story
for another Jira...
was (Author: jacques.le.roux):
h3. Sorry for the digressions in both Jiras below. I needed to clear my mind
and put notes somewhere...
A last note, in OFBIZ-10054 I wrote
{quote}
Actually there are 2 ways used in OFBiz:
# To prevent saving stored XSS scriptings in DB we reject them before. This is
achieved with UtilCodec.checkStringForHtmlStrictNone(). Most of the possible
XSS attacks rely on the less-than (<) and greater-than (>) symbols. But as
shown with the current issue there are other types of possibles attacks.
# Filter HTML texts and remove the unwanted parts. This is done using policies
with HtmlEncoder::sanitize. The default policy is not much permissive. Since
OFBIZ-10187 it's easier to create own more permissive policies. An example
inspired by eBay is available OOTB.. To be safer a policy inspired by Slashdot
could be used. Anyway it's up to you... I should note here though that
currently the AntiSamy API is not used in OFBiz. This is something that still
need to be clarified with the authors of OFBIZ-10187. Maybe it was easier for
them to adapt from XML to Java...
These 2 ways (reject or filter) are somehow discussed here:
https://github.com/OWASP/java-html-sanitizer/blob/master/docs/html-validation.md
{quote}
The most interesting part is at the bottom and says
{quote}
One use case for validation seems to be to allow a comment edit window to warn
about markup that violates a policy instead of dumping a sanitized output on
them and asking them to look past cosmetic differences like changes in case and
entity encoding.
Knowing that an input is invalid does not help narrow down the problematic part
of the input.
This use case seems to be addressable via
String normalizedButNotFiltered = policyThatAllowsEverything.sanitize(input);
String filtered = policy.sanitize(input);
boolean violatedPolicy = !normalizedButNotFiltered.equals(filtered);
and those two can be structurally compared to narrow down the problematic part.
{quote}
I will have nother look at OFBIZ-10054 and decide if we can't use this way. I
1st wanted to make it works and handling js events in a policy is another story
for another Jira...
> OWASP sanitizer breaks proper rendering of HTML code
> ----------------------------------------------------
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: Trunk, 16.11.04, Release Branch 17.12, Release Branch
> 18.12
> Reporter: Michael Brohl
> Assignee: Michael Brohl
> Priority: Critical
> Labels: backport-needed
> Fix For: 17.12.01, 16.11.06, 18.12.01
>
> Attachments:
> OFBIZ-10187_Rewrite-CustomPermissivePolicy-matchesEithe.patch,
> OFBIZ-10187_Sanitizer.patch, OFBIZ-10187_Sanitizer_16.11.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
> <div class="item">
> <img
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg</@ofbizContentUrl>"
> alt="" />
> <div class="container">
> <div class="slider-overlay">
> <h2>Lorem ipsum dolor sit amet</h2>
> <h3>At vero eos et accusam et justo</h3>
> <p>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
> </p>
> <a class="btn btn-grey"
> href="<@ofbizUrl>cms/~webpage_id=100</@ofbizUrl>">weitere Informationen</a>
> </div>
> </div>
> </div>{code}
> will be rendered to
> {code:java}
> <div>
> <img
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg</@ofbizContentUrl>"
> alt="" />
> <div>
> <div>
> <h2>Lorem ipsum dolor sit amet</h2>
> <h3>At vero eos et accusam et justo</h3>
> <p>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
> </p>
> <a
> href="<@ofbizUrl>cms/~webpage_id=100</@ofbizUrl>">weitere Informationen</a>
> </div>
> </div>
> </div>{code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
