OFBiz
  1. OFBiz
  2. OFBIZ-260

Cross Site Scripting Vulnerability (XSS)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: Trunk
    • Labels:
      None

      Description

      It's a copy of http://jira.undersunconsulting.com/browse/OFBIZ-559 from Olivier Lietz.

      ===========================================================

      Very simple test:

      /ecommerce/control/keywordsearch?SEARCH_STRING=<script>alert("XSS");</script>

      Other components beside ecommerce are also affected.

        Issue Links

          Activity

          Hide
          David E. Jones added a comment -

          Has anyone found an actual vulnerability related to this?

          It is somewhat natural with webapps that you can change the behavior by changing (directory or indirectly) the text that the browser interprets.

          The real question is whether or not it is possible to change server-side behavior to do something the user is not authorized to do.

          Show
          David E. Jones added a comment - Has anyone found an actual vulnerability related to this? It is somewhat natural with webapps that you can change the behavior by changing (directory or indirectly) the text that the browser interprets. The real question is whether or not it is possible to change server-side behavior to do something the user is not authorized to do.
          Hide
          Leon Torres added a comment -

          The attack would have to be extremely sophisticated and social: Imagine that the popup is inserted into some description field. When displayed in a text area, it gets executed. (I tried <script>alert("XSS")</script>, it worked.) Now imagine that the popup is designed to look like the ofbiz login screen. An administrator would type in the username and password, which then gets sent to some remote site via a URL call in javascript. The window closes and the administrator wonders what happened.

          So a combination of phishing techniques, careful scripting, a careless user, and a compromised account that can edit a textarea is sufficient to cause a vulnerability.

          Show
          Leon Torres added a comment - The attack would have to be extremely sophisticated and social: Imagine that the popup is inserted into some description field. When displayed in a text area, it gets executed. (I tried <script>alert("XSS")</script>, it worked.) Now imagine that the popup is designed to look like the ofbiz login screen. An administrator would type in the username and password, which then gets sent to some remote site via a URL call in javascript. The window closes and the administrator wonders what happened. So a combination of phishing techniques, careful scripting, a careless user, and a compromised account that can edit a textarea is sufficient to cause a vulnerability.
          Hide
          Leon Torres added a comment -

          I just realized that a compromised account is not necessary. Any public input that gets displayed as textarea internally is a vector for attack, such as gift message.

          Show
          Leon Torres added a comment - I just realized that a compromised account is not necessary. Any public input that gets displayed as textarea internally is a vector for attack, such as gift message.
          Hide
          Jacques Le Roux added a comment -

          Yes indeed, as far as I searched there is no threat on the server side. On client side I can see another threat more of social engineered as described Leon above. The most I have achieved was using something like <script>alert(document.cookie);</script> .This can be used in many places (every places where a parameter is passed in url) and at first glance seems not too harmful. But we can imagine that an attacker could use this to build a more sophisticated script retrieving cookies. Having the admin login and such he might try brutal force to find a password...

          In this case we speak about non persistent XSS but in the case of https://issues.apache.org/jira/browse/OFBIZ-178 where persistend entry may be in place the attack could be even more dangerous. Because there the attacker has just to wait...

          Here are some interesting links I found about this subject :
          http://www.cert.org/advisories/CA-2000-02.html
          http://www.cert.org/tech_tips/malicious_code_mitigation.html
          http://alistapart.com/articles/secureyourcode
          http://www.whitehatsec.com/downloads/WHXSSThreats.pdf
          http://ha.ckers.org/xss.html

          Some solutions from a list apart (http://alistapart.com/articles/secureyourcode)

          • Strip out single and double quotes or convert them to their HTML entities (‘ and ’ for opening and closing single quotes, “ and ” for opening and closing double quotes). Please note however, that this does not entirely protect you. An attacker could still use String.fromCharCode(39) in an eval() function.
          • Convert < and > to < and >.
          • Convert all line breaks to <br>. If you do this on all code, including style tags, you will save yourself from an attack. See "IE, CSS and JavaScript".
          • Check your self-created code tags (such as [URL]) to make sure the user is not allowed to inject JavaScript in URLs or CSS.
          • Consider stripping out the word "script" to prevent someone from trying to inject the word JavaScript. Keep in mind, though, that as far as IE is concerned, "ja\n\sc\nript" is valid.
          • Use regular expressions (server side) to validate and sanitize user input, as described above
          • Validate CSS input!

          See also p.19 of http://www.whitehatsec.com/downloads/WHXSSThreats.pdf

          But as we can see in http://ha.ckers.org/xss.html this may not be a simple issue : encoding can be very sophisticated
          Even if http://www.cert.org/tech_tips/malicious_code_mitigation.html proposes some solutions about that.

          Show
          Jacques Le Roux added a comment - Yes indeed, as far as I searched there is no threat on the server side. On client side I can see another threat more of social engineered as described Leon above. The most I have achieved was using something like <script>alert(document.cookie);</script> .This can be used in many places (every places where a parameter is passed in url) and at first glance seems not too harmful. But we can imagine that an attacker could use this to build a more sophisticated script retrieving cookies. Having the admin login and such he might try brutal force to find a password... In this case we speak about non persistent XSS but in the case of https://issues.apache.org/jira/browse/OFBIZ-178 where persistend entry may be in place the attack could be even more dangerous. Because there the attacker has just to wait... Here are some interesting links I found about this subject : http://www.cert.org/advisories/CA-2000-02.html http://www.cert.org/tech_tips/malicious_code_mitigation.html http://alistapart.com/articles/secureyourcode http://www.whitehatsec.com/downloads/WHXSSThreats.pdf http://ha.ckers.org/xss.html Some solutions from a list apart ( http://alistapart.com/articles/secureyourcode ) Strip out single and double quotes or convert them to their HTML entities (‘ and ’ for opening and closing single quotes, “ and ” for opening and closing double quotes). Please note however, that this does not entirely protect you. An attacker could still use String.fromCharCode(39) in an eval() function. Convert < and > to < and >. Convert all line breaks to <br>. If you do this on all code, including style tags, you will save yourself from an attack. See "IE, CSS and JavaScript". Check your self-created code tags (such as [URL] ) to make sure the user is not allowed to inject JavaScript in URLs or CSS. Consider stripping out the word "script" to prevent someone from trying to inject the word JavaScript. Keep in mind, though, that as far as IE is concerned, "ja\n\sc\nript" is valid. Use regular expressions (server side) to validate and sanitize user input, as described above Validate CSS input! See also p.19 of http://www.whitehatsec.com/downloads/WHXSSThreats.pdf But as we can see in http://ha.ckers.org/xss.html this may not be a simple issue : encoding can be very sophisticated Even if http://www.cert.org/tech_tips/malicious_code_mitigation.html proposes some solutions about that.
          Hide
          Eriks Dobelis added a comment -

          I suggest we start with really cautious attitude here, and then in longer run remove restrictions when we are sure they are safe.

          So for the start I would suggest:

          In forum case - it is just a few tags that are allowed (like <i>,<b>, but not <img> and certainly <script>). All <,>, and better also ',",; which are not part of explicitely allowed tags should be changed to &#60,&#62, etc. <img> tag should not be allowed because it contains parameters which can be manipulated. There is nothing attacker can do with simple <i>.

          In search case it is simpler, because you should not allow any tags there at all and should replace all of these.

          Of course UTF-8 variations of the symbols should be analyzed and characters like 000060 should be converted to 60 before stripping.

          Speaking about potential implementation, a separate filter should be created and used in corresponding web.xml analyzing all POST and GET parameters supplied by user. The question is whether we can create a generic filter for all components or there should different ones because of different needs of different modules.

          Show
          Eriks Dobelis added a comment - I suggest we start with really cautious attitude here, and then in longer run remove restrictions when we are sure they are safe. So for the start I would suggest: In forum case - it is just a few tags that are allowed (like <i>,<b>, but not <img> and certainly <script>). All <,>, and better also ',",; which are not part of explicitely allowed tags should be changed to &#60,&#62, etc. <img> tag should not be allowed because it contains parameters which can be manipulated. There is nothing attacker can do with simple <i>. In search case it is simpler, because you should not allow any tags there at all and should replace all of these. Of course UTF-8 variations of the symbols should be analyzed and characters like 000060 should be converted to 60 before stripping. Speaking about potential implementation, a separate filter should be created and used in corresponding web.xml analyzing all POST and GET parameters supplied by user. The question is whether we can create a generic filter for all components or there should different ones because of different needs of different modules.
          Hide
          Jacques Le Roux added a comment -

          I have added a new method htmlSpecialChars into the StringUtil class from John Martin.

          htmlSpecialChars may be used in this issue and in OFBIZ-178 as well. A first step...

          Show
          Jacques Le Roux added a comment - I have added a new method htmlSpecialChars into the StringUtil class from John Martin. htmlSpecialChars may be used in this issue and in OFBIZ-178 as well. A first step...
          Hide
          Eriks Dobelis added a comment -

          Great addition, Jacques! I suggest that there should be a parameter allowedTags or something like that. It would be a list of tags which are allowed and should not be replaced. So we could pass list like "b","i" and <b></b><i></i> would be left as they are, but all the other < and > would be replaced.

          Important question is: what should call this method? What do you think about creating a filter in web.xml to parse user input? Or for now we should just call this method in cases where we have identified the problem, and create the global filter later?

          Show
          Eriks Dobelis added a comment - Great addition, Jacques! I suggest that there should be a parameter allowedTags or something like that. It would be a list of tags which are allowed and should not be replaced. So we could pass list like "b","i" and <b></b><i></i> would be left as they are, but all the other < and > would be replaced. Important question is: what should call this method? What do you think about creating a filter in web.xml to parse user input? Or for now we should just call this method in cases where we have identified the problem, and create the global filter later?
          Hide
          Marco Risaliti added a comment -

          Can this issue be closed or this bug is still present ?

          Thanks
          Marco

          Show
          Marco Risaliti added a comment - Can this issue be closed or this bug is still present ? Thanks Marco
          Hide
          Jacques Le Roux added a comment -

          No really a bug, more a security issue : still present but not a lot problems (if any) arise so nothing is done yet. Reality takes precedent !

          Show
          Jacques Le Roux added a comment - No really a bug, more a security issue : still present but not a lot problems (if any) arise so nothing is done yet. Reality takes precedent !
          Hide
          Eriks Dobelis added a comment -

          It is a security bug (not functional one), and it is still present. It certainly shouldn't be closed.

          Show
          Eriks Dobelis added a comment - It is a security bug (not functional one), and it is still present. It certainly shouldn't be closed.
          Hide
          Bruno Busco added a comment -

          I have seen in Drupal a nice handling of what they call "input filters".
          http://www.lullabot.com/articles/drupal_input_formats_and_filters

          May be can give some ideas...

          Show
          Bruno Busco added a comment - I have seen in Drupal a nice handling of what they call "input filters". http://www.lullabot.com/articles/drupal_input_formats_and_filters May be can give some ideas...
          Hide
          Jacques Le Roux added a comment -

          Fixed by recent security efforts

          Show
          Jacques Le Roux added a comment - Fixed by recent security efforts

            People

            • Assignee:
              David E. Jones
              Reporter:
              Marco Risaliti
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development