[ http://issues.apache.org/jira/browse/OFBIZ-260?page=comments#action_12436441 ] Jacques Le Roux commented on OFBIZ-260: ---------------------------------------
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. > Cross Site Scripting Vulnerability (XSS) > ---------------------------------------- > > Key: OFBIZ-260 > URL: http://issues.apache.org/jira/browse/OFBIZ-260 > Project: OFBiz (The Open for Business Project) > Issue Type: Bug > Components: ecommerce > Affects Versions: SVN trunk > Reporter: Marco Risaliti > > 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. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
