Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-1525 Issue to group security concerns
  3. OFBIZ-6506

XSS vulnerability in OFBiz forms and screens especially in display-entity component

    Details

      Description

      In Ofbiz form need to escape characters from description column in a display-entity tag to avoid XSS attacks.

      <display-entity entity-name="Table" description="${description}" >

      I tried to use bsh, as following:

      <display-entity entity-name="Table" description="${bsh: org.apache.commons.lang.StringEscapeUtils.escapeHtml(&quot;${description}&quot;)}">

      But I get this error:

      Error rendering screen [component://my/widget/CommonScreens.xml#GlobalDecorator]: java.lang.IllegalStateException: This object has been flagged as immutable (unchangeable), probably because it came from an Entity Engine cache. Cannot set a value in an immutable entity object. 
      (This object has been flagged as immutable (unchangeable), probably because it came from an Entity Engine cache. Cannot set a value in an immutable entity object.)
      

      PS:
      Also you can see here a similar issue:
      http://stackoverflow.com/questions/30097370/how-to-escape-characters-in-ofbiz-widget

        Activity

        Hide
        jacques.le.roux Jacques Le Roux added a comment - - edited
        For your reference the relevant fixes have been committed with following revision numbers:
        • trunk: 1692357 (branch 15.12 was not yet created, so includes this fix)
        • 14.12: 1692358
        • 13.07: 1692359
        • 12.04: 1692360
        Versions Affected:

        Apache OFBiz 13.07.02 and 13.07.01
        Apache OFBiz 12.04.05 and earlier releases in the series (12.04.*)
        The unsupported releases 11.04.*, 10.04.* and 09.04 versions are also affected (Lilian reported he tried with r691692, which is early March 2008)

        Show
        jacques.le.roux Jacques Le Roux added a comment - - edited For your reference the relevant fixes have been committed with following revision numbers: trunk: 1692357 (branch 15.12 was not yet created, so includes this fix) 14.12: 1692358 13.07: 1692359 12.04: 1692360 Versions Affected: Apache OFBiz 13.07.02 and 13.07.01 Apache OFBiz 12.04.05 and earlier releases in the series (12.04.*) The unsupported releases 11.04.*, 10.04.* and 09.04 versions are also affected (Lilian reported he tried with r691692, which is early March 2008)
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        I reopen this issue to close it properly and credit Lilian for the report of the vunerability which has been attributed the CVE-2015-3268

        Note though that as explained at https://ofbiz.apache.org/download.html, we strongly encourage OfBiz users to report security problems affecting OFBiz to the private security mailing list of the ASF Security Team, before disclosing them in public. Please see the page of the ASF Security Team for further information and contact information. A

        Summary:

        The issue was that in ModelFormField.java we were not encoding not empty data coming from the DB when using the DisplayEntityField.getDescription() method.
        The issue was not possible without an access to the DB. In other words for the XSS to work you needed to have either an admin access or be able to do an SQL injection.
        Anyway in both cases, the description attribute of the display-entity element is now escaped to prevent the risk of this XSS attack.

        Show
        jacques.le.roux Jacques Le Roux added a comment - I reopen this issue to close it properly and credit Lilian for the report of the vunerability which has been attributed the CVE-2015-3268 Note though that as explained at https://ofbiz.apache.org/download.html , we strongly encourage OfBiz users to report security problems affecting OFBiz to the private security mailing list of the ASF Security Team , before disclosing them in public. Please see the page of the ASF Security Team for further information and contact information. A Summary: The issue was that in ModelFormField.java we were not encoding not empty data coming from the DB when using the DisplayEntityField.getDescription() method. The issue was not possible without an access to the DB. In other words for the XSS to work you needed to have either an admin access or be able to do an SQL injection. Anyway in both cases, the description attribute of the display-entity element is now escaped to prevent the risk of this XSS attack.
        Hide
        administractor Lilian Iatco added a comment - - edited

        about first issue described here.. we have this case:

        <display-entity entity-name="Table" description="XSS from DB">

        If we submit this script:

        <input type="image" src="javascript:alert('XSS');">

        as value for description column in DB and after that we go on this form, got js alert.
        Seems that it's not reproducible for this script:

        <script>alert('alert')</script>

        Exists here a way to escape chars in description attribute from component:

        <display-entity
        Show
        administractor Lilian Iatco added a comment - - edited about first issue described here.. we have this case: <display-entity entity-name= "Table" description= "XSS from DB" > If we submit this script: <input type= "image" src= "javascript:alert('XSS');" > as value for description column in DB and after that we go on this form, got js alert. Seems that it's not reproducible for this script: <script>alert('alert')</script> Exists here a way to escape chars in description attribute from component: <display-entity
        Hide
        jacques.le.roux Jacques Le Roux added a comment - - edited

        Something I wanted intially to say but forgot and is not intended to only you Lilian but to all OFBiz contributors: if you ever find real XSS vulnerability, you should not disclose it like Lilian did here (fortunately it's not a real one, as long as not proved otherwise). You should rather follow the process which is explained on the "The Apache Security Team" page: http://www.apache.org/security Note that this page is also referenced in the "Security Vulnerabilities" section at the bottom of "OFBiz download" patge http://ofbiz.apache.org/download.html.

        As it said intially on this page:

        We strongly encourage folks to report security vulnerabilities to one of our private security mailing lists first, before disclosing them in a public forum.

        The rest is explained there...

        Show
        jacques.le.roux Jacques Le Roux added a comment - - edited Something I wanted intially to say but forgot and is not intended to only you Lilian but to all OFBiz contributors: if you ever find real XSS vulnerability, you should not disclose it like Lilian did here (fortunately it's not a real one, as long as not proved otherwise). You should rather follow the process which is explained on the "The Apache Security Team" page: http://www.apache.org/security Note that this page is also referenced in the "Security Vulnerabilities" section at the bottom of "OFBiz download" patge http://ofbiz.apache.org/download.html . As it said intially on this page: We strongly encourage folks to report security vulnerabilities to one of our private security mailing lists first, before disclosing them in a public forum. The rest is explained there...
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        I don't see what you are chasing. If I put

        ?productId=<script>alert('alert')</script>
        

        after an URL, and use

        <field name="productId" tooltip="${uiLabelMap.ProductId} [${productId}]"><text size="20" maxlength="20"/></field>
        

        in a form, after passing the partyId value from a screen with

        <set field="productId" from-field="parameters.productId"/>
        

        This is what I get on screen
        And this is what I see in the HTML source

        <input type="text" name="productId"  value="&lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt;" size="20" maxlength="20" id="addSmsContactPerson_productId" /><script language="JavaScript" type="text/javascript">ajaxAutoCompleter('', false, 2, 300);</script>
        <span class="tooltip">Product Id &#x5b;&lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt;&#x5d;</span>
        

        Of course, same when using your example, which is in no way a mean to show an XSS issue. A JavaScript must be actionable, I think I was pretty clear with the examples I gave above.

        <input type="text" name="productId"   value="&lt;font color&#x3d;red&gt;XSS&lt;&#x2f;font&gt;"  size="20" maxlength="20" id="formName_productId"/><script language="JavaScript" type="text/javascript">ajaxAutoCompleter('', false, 2, 300);</script>
        <span class="tooltip">Product Id &#x5b;&lt;font color&#x3d;red&gt;XSS&lt;&#x2f;font&gt;&#x5d;</span>
        

        So it's now clear to me that this does not show an XSS vulnerability and I close this issue as invalid.

        A last question though, which version are you using? I used the trunk HEAD but normally none of the supported versions have XSS vulnerabilities. All known so far have been fixed months ago, see the "Security Vulnerabilities" section at the bottom of http://ofbiz.apache.org/download.html. Last being fixed for almost a year.

        Show
        jacques.le.roux Jacques Le Roux added a comment - I don't see what you are chasing. If I put ?productId=<script>alert('alert')</script> after an URL, and use <field name= "productId" tooltip= "${uiLabelMap.ProductId} [${productId}]" ><text size= "20" maxlength= "20" /></field> in a form, after passing the partyId value from a screen with <set field= "productId" from-field= "parameters.productId" /> This is what I get on screen And this is what I see in the HTML source <input type= "text" name= "productId" value= "&lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt;" size= "20" maxlength= "20" id= "addSmsContactPerson_productId" /><script language= "JavaScript" type= "text/javascript" >ajaxAutoCompleter('', false , 2, 300);</script> <span class= "tooltip" >Product Id &#x5b;&lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt;&#x5d;</span> Of course, same when using your example, which is in no way a mean to show an XSS issue. A JavaScript must be actionable, I think I was pretty clear with the examples I gave above. <input type= "text" name= "productId" value= "&lt;font color&#x3d;red&gt;XSS&lt;&#x2f;font&gt;" size= "20" maxlength= "20" id= "formName_productId" /><script language= "JavaScript" type= "text/javascript" >ajaxAutoCompleter('', false , 2, 300);</script> <span class= "tooltip" >Product Id &#x5b;&lt;font color&#x3d;red&gt;XSS&lt;&#x2f;font&gt;&#x5d;</span> So it's now clear to me that this does not show an XSS vulnerability and I close this issue as invalid. A last question though, which version are you using? I used the trunk HEAD but normally none of the supported versions have XSS vulnerabilities. All known so far have been fixed months ago, see the "Security Vulnerabilities" section at the bottom of http://ofbiz.apache.org/download.html . Last being fixed for almost a year.
        Hide
        administractor Lilian Iatco added a comment - - edited

        http://stackoverflow.com/questions/30097370/how-to-escape-characters-in-ofbiz-widget
        it reproduces for this case:

        put in URL parameter HTML code:

        https://host:8403/xxx/yyy/Product?productId=<font color=red>XSS</font>

        The value is set in PScreens.xml as following :

        <screen name="Product">
        <section>
         <actions>
          <set field="productId" from-field="parameters.productId"/>
         </actions>
        <widgets>
          <include-form name="Product" location="component://.../xxx/yyy/PForms.xml"/>
        </widgets>
        

        The value to escape is productId from tooltip attribute:

        <field name="productId" tooltip="${uiLabelMap.ProductId} [${productId}]"><text size="20" maxlength="20"/></field>

        Can you also suggest a solution for this issue: http://stackoverflow.com/questions/30708500/how-to-escape-characters-in-ofbiz-display-entity-xss-in-ofbiz

        Thank You

        Show
        administractor Lilian Iatco added a comment - - edited http://stackoverflow.com/questions/30097370/how-to-escape-characters-in-ofbiz-widget it reproduces for this case: put in URL parameter HTML code: https: //host:8403/xxx/yyy/Product?productId=<font color=red>XSS</font> The value is set in PScreens.xml as following : <screen name= "Product" > <section> <actions> <set field= "productId" from-field= "parameters.productId" /> </actions> <widgets> <include-form name= "Product" location= "component: //.../xxx/yyy/PForms.xml" /> </widgets> The value to escape is productId from tooltip attribute: <field name= "productId" tooltip= "${uiLabelMap.ProductId} [${productId}]" ><text size= "20" maxlength= "20" /></field> Can you also suggest a solution for this issue: http://stackoverflow.com/questions/30708500/how-to-escape-characters-in-ofbiz-display-entity-xss-in-ofbiz Thank You
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Could you provide a case to reproduce the initial XSS issue? I tried this:
        in a groovy file called by a screen widget

        context.test = "<script>alert('alert')</script>"
        

        in the screen widget

        <set field="parameters.test" from-field="test"/>
        

        in the form called by the screen:

        <field name="test"><display/></field>
        

        I got no js alert popup but this in HTML source:

        <label for="form_test"  id="form_test_title">Test</label>  </td>
          <td colspan="7">
        &lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt;
          </td>
        

        So as you see the data is escaped before being rendered.

        There is a reproducible case and it's

        <field name="test"><display default-value="&lt;script&gt;alert(&#39;alert&#39;)&lt;/script&gt;"/></field>
        

        But this is really shooting oneself in the foot only for the fun of it.
        If you like to shoot yourself in the foot there is another way by using the same process than above but adding encode-output="false" in the form widget

        <field name="test" encode-output="false"><display/></field>
        

        Please let us know your concern and how to reproduce, else in a week, I will close this issue and the Stackoverflows as invalid .

        Show
        jacques.le.roux Jacques Le Roux added a comment - Could you provide a case to reproduce the initial XSS issue? I tried this: in a groovy file called by a screen widget context.test = "<script>alert('alert')</script>" in the screen widget <set field= "parameters.test" from-field= "test" /> in the form called by the screen: <field name= "test" ><display/></field> I got no js alert popup but this in HTML source: <label for = "form_test" id= "form_test_title" >Test</label> </td> <td colspan= "7" > &lt;script&gt;alert&#x28;&#x27;alert&#x27;&#x29;&lt;&#x2f;script&gt; </td> So as you see the data is escaped before being rendered. There is a reproducible case and it's <field name= "test" ><display default -value= "&lt;script&gt;alert(&#39;alert&#39;)&lt;/script&gt;" /></field> But this is really shooting oneself in the foot only for the fun of it. If you like to shoot yourself in the foot there is another way by using the same process than above but adding encode-output="false" in the form widget <field name= "test" encode-output= " false " ><display/></field> Please let us know your concern and how to reproduce, else in a week, I will close this issue and the Stackoverflows as invalid .

          People

          • Assignee:
            jacques.le.roux Jacques Le Roux
            Reporter:
            administractor Lilian Iatco
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development

                Agile