ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
Date Thu, 09 May 2019 12:25:00 GMT

    [ 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)

Mime
View raw message