[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[ https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836323#comment-16836323 ] Jacques Le Roux commented on OFBIZ-10054: - See my last comment about AntiSamy API in OFBIZ-10187. It clarifies that we still prefer to use https://github.com/OWASP/java-html-sanitizer > Product content management screen doesn't validate trusted users' input > --- > > Key: OFBIZ-10054 > URL: https://issues.apache.org/jira/browse/OFBIZ-10054 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacopo Cappellato >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01, 16.11.06, 18.12.01 > > > Steps to recreate: > 1) go to (authenticate with admin/ofbiz): > https://localhost:8443/catalog/control/EditProductContent?productId=WG- > 2) set the content of the field labeled "Large Image" to: > non_existent.foo onerror=alert(Hi!); > 3) visit the url: > https://localhost:8443/ecommerce/control/product?product_id=WG- > A popup message will appear with the "Hi!". > Thanks to Loris Nardo for the report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[ https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836265#comment-16836265 ] Jacques Le Roux commented on OFBIZ-10054: - About my comment above bq. 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... Before asking them I remembered that the AntiSamy API has not been updated since 2013, so should be considered as somehow deprecated (it's a century in term of security). > Product content management screen doesn't validate trusted users' input > --- > > Key: OFBIZ-10054 > URL: https://issues.apache.org/jira/browse/OFBIZ-10054 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacopo Cappellato >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01, 16.11.06, 18.12.01 > > > Steps to recreate: > 1) go to (authenticate with admin/ofbiz): > https://localhost:8443/catalog/control/EditProductContent?productId=WG- > 2) set the content of the field labeled "Large Image" to: > non_existent.foo onerror=alert(Hi!); > 3) visit the url: > https://localhost:8443/ecommerce/control/product?product_id=WG- > A popup message will appear with the "Hi!". > Thanks to Loris Nardo for the report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[ https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836262#comment-16836262 ] Jacques Le Roux commented on OFBIZ-10054: - About my comment above bq. 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... Before asking them I remembered that the AntiSamy API has not been updated since 2013, so should be considered as somehow deprecated (it's a century in term of security). > Product content management screen doesn't validate trusted users' input > --- > > Key: OFBIZ-10054 > URL: https://issues.apache.org/jira/browse/OFBIZ-10054 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacopo Cappellato >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01, 16.11.06, 18.12.01 > > > Steps to recreate: > 1) go to (authenticate with admin/ofbiz): > https://localhost:8443/catalog/control/EditProductContent?productId=WG- > 2) set the content of the field labeled "Large Image" to: > non_existent.foo onerror=alert(Hi!); > 3) visit the url: > https://localhost:8443/ecommerce/control/product?product_id=WG- > A popup message will appear with the "Hi!". > Thanks to Loris Nardo for the report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[ https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836222#comment-16836222 ] Jacques Le Roux commented on OFBIZ-10054: - At r1858977 I had to add bq. compile 'org.apache.commons:commons-lang3:3.9' in build.gradle of R16, not in others, not sure why. > Product content management screen doesn't validate trusted users' input > --- > > Key: OFBIZ-10054 > URL: https://issues.apache.org/jira/browse/OFBIZ-10054 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacopo Cappellato >Assignee: Jacques Le Roux >Priority: Major > Fix For: 17.12.01, 16.11.06, 18.12.01 > > > Steps to recreate: > 1) go to (authenticate with admin/ofbiz): > https://localhost:8443/catalog/control/EditProductContent?productId=WG- > 2) set the content of the field labeled "Large Image" to: > non_existent.foo onerror=alert(Hi!); > 3) visit the url: > https://localhost:8443/ecommerce/control/product?product_id=WG- > A popup message will appear with the "Hi!". > Thanks to Loris Nardo for the report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[ https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836110#comment-16836110 ] Jacques Le Roux commented on OFBIZ-10054: - 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|https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet]. But as shown with the current issue [there are other types of possibles attacks|https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Event_Handlers]. # 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.|https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project#Stage_2_-_Choosing_a_base_policy_file]. To be safer a [policy inspired by Slashdot|https://github.com/andresriancho/owaspantisamy/blob/master/Java/antisamy-smoketest/src/main/webapp/WEB-INF/policies/antisamy-slashdot.xml] 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] Anyway, my proposition of using HtmlEncoder::sanitize inside UtilCodec.checkStringForHtmlStrictNone() was wrong. Because they don't achieve the same goal. One rejects, the other modifies, with the hope to make the result safer (can't be 100% guaranteed). Greg's solution don't work either for the same reason. With UtilCodec.checkStringForHtmlStrictNone(), we need to reject not change. I have committed a solution which rejects any js event in: trunk r1858965 R18 r1858966 R17 r1858967 R16 r1858969 According to https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet there are 2 other types of cases which are not covered by rejecting less-than (<) and greater-than (>) symbols: # [US-ASCII_encoding|https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#US-ASCII_encoding] # Flash As I commented in code for: # All our Tomcat connectors use UTF-8, so not a problem # We don't care about Flash now rather deprecated in last versions of major browsers. And actually we don't use Flash OOTB at all > Product content management screen doesn't validate trusted users' input > --- > > Key: OFBIZ-10054 > URL: https://issues.apache.org/jira/browse/OFBIZ-10054 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: Trunk, Release Branch 16.11 >Reporter: Jacopo Cappellato >Assignee: Jacques Le Roux >Priority: Major > > Steps to recreate: > 1) go to (authenticate with admin/ofbiz): > https://localhost:8443/catalog/control/EditProductContent?productId=WG- > 2) set the content of the field labeled "Large Image" to: > non_existent.foo onerror=alert(Hi!); > 3) visit the url: > https://localhost:8443/ecommerce/control/product?product_id=WG- > A popup message will appear with the "Hi!". > Thanks to Loris Nardo for the report. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10054) Product content management screen doesn't validate trusted users' input
[
https://issues.apache.org/jira/browse/OFBIZ-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292756#comment-16292756
]
Jacques Le Roux commented on OFBIZ-10054:
-
Here are the most relevant parts of the discussion held in the OFBiz private
security at the time of the disclosure by Loris Nardo. I think they can help
here.
Jacopo wrote
My suggestion is to fix this by editing the service definition for service
"updateProductContent" by setting allow-html="safe" on a few fields
(small/medium/large images and a few others).
However there are some fields where embedding html should be allowed and this
will still allow authenticated malicious backend users to cause similar
problems: for this reason I don't think we should treat this report as an
official security vulnerability (with CVE etc...): all in all an authenticated
malicious user may cause any kind of troubles in the system.
So I would suggest to treat it as an enhancement to security rather than a
security vulnerability.
Gregory answered to Jacopo:
If there are fields where html is needed and we can authorize a specific set of
html tags the following solution can fit.
All the content is html encoded and then a regex is applied to replace all
encoded tags by the authorized html tag.
Example:
{code}
