[TEST] Test "POC for CSRF Token"

[Jacques Le Roux]

Hi,

After working with James, who initiated the "POC for CSRF Token" effort, on https://issues.apache.org/jira/browse/OFBIZ-11306
I have created OFBIZ-11425 to ask for all possible help to review and test.

TIA

Jacques

[Jacques Le Roux]

Forgot to say that w/ or w/o test I'll commit in 1 month...

Jacques

Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
> Hi,
>
> After working with James, who initiated the "POC for CSRF Token" effort, on https://issues.apache.org/jira/browse/OFBIZ-11306
> I have created OFBIZ-11425 to ask for all possible help to review and test.
>
> TIA
>
> Jacques
>

[Jacques Le Roux]

For those interested, it's maybe easier to test to simply apply the last patches (framework + plugins) at OFBIZ-11306

Also if I see nothing happening, I'll do a reminder every week...

Thanks

Jacques

Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :

> Forgot to say that w/ or w/o test I'll commit in 1 month...
>
> Jacques
>
> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>> Hi,
>>
>> After working with James, who initiated the "POC for CSRF Token" effort, on https://issues.apache.org/jira/browse/OFBIZ-11306
>> I have created OFBIZ-11425 to ask for all possible help to review and test.
>>
>> TIA
>>
>> Jacques
>>

[Pierre Smits-3]

Thanks for the info, and the persistence to keep it in the attention span,
Jacques.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
[hidden email]> wrote:

> For those interested, it's maybe easier to test to simply apply the last
> patches (framework + plugins) at OFBIZ-11306
>
> Also if I see nothing happening, I'll do a reminder every week...
>
> Thanks
>
> Jacques
>
> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
> > Forgot to say that w/ or w/o test I'll commit in 1 month...
> >
> > Jacques
> >
> > Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
> >> Hi,
> >>
> >> After working with James, who initiated the "POC for CSRF Token"
> effort, on https://issues.apache.org/jira/browse/OFBIZ-11306
> >> I have created OFBIZ-11425 to ask for all possible help to review and
> test.
> >>
> >> TIA
> >>
> >> Jacques
> >>
>

[Jacques Le Roux]

Hi All,

This is my 1st weekly reminder :)

As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke but once you are able to create one, mostly using social engineering, they
can be "/devastating for both the business and user/".[1]

OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent URLs[2] are susceptible to be attacked. James started an effort to fix them
with OFBIZ-11306 and I joined him.

Though, after almost 3 months of work, I'm pretty confident about our results, I have investigated how to validate our effort, with 3 mains
penetrations tools: Burp, Owasp Zap and Qualys.

I notably followed[3]. Since we have (normally) covered all cases (see OFBIZ-11306 description), I did not find a way to penetrate using this method.

Moreover, I'm a developer not a penetration tester. And, for misc. reasons, I find quite painful to use those tools when it comes to CSRF, even if
it's well explained in[3].

I did not either find an easy way to automatically test all URLs for CSRF vulnerabilities. It seems to me that the most powerful tool is Qualys but so
far I have been unable to scan a localhost instance. I expect to work on that next week. If I can't get it working it would be nice to have a domain
where to put the changes and launch Qualys, and Zap that I have to test for the same also, against this domain.

Another aspect I'd be interested in are regressions. I don't think there should be any, but if you can apply the patch, or use my fork branch (see
OFBIZ-11425), and have a short tour it would be good.

[1] https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
[2] this is security jargon :), and idempotent URL is one that does not change the state of the application. It's a bit more than safe URL:
http://restcookbook.com/HTTP%20Methods/idempotency/
[3] https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery

TIA

Jacques

Le 29/02/2020 à 11:01, Pierre Smits a écrit :

> Thanks for the info, and the persistence to keep it in the attention span,
> Jacques.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>  since
> 2008 (without privileges)
>
> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
> *Apache Directory<https://directory.apache.org>, PMC Member*
> Apache Incubator<https://incubator.apache.org>, committer
> Apache Steve<https://steve.apache.org>, committer
>
>
> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
> [hidden email]> wrote:
>
>> For those interested, it's maybe easier to test to simply apply the last
>> patches (framework + plugins) at OFBIZ-11306
>>
>> Also if I see nothing happening, I'll do a reminder every week...
>>
>> Thanks
>>
>> Jacques
>>
>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>
>>> Jacques
>>>
>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>> Hi,
>>>>
>>>> After working with James, who initiated the "POC for CSRF Token"
>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>> I have created OFBIZ-11425 to ask for all possible help to review and
>> test.
>>>> TIA
>>>>
>>>> Jacques
>>>>

[grv]

Hi Jacques

I tried to simulate the CSRF manually (and I plan to use Zap as well) and I
got this error -

Invalid or missing CSRF token to path '/EntitySQLProcessor'

I logged in to OFBiz and then used an HTML form to perform the attack and
the patch successfully prevented.

So it looks good to me. I will let you know how it goes with ZAP.

Best,
Girish






On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux <[hidden email]>
wrote:

> Hi All,
>
> This is my 1st weekly reminder :)
>
> As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke
> but once you are able to create one, mostly using social engineering, they
> can be "/devastating for both the business and user/".[1]
>
> OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent
> URLs[2] are susceptible to be attacked. James started an effort to fix them
> with OFBIZ-11306 and I joined him.
>
> Though, after almost 3 months of work, I'm pretty confident about our
> results, I have investigated how to validate our effort, with 3 mains
> penetrations tools: Burp, Owasp Zap and Qualys.
>
> I notably followed[3]. Since we have (normally) covered all cases (see
> OFBIZ-11306 description), I did not find a way to penetrate using this
> method.
>
> Moreover, I'm a developer not a penetration tester. And, for misc.
> reasons, I find quite painful to use those tools when it comes to CSRF,
> even if
> it's well explained in[3].
>
> I did not either find an easy way to automatically test all URLs for CSRF
> vulnerabilities. It seems to me that the most powerful tool is Qualys but
> so
> far I have been unable to scan a localhost instance. I expect to work on
> that next week. If I can't get it working it would be nice to have a domain
> where to put the changes and launch Qualys, and Zap that I have to test
> for the same also, against this domain.
>
> Another aspect I'd be interested in are regressions. I don't think there
> should be any, but if you can apply the patch, or use my fork branch (see
> OFBIZ-11425), and have a short tour it would be good.
>
> [1]
> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
> [2] this is security jargon :), and idempotent URL is one that does not
> change the state of the application. It's a bit more than safe URL:
> http://restcookbook.com/HTTP%20Methods/idempotency/
> [3]
> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery
>
> TIA
>
> Jacques
>
> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
> > Thanks for the info, and the persistence to keep it in the attention
> span,
> > Jacques.
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion<https://trafodion.apache.org>, Vice President*
> > *Apache Directory<https://directory.apache.org>, PMC Member*
> > Apache Incubator<https://incubator.apache.org>, committer
> > Apache Steve<https://steve.apache.org>, committer
> >
> >
> > On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> For those interested, it's maybe easier to test to simply apply the last
> >> patches (framework + plugins) at OFBIZ-11306
> >>
> >> Also if I see nothing happening, I'll do a reminder every week...
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
> >>> Forgot to say that w/ or w/o test I'll commit in 1 month...
> >>>
> >>> Jacques
> >>>
> >>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
> >>>> Hi,
> >>>>
> >>>> After working with James, who initiated the "POC for CSRF Token"
> >> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
> >>>> I have created OFBIZ-11425 to ask for all possible help to review and
> >> test.
> >>>> TIA
> >>>>
> >>>> Jacques
> >>>>
>

[Jacques Le Roux]

Hi Girish,

I just had a look with Zap.  As a note: Zap reports missing CSRF tokens in forms when there are actually present in the URL. This is explained by the
point 3 of OFBIZ-11306 description (Freemarker handling).

Jacques

Le 09/03/2020 à 10:57, Girish Vasmatkar a écrit :

> Hi Jacques
>
> I tried to simulate the CSRF manually (and I plan to use Zap as well) and I
> got this error -
>
> Invalid or missing CSRF token to path '/EntitySQLProcessor'
>
> I logged in to OFBiz and then used an HTML form to perform the attack and
> the patch successfully prevented.
>
> So it looks good to me. I will let you know how it goes with ZAP.
>
> Best,
> Girish
>
>
>
>
>
>
> On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux <[hidden email]>
> wrote:
>
>> Hi All,
>>
>> This is my 1st weekly reminder :)
>>
>> As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke
>> but once you are able to create one, mostly using social engineering, they
>> can be "/devastating for both the business and user/".[1]
>>
>> OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent
>> URLs[2] are susceptible to be attacked. James started an effort to fix them
>> with OFBIZ-11306 and I joined him.
>>
>> Though, after almost 3 months of work, I'm pretty confident about our
>> results, I have investigated how to validate our effort, with 3 mains
>> penetrations tools: Burp, Owasp Zap and Qualys.
>>
>> I notably followed[3]. Since we have (normally) covered all cases (see
>> OFBIZ-11306 description), I did not find a way to penetrate using this
>> method.
>>
>> Moreover, I'm a developer not a penetration tester. And, for misc.
>> reasons, I find quite painful to use those tools when it comes to CSRF,
>> even if
>> it's well explained in[3].
>>
>> I did not either find an easy way to automatically test all URLs for CSRF
>> vulnerabilities. It seems to me that the most powerful tool is Qualys but
>> so
>> far I have been unable to scan a localhost instance. I expect to work on
>> that next week. If I can't get it working it would be nice to have a domain
>> where to put the changes and launch Qualys, and Zap that I have to test
>> for the same also, against this domain.
>>
>> Another aspect I'd be interested in are regressions. I don't think there
>> should be any, but if you can apply the patch, or use my fork branch (see
>> OFBIZ-11425), and have a short tour it would be good.
>>
>> [1]
>> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
>> [2] this is security jargon :), and idempotent URL is one that does not
>> change the state of the application. It's a bit more than safe URL:
>> http://restcookbook.com/HTTP%20Methods/idempotency/
>> [3]
>> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery
>>
>> TIA
>>
>> Jacques
>>
>> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
>>> Thanks for the info, and the persistence to keep it in the attention
>> span,
>>> Jacques.
>>>
>>> Met vriendelijke groet,
>>>
>>> Pierre Smits
>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
>> since
>>> 2008 (without privileges)
>>>
>>> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
>>> *Apache Directory<https://directory.apache.org>, PMC Member*
>>> Apache Incubator<https://incubator.apache.org>, committer
>>> Apache Steve<https://steve.apache.org>, committer
>>>
>>>
>>> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> For those interested, it's maybe easier to test to simply apply the last
>>>> patches (framework + plugins) at OFBIZ-11306
>>>>
>>>> Also if I see nothing happening, I'll do a reminder every week...
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> After working with James, who initiated the "POC for CSRF Token"
>>>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>>>> I have created OFBIZ-11425 to ask for all possible help to review and
>>>> test.
>>>>>> TIA
>>>>>>
>>>>>> Jacques
>>>>>>

[Jacques Le Roux]

Hi All,

If you are interested to test, manually or with the tool of you choice, you can do so at https://168.63.29.103:8443/webtools.

This is thank to Ross Gardler and Microsoft for providing an Azure  Ubuntu 18.04.4 LTS  VM where I installed OFBiz trunk patched for CSRF.

Please break it :)

Enjoy

Jacques

Le 09/03/2020 à 17:58, Jacques Le Roux a écrit :

> Hi Girish,
>
> I just had a look with Zap.  As a note: Zap reports missing CSRF tokens in forms when there are actually present in the URL. This is explained by
> the point 3 of OFBIZ-11306 description (Freemarker handling).
>
> Jacques
>
> Le 09/03/2020 à 10:57, Girish Vasmatkar a écrit :
>> Hi Jacques
>>
>> I tried to simulate the CSRF manually (and I plan to use Zap as well) and I
>> got this error -
>>
>> Invalid or missing CSRF token to path '/EntitySQLProcessor'
>>
>> I logged in to OFBiz and then used an HTML form to perform the attack and
>> the patch successfully prevented.
>>
>> So it looks good to me. I will let you know how it goes with ZAP.
>>
>> Best,
>> Girish
>>
>>
>>
>>
>>
>>
>> On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux <[hidden email]>
>> wrote:
>>
>>> Hi All,
>>>
>>> This is my 1st weekly reminder :)
>>>
>>> As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke
>>> but once you are able to create one, mostly using social engineering, they
>>> can be "/devastating for both the business and user/".[1]
>>>
>>> OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent
>>> URLs[2] are susceptible to be attacked. James started an effort to fix them
>>> with OFBIZ-11306 and I joined him.
>>>
>>> Though, after almost 3 months of work, I'm pretty confident about our
>>> results, I have investigated how to validate our effort, with 3 mains
>>> penetrations tools: Burp, Owasp Zap and Qualys.
>>>
>>> I notably followed[3]. Since we have (normally) covered all cases (see
>>> OFBIZ-11306 description), I did not find a way to penetrate using this
>>> method.
>>>
>>> Moreover, I'm a developer not a penetration tester. And, for misc.
>>> reasons, I find quite painful to use those tools when it comes to CSRF,
>>> even if
>>> it's well explained in[3].
>>>
>>> I did not either find an easy way to automatically test all URLs for CSRF
>>> vulnerabilities. It seems to me that the most powerful tool is Qualys but
>>> so
>>> far I have been unable to scan a localhost instance. I expect to work on
>>> that next week. If I can't get it working it would be nice to have a domain
>>> where to put the changes and launch Qualys, and Zap that I have to test
>>> for the same also, against this domain.
>>>
>>> Another aspect I'd be interested in are regressions. I don't think there
>>> should be any, but if you can apply the patch, or use my fork branch (see
>>> OFBIZ-11425), and have a short tour it would be good.
>>>
>>> [1]
>>> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
>>> [2] this is security jargon :), and idempotent URL is one that does not
>>> change the state of the application. It's a bit more than safe URL:
>>> http://restcookbook.com/HTTP%20Methods/idempotency/
>>> [3]
>>> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery
>>>
>>> TIA
>>>
>>> Jacques
>>>
>>> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
>>>> Thanks for the info, and the persistence to keep it in the attention
>>> span,
>>>> Jacques.
>>>>
>>>> Met vriendelijke groet,
>>>>
>>>> Pierre Smits
>>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
>>> since
>>>> 2008 (without privileges)
>>>>
>>>> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
>>>> *Apache Directory<https://directory.apache.org>, PMC Member*
>>>> Apache Incubator<https://incubator.apache.org>, committer
>>>> Apache Steve<https://steve.apache.org>, committer
>>>>
>>>>
>>>> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> For those interested, it's maybe easier to test to simply apply the last
>>>>> patches (framework + plugins) at OFBIZ-11306
>>>>>
>>>>> Also if I see nothing happening, I'll do a reminder every week...
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>>>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> After working with James, who initiated the "POC for CSRF Token"
>>>>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>>>>> I have created OFBIZ-11425 to ask for all possible help to review and
>>>>> test.
>>>>>>> TIA
>>>>>>>
>>>>>>> Jacques
>>>>>>>

[Jacques Le Roux]

Hi,

I initially said I'd wait a month, it will be 24 days next Monday and I don't expect much more activity now.

So, if nobody disagree, this weekend, I'll commit both the CSRF defense and another vulnerability fix pending. This will allow to release 17.12.02
with our 1+ years backlog of vulnerabilities purged.

If we do so, I have a question. With NoCsrfDefenseStrategy we have the possibility to bypass the CSRF defense. It's convenient for development,
because else, in this mode, the CSRF defense is quite intrusive. *

I propose to use it also in demo mode. Because we should not expect CSRF attacks on the demos (stable R17 and trunk) and if even it happens the
consequences should not be important. Only alteration of the DB should be expected and nothing should happen out of that. So no consequences for the
VM and for the apache.org domain. If somebody see a risk doing so please chime in before I patch OFBiz.

@Swapnil, I know you plan to update the demos in order to make R17 stable, and R16 old. If nobody disagree about bypassing the CSRF defense on demo,
it's only a matter of applying this patch:

diff --git framework/security/config/security.properties framework/security/config/security.properties
index 55c2b6a41a..5b06692d88 100644
--- framework/security/config/security.properties
+++ framework/security/config/security.properties
@@ -169,4 +169,4 @@ csrf.entity.request.limit=

  # csrf defense strategy. Default is org.apache.ofbiz.security.CsrfDefenseStrategy if not specified.
  # use org.apache.ofbiz.security.NoCsrfDefenseStrategy to disable CSRF check totally.
-csrf.defense.strategy=
+csrf.defense.strategy=org.apache.ofbiz.security.NoCsrfDefenseStrategy

I hope all is clear for everybody. The CSRF defense is a major change, fortunately not in development mode. Please verify it's OK with you before we
apply the plan above.

Here I want to thank James for his good work again

Jacques

Le 15/03/2020 à 19:35, Jacques Le Roux a écrit :

> Hi All,
>
> If you are interested to test, manually or with the tool of you choice, you can do so at https://168.63.29.103:8443/webtools.
>
> This is thank to Ross Gardler and Microsoft for providing an Azure  Ubuntu 18.04.4 LTS  VM where I installed OFBiz trunk patched for CSRF.
>
> Please break it :)
>
> Enjoy
>
> Jacques
>
> Le 09/03/2020 à 17:58, Jacques Le Roux a écrit :
>> Hi Girish,
>>
>> I just had a look with Zap.  As a note: Zap reports missing CSRF tokens in forms when there are actually present in the URL. This is explained by
>> the point 3 of OFBIZ-11306 description (Freemarker handling).
>>
>> Jacques
>>
>> Le 09/03/2020 à 10:57, Girish Vasmatkar a écrit :
>>> Hi Jacques
>>>
>>> I tried to simulate the CSRF manually (and I plan to use Zap as well) and I
>>> got this error -
>>>
>>> Invalid or missing CSRF token to path '/EntitySQLProcessor'
>>>
>>> I logged in to OFBiz and then used an HTML form to perform the attack and
>>> the patch successfully prevented.
>>>
>>> So it looks good to me. I will let you know how it goes with ZAP.
>>>
>>> Best,
>>> Girish
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux <[hidden email]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> This is my 1st weekly reminder :)
>>>>
>>>> As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke
>>>> but once you are able to create one, mostly using social engineering, they
>>>> can be "/devastating for both the business and user/".[1]
>>>>
>>>> OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent
>>>> URLs[2] are susceptible to be attacked. James started an effort to fix them
>>>> with OFBIZ-11306 and I joined him.
>>>>
>>>> Though, after almost 3 months of work, I'm pretty confident about our
>>>> results, I have investigated how to validate our effort, with 3 mains
>>>> penetrations tools: Burp, Owasp Zap and Qualys.
>>>>
>>>> I notably followed[3]. Since we have (normally) covered all cases (see
>>>> OFBIZ-11306 description), I did not find a way to penetrate using this
>>>> method.
>>>>
>>>> Moreover, I'm a developer not a penetration tester. And, for misc.
>>>> reasons, I find quite painful to use those tools when it comes to CSRF,
>>>> even if
>>>> it's well explained in[3].
>>>>
>>>> I did not either find an easy way to automatically test all URLs for CSRF
>>>> vulnerabilities. It seems to me that the most powerful tool is Qualys but
>>>> so
>>>> far I have been unable to scan a localhost instance. I expect to work on
>>>> that next week. If I can't get it working it would be nice to have a domain
>>>> where to put the changes and launch Qualys, and Zap that I have to test
>>>> for the same also, against this domain.
>>>>
>>>> Another aspect I'd be interested in are regressions. I don't think there
>>>> should be any, but if you can apply the patch, or use my fork branch (see
>>>> OFBIZ-11425), and have a short tour it would be good.
>>>>
>>>> [1]
>>>> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
>>>> [2] this is security jargon :), and idempotent URL is one that does not
>>>> change the state of the application. It's a bit more than safe URL:
>>>> http://restcookbook.com/HTTP%20Methods/idempotency/
>>>> [3]
>>>> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery
>>>>
>>>> TIA
>>>>
>>>> Jacques
>>>>
>>>> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
>>>>> Thanks for the info, and the persistence to keep it in the attention
>>>> span,
>>>>> Jacques.
>>>>>
>>>>> Met vriendelijke groet,
>>>>>
>>>>> Pierre Smits
>>>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
>>>> since
>>>>> 2008 (without privileges)
>>>>>
>>>>> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
>>>>> *Apache Directory<https://directory.apache.org>, PMC Member*
>>>>> Apache Incubator<https://incubator.apache.org>, committer
>>>>> Apache Steve<https://steve.apache.org>, committer
>>>>>
>>>>>
>>>>> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> For those interested, it's maybe easier to test to simply apply the last
>>>>>> patches (framework + plugins) at OFBIZ-11306
>>>>>>
>>>>>> Also if I see nothing happening, I'll do a reminder every week...
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>>>>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After working with James, who initiated the "POC for CSRF Token"
>>>>>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>>>>>> I have created OFBIZ-11425 to ask for all possible help to review and
>>>>>> test.
>>>>>>>> TIA
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>

[Michael Brohl-3]

Jacques,

you announced a month, please stay with that or even think about
expaning the test period. This is not a trivial case and with the
current global situation, a lot of people will have more urgent problems
to solve at the moment.

Thanks,

Michael


Am 20.03.20 um 08:44 schrieb Jacques Le Roux:

> Hi,
>
> I initially said I'd wait a month, it will be 24 days next Monday and
> I don't expect much more activity now.
>
> So, if nobody disagree, this weekend, I'll commit both the CSRF
> defense and another vulnerability fix pending. This will allow to
> release 17.12.02 with our 1+ years backlog of vulnerabilities purged.
>
> If we do so, I have a question. With NoCsrfDefenseStrategy we have the
> possibility to bypass the CSRF defense. It's convenient for
> development, because else, in this mode, the CSRF defense is quite
> intrusive. *
>
> I propose to use it also in demo mode. Because we should not expect
> CSRF attacks on the demos (stable R17 and trunk) and if even it
> happens the consequences should not be important. Only alteration of
> the DB should be expected and nothing should happen out of that. So no
> consequences for the VM and for the apache.org domain. If somebody see
> a risk doing so please chime in before I patch OFBiz.
>
> @Swapnil, I know you plan to update the demos in order to make R17
> stable, and R16 old. If nobody disagree about bypassing the CSRF
> defense on demo, it's only a matter of applying this patch:
>
> diff --git framework/security/config/security.properties
> framework/security/config/security.properties
> index 55c2b6a41a..5b06692d88 100644
> --- framework/security/config/security.properties
> +++ framework/security/config/security.properties
> @@ -169,4 +169,4 @@ csrf.entity.request.limit=
>
>  # csrf defense strategy. Default is
> org.apache.ofbiz.security.CsrfDefenseStrategy if not specified.
>  # use org.apache.ofbiz.security.NoCsrfDefenseStrategy to disable CSRF
> check totally.
> -csrf.defense.strategy=
> +csrf.defense.strategy=org.apache.ofbiz.security.NoCsrfDefenseStrategy
>
> I hope all is clear for everybody. The CSRF defense is a major change,
> fortunately not in development mode. Please verify it's OK with you
> before we apply the plan above.
>
> Here I want to thank James for his good work again
>
> Jacques
>
> Le 15/03/2020 à 19:35, Jacques Le Roux a écrit :
>> Hi All,
>>
>> If you are interested to test, manually or with the tool of you
>> choice, you can do so at https://168.63.29.103:8443/webtools.
>>
>> This is thank to Ross Gardler and Microsoft for providing an Azure 
>> Ubuntu 18.04.4 LTS  VM where I installed OFBiz trunk patched for CSRF.
>>
>> Please break it :)
>>
>> Enjoy
>>
>> Jacques
>>
>> Le 09/03/2020 à 17:58, Jacques Le Roux a écrit :
>>> Hi Girish,
>>>
>>> I just had a look with Zap.  As a note: Zap reports missing CSRF
>>> tokens in forms when there are actually present in the URL. This is
>>> explained by the point 3 of OFBIZ-11306 description (Freemarker
>>> handling).
>>>
>>> Jacques
>>>
>>> Le 09/03/2020 à 10:57, Girish Vasmatkar a écrit :
>>>> Hi Jacques
>>>>
>>>> I tried to simulate the CSRF manually (and I plan to use Zap as
>>>> well) and I
>>>> got this error -
>>>>
>>>> Invalid or missing CSRF token to path '/EntitySQLProcessor'
>>>>
>>>> I logged in to OFBiz and then used an HTML form to perform the
>>>> attack and
>>>> the patch successfully prevented.
>>>>
>>>> So it looks good to me. I will let you know how it goes with ZAP.
>>>>
>>>> Best,
>>>> Girish
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> This is my 1st weekly reminder :)
>>>>>
>>>>> As you may know CSRF attacks are very bad. TL;DR: They are hard to
>>>>> provoke
>>>>> but once you are able to create one, mostly using social
>>>>> engineering, they
>>>>> can be "/devastating for both the business and user/".[1]
>>>>>
>>>>> OFBiz is currently riddled with CSRF vulnerabilities, all not
>>>>> idempotent
>>>>> URLs[2] are susceptible to be attacked. James started an effort to
>>>>> fix them
>>>>> with OFBIZ-11306 and I joined him.
>>>>>
>>>>> Though, after almost 3 months of work, I'm pretty confident about our
>>>>> results, I have investigated how to validate our effort, with 3 mains
>>>>> penetrations tools: Burp, Owasp Zap and Qualys.
>>>>>
>>>>> I notably followed[3]. Since we have (normally) covered all cases
>>>>> (see
>>>>> OFBIZ-11306 description), I did not find a way to penetrate using
>>>>> this
>>>>> method.
>>>>>
>>>>> Moreover, I'm a developer not a penetration tester. And, for misc.
>>>>> reasons, I find quite painful to use those tools when it comes to
>>>>> CSRF,
>>>>> even if
>>>>> it's well explained in[3].
>>>>>
>>>>> I did not either find an easy way to automatically test all URLs
>>>>> for CSRF
>>>>> vulnerabilities. It seems to me that the most powerful tool is
>>>>> Qualys but
>>>>> so
>>>>> far I have been unable to scan a localhost instance. I expect to
>>>>> work on
>>>>> that next week. If I can't get it working it would be nice to have
>>>>> a domain
>>>>> where to put the changes and launch Qualys, and Zap that I have to
>>>>> test
>>>>> for the same also, against this domain.
>>>>>
>>>>> Another aspect I'd be interested in are regressions. I don't think
>>>>> there
>>>>> should be any, but if you can apply the patch, or use my fork
>>>>> branch (see
>>>>> OFBIZ-11425), and have a short tour it would be good.
>>>>>
>>>>> [1]
>>>>> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/ 
>>>>>
>>>>> [2] this is security jargon :), and idempotent URL is one that
>>>>> does not
>>>>> change the state of the application. It's a bit more than safe URL:
>>>>> http://restcookbook.com/HTTP%20Methods/idempotency/
>>>>> [3]
>>>>> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery 
>>>>>
>>>>>
>>>>> TIA
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
>>>>>> Thanks for the info, and the persistence to keep it in the attention
>>>>> span,
>>>>>> Jacques.
>>>>>>
>>>>>> Met vriendelijke groet,
>>>>>>
>>>>>> Pierre Smits
>>>>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
>>>>> since
>>>>>> 2008 (without privileges)
>>>>>>
>>>>>> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
>>>>>> *Apache Directory<https://directory.apache.org>, PMC Member*
>>>>>> Apache Incubator<https://incubator.apache.org>, committer
>>>>>> Apache Steve<https://steve.apache.org>, committer
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> For those interested, it's maybe easier to test to simply apply
>>>>>>> the last
>>>>>>> patches (framework + plugins) at OFBIZ-11306
>>>>>>>
>>>>>>> Also if I see nothing happening, I'll do a reminder every week...
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>>>>>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> After working with James, who initiated the "POC for CSRF Token"
>>>>>>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>>>>>>> I have created OFBIZ-11425 to ask for all possible help to
>>>>>>>>> review and
>>>>>>> test.
>>>>>>>>> TIA
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>

[Jacques Le Roux]

Michael,

OK, I can wait 5 days more :) So it will be more for the next weekend

Jacques

Le 20/03/2020 à 09:44, Michael Brohl a écrit :

> Jacques,
>
> you announced a month, please stay with that or even think about expaning the test period. This is not a trivial case and with the current global
> situation, a lot of people will have more urgent problems to solve at the moment.
>
> Thanks,
>
> Michael
>
>
> Am 20.03.20 um 08:44 schrieb Jacques Le Roux:
>> Hi,
>>
>> I initially said I'd wait a month, it will be 24 days next Monday and I don't expect much more activity now.
>>
>> So, if nobody disagree, this weekend, I'll commit both the CSRF defense and another vulnerability fix pending. This will allow to release 17.12.02
>> with our 1+ years backlog of vulnerabilities purged.
>>
>> If we do so, I have a question. With NoCsrfDefenseStrategy we have the possibility to bypass the CSRF defense. It's convenient for development,
>> because else, in this mode, the CSRF defense is quite intrusive. *
>>
>> I propose to use it also in demo mode. Because we should not expect CSRF attacks on the demos (stable R17 and trunk) and if even it happens the
>> consequences should not be important. Only alteration of the DB should be expected and nothing should happen out of that. So no consequences for
>> the VM and for the apache.org domain. If somebody see a risk doing so please chime in before I patch OFBiz.
>>
>> @Swapnil, I know you plan to update the demos in order to make R17 stable, and R16 old. If nobody disagree about bypassing the CSRF defense on
>> demo, it's only a matter of applying this patch:
>>
>> diff --git framework/security/config/security.properties framework/security/config/security.properties
>> index 55c2b6a41a..5b06692d88 100644
>> --- framework/security/config/security.properties
>> +++ framework/security/config/security.properties
>> @@ -169,4 +169,4 @@ csrf.entity.request.limit=
>>
>>  # csrf defense strategy. Default is org.apache.ofbiz.security.CsrfDefenseStrategy if not specified.
>>  # use org.apache.ofbiz.security.NoCsrfDefenseStrategy to disable CSRF check totally.
>> -csrf.defense.strategy=
>> +csrf.defense.strategy=org.apache.ofbiz.security.NoCsrfDefenseStrategy
>>
>> I hope all is clear for everybody. The CSRF defense is a major change, fortunately not in development mode. Please verify it's OK with you before
>> we apply the plan above.
>>
>> Here I want to thank James for his good work again
>>
>> Jacques
>>
>> Le 15/03/2020 à 19:35, Jacques Le Roux a écrit :
>>> Hi All,
>>>
>>> If you are interested to test, manually or with the tool of you choice, you can do so at https://168.63.29.103:8443/webtools.
>>>
>>> This is thank to Ross Gardler and Microsoft for providing an Azure  Ubuntu 18.04.4 LTS  VM where I installed OFBiz trunk patched for CSRF.
>>>
>>> Please break it :)
>>>
>>> Enjoy
>>>
>>> Jacques
>>>
>>> Le 09/03/2020 à 17:58, Jacques Le Roux a écrit :
>>>> Hi Girish,
>>>>
>>>> I just had a look with Zap.  As a note: Zap reports missing CSRF tokens in forms when there are actually present in the URL. This is explained by
>>>> the point 3 of OFBIZ-11306 description (Freemarker handling).
>>>>
>>>> Jacques
>>>>
>>>> Le 09/03/2020 à 10:57, Girish Vasmatkar a écrit :
>>>>> Hi Jacques
>>>>>
>>>>> I tried to simulate the CSRF manually (and I plan to use Zap as well) and I
>>>>> got this error -
>>>>>
>>>>> Invalid or missing CSRF token to path '/EntitySQLProcessor'
>>>>>
>>>>> I logged in to OFBiz and then used an HTML form to perform the attack and
>>>>> the patch successfully prevented.
>>>>>
>>>>> So it looks good to me. I will let you know how it goes with ZAP.
>>>>>
>>>>> Best,
>>>>> Girish
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 7, 2020 at 3:30 PM Jacques Le Roux <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> This is my 1st weekly reminder :)
>>>>>>
>>>>>> As you may know CSRF attacks are very bad. TL;DR: They are hard to provoke
>>>>>> but once you are able to create one, mostly using social engineering, they
>>>>>> can be "/devastating for both the business and user/".[1]
>>>>>>
>>>>>> OFBiz is currently riddled with CSRF vulnerabilities, all not idempotent
>>>>>> URLs[2] are susceptible to be attacked. James started an effort to fix them
>>>>>> with OFBIZ-11306 and I joined him.
>>>>>>
>>>>>> Though, after almost 3 months of work, I'm pretty confident about our
>>>>>> results, I have investigated how to validate our effort, with 3 mains
>>>>>> penetrations tools: Burp, Owasp Zap and Qualys.
>>>>>>
>>>>>> I notably followed[3]. Since we have (normally) covered all cases (see
>>>>>> OFBIZ-11306 description), I did not find a way to penetrate using this
>>>>>> method.
>>>>>>
>>>>>> Moreover, I'm a developer not a penetration tester. And, for misc.
>>>>>> reasons, I find quite painful to use those tools when it comes to CSRF,
>>>>>> even if
>>>>>> it's well explained in[3].
>>>>>>
>>>>>> I did not either find an easy way to automatically test all URLs for CSRF
>>>>>> vulnerabilities. It seems to me that the most powerful tool is Qualys but
>>>>>> so
>>>>>> far I have been unable to scan a localhost instance. I expect to work on
>>>>>> that next week. If I can't get it working it would be nice to have a domain
>>>>>> where to put the changes and launch Qualys, and Zap that I have to test
>>>>>> for the same also, against this domain.
>>>>>>
>>>>>> Another aspect I'd be interested in are regressions. I don't think there
>>>>>> should be any, but if you can apply the patch, or use my fork branch (see
>>>>>> OFBIZ-11425), and have a short tour it would be good.
>>>>>>
>>>>>> [1]
>>>>>> https://www.imperva.com/learn/application-security/csrf-cross-site-request-forgery/
>>>>>> [2] this is security jargon :), and idempotent URL is one that does not
>>>>>> change the state of the application. It's a bit more than safe URL:
>>>>>> http://restcookbook.com/HTTP%20Methods/idempotency/
>>>>>> [3]
>>>>>> https://portswigger.net/support/using-burp-to-test-for-cross-site-request-forgery
>>>>>>
>>>>>> TIA
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 29/02/2020 à 11:01, Pierre Smits a écrit :
>>>>>>> Thanks for the info, and the persistence to keep it in the attention
>>>>>> span,
>>>>>>> Jacques.
>>>>>>>
>>>>>>> Met vriendelijke groet,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>> *Proud* *contributor** of* Apache OFBiz<https://ofbiz.apache.org/>
>>>>>> since
>>>>>>> 2008 (without privileges)
>>>>>>>
>>>>>>> *Apache Trafodion<https://trafodion.apache.org>, Vice President*
>>>>>>> *Apache Directory<https://directory.apache.org>, PMC Member*
>>>>>>> Apache Incubator<https://incubator.apache.org>, committer
>>>>>>> Apache Steve<https://steve.apache.org>, committer
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>>> For those interested, it's maybe easier to test to simply apply the last
>>>>>>>> patches (framework + plugins) at OFBIZ-11306
>>>>>>>>
>>>>>>>> Also if I see nothing happening, I'll do a reminder every week...
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> Le 27/02/2020 à 17:28, Jacques Le Roux a écrit :
>>>>>>>>> Forgot to say that w/ or w/o test I'll commit in 1 month...
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>> Le 27/02/2020 à 15:08, Jacques Le Roux a écrit :
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> After working with James, who initiated the "POC for CSRF Token"
>>>>>>>> effort, onhttps://issues.apache.org/jira/browse/OFBIZ-11306
>>>>>>>>>> I have created OFBIZ-11425 to ask for all possible help to review and
>>>>>>>> test.
>>>>>>>>>> TIA
>>>>>>>>>>
>>>>>>>>>> Jacques
>>>>>>>>>>
>

[Jacques Le Roux]

Le 20/03/2020 à 08:44, Jacques Le Roux a écrit :

> If we do so, I have a question. With NoCsrfDefenseStrategy we have the possibility to bypass the CSRF defense. It's convenient for development,
> because else, in this mode, the CSRF defense is quite intrusive. *
>
> I propose to use it also in demo mode. Because we should not expect CSRF attacks on the demos (stable R17 and trunk) and if even it happens the
> consequences should not be important. Only alteration of the DB should be expected and nothing should happen out of that. So no consequences for the
> VM and for the apache.org domain. If somebody see a risk doing so please chime in before I patch OFBiz.
>
> @Swapnil, I know you plan to update the demos in order to make R17 stable, and R16 old. If nobody disagree about bypassing the CSRF defense on demo,
> it's only a matter of applying this patch:
>
> diff --git framework/security/config/security.properties framework/security/config/security.properties
> index 55c2b6a41a..5b06692d88 100644
> --- framework/security/config/security.properties
> +++ framework/security/config/security.properties
> @@ -169,4 +169,4 @@ csrf.entity.request.limit=
>
>  # csrf defense strategy. Default is org.apache.ofbiz.security.CsrfDefenseStrategy if not specified.
>  # use org.apache.ofbiz.security.NoCsrfDefenseStrategy to disable CSRF check totally.
> -csrf.defense.strategy=
> +csrf.defense.strategy=org.apache.ofbiz.security.NoCsrfDefenseStrategy
>
> I hope all is clear for everybody. The CSRF defense is a major change, fortunately not in development mode. Please verify it's OK with you before we
> apply the plan above

Hi,

I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
interested in stable, would  see the real situation.

And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
they certainly will do locally.

If nobody disagree we will do so at https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil

If we do so, the link https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y will no longer work.

https://demo-stable.ofbiz.apache.org/ordermgr should be used and we need to update https://ofbiz.apache.org/ofbiz-demos.html for that.

Jacques

[James Yong-2]

+1 with CSRF defense enabled in Demo
 

> Hi,
>
> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
> interested in stable, would  see the real situation.
>
> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
> they certainly will do locally.
>
> If nobody disagree we will do so at https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
>
> If we do so, the link https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y will no longer work.
>
> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
>
> Jacques
>
>

[Jacques Le Roux]

Hi All,

Before I create a PR as a last opportunity to allow reviews and tests, I'd like to ask 2 last questions:

 1. should we not use a JWT rather than a (pseudo) random value for the CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
    random values generated by java.security.SecureRandom, as currently used, are safe enough. It's just that I wonder about the timeout. Should we care?
 2. In relation with OFBIZ-4956, we need to check the remaining 195 cases where auth="false" and decide if we should change to "true", with the CSRF
    defense then used by default. In other cases (auth="false" must remain) we need to decide if should set the CSRF token check to false.

Apart that my https://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306 branch is ready to create a PR. We can't wait too
long about those 2 points, even if the 2nd needs a "bit" of work. Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.

Thanks

Jacques


Le 26/03/2020 à 07:39, James Yong a écrit :

> +1 with CSRF defense enabled in Demo
>  
>> Hi,
>>
>> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
>> interested in stable, would  see the real situation.
>>
>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
>> they certainly will do locally.
>>
>> If nobody disagree we will do so at https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
>>
>> If we do so, the link https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y will no longer work.
>>
>> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
>>
>> Jacques
>>
>>

[Jacques Le Roux]

Hi,

Of course, I have my own opinion. Here are my answers to these questions.

 1. By default in OFBiz the session timeout is 1 hour. After that, OFBiz generates a new CSRF token before you sign in. I think for OFBiz applications
    it's enough security. Of course we could have more fancy defenses like banks which are using random numeric pads for authentication and two-factor
    authentication for important operations. Or companies like GitHub which use two-factor authentication in case of machine or browser change. I
    don't think it's needed OOTB for OFBiz applications. Some users may need it but it's then to them to implement what they specifically need. So
    random values generated by java.security.SecureRandom are safe enough in my opinion.
 2. If someone tries to use a not auth protected request the CSRF defenses (token + same-site) will not allow it from another domain if csrf-token is
    not set to false. That's already reassuring and we maybe not need to worry much about the remaining 195 cases where auth="false". Because there
    are some obviously needed, like all those related to login or password change. For the others it may turn out that they are also needed for other
    reasons. For them we need to test them one by one and in some case need to set csrf-token to false, for instance in case of requests in an
    anonymous flow. So finally, despite the remaining 195 cases, it should not be too hard and too long to decide on this.

Also note that with OFBIZ-11470 <https://issues.apache.org/jira/browse/OFBIZ-11470> we are more secured, in a CSRF perspective, with the same-site
cookie attribute. It's not perfect in itself, but according to OWASP, it's the perfect duo for CSRF defense when associated with CSRF tokens.

I continue to work on the remaining 195 cases where auth="false"...

HTH

Jacques

Le 27/03/2020 à 19:16, Jacques Le Roux a écrit :

> Hi All,
>
> Before I create a PR as a last opportunity to allow reviews and tests, I'd like to ask 2 last questions:
>
> 1. should we not use a JWT rather than a (pseudo) random value for the CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
>    random values generated by java.security.SecureRandom, as currently used, are safe enough. It's just that I wonder about the timeout. Should we
> care?
> 2. In relation with OFBIZ-4956, we need to check the remaining 195 cases where auth="false" and decide if we should change to "true", with the CSRF
>    defense then used by default. In other cases (auth="false" must remain) we need to decide if should set the CSRF token check to false.
>
> Apart that my https://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306 branch is ready to create a PR. We can't wait too
> long about those 2 points, even if the 2nd needs a "bit" of work. Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
>
> Thanks
>
> Jacques
>
>
> Le 26/03/2020 à 07:39, James Yong a écrit :
>> +1 with CSRF defense enabled in Demo
>>> Hi,
>>>
>>> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
>>> interested in stable, would  see the real situation.
>>>
>>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
>>> they certainly will do locally.
>>>
>>> If nobody disagree we will do so at https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
>>>
>>> If we do so, the link https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y will no longer
>>> work.
>>>
>>> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
>>>
>>> Jacques
>>>
>>>

[grv]

Hi Jacques

I second your points. However, I have the following question -

Since you have explored and followed OWASP very extensively, do you think
with the introduction of same-site attribute, the whole concept of CSRF
token becomes somewhat redundant, provided almost every browser has the
support for this attribute now?
I haven't gone into too much detail, so my understanding on this is
limited. However, from what I understood, same-site has the ability to
become an all-in-one solution for CSRF attacks provided browsers honour it.

Best,
Girish


On Sat, Mar 28, 2020 at 2:39 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi,
>
> Of course, I have my own opinion. Here are my answers to these questions.
>
>  1. By default in OFBiz the session timeout is 1 hour. After that, OFBiz
> generates a new CSRF token before you sign in. I think for OFBiz
> applications
>     it's enough security. Of course we could have more fancy defenses like
> banks which are using random numeric pads for authentication and two-factor
>     authentication for important operations. Or companies like GitHub
> which use two-factor authentication in case of machine or browser change. I
>     don't think it's needed OOTB for OFBiz applications. Some users may
> need it but it's then to them to implement what they specifically need. So
>     random values generated by java.security.SecureRandom are safe enough
> in my opinion.
>  2. If someone tries to use a not auth protected request the CSRF defenses
> (token + same-site) will not allow it from another domain if csrf-token is
>     not set to false. That's already reassuring and we maybe not need to
> worry much about the remaining 195 cases where auth="false". Because there
>     are some obviously needed, like all those related to login or password
> change. For the others it may turn out that they are also needed for other
>     reasons. For them we need to test them one by one and in some case
> need to set csrf-token to false, for instance in case of requests in an
>     anonymous flow. So finally, despite the remaining 195 cases, it should
> not be too hard and too long to decide on this.
>
> Also note that with OFBIZ-11470 <
> https://issues.apache.org/jira/browse/OFBIZ-11470> we are more secured,
> in a CSRF perspective, with the same-site
> cookie attribute. It's not perfect in itself, but according to OWASP, it's
> the perfect duo for CSRF defense when associated with CSRF tokens.
>
> I continue to work on the remaining 195 cases where auth="false"...
>
> HTH
>
> Jacques
>
> Le 27/03/2020 à 19:16, Jacques Le Roux a écrit :
> > Hi All,
> >
> > Before I create a PR as a last opportunity to allow reviews and tests,
> I'd like to ask 2 last questions:
> >
> > 1. should we not use a JWT rather than a (pseudo) random value for the
> CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
> >    random values generated by java.security.SecureRandom, as currently
> used, are safe enough. It's just that I wonder about the timeout. Should we
> > care?
> > 2. In relation with OFBIZ-4956, we need to check the remaining 195 cases
> where auth="false" and decide if we should change to "true", with the CSRF
> >    defense then used by default. In other cases (auth="false" must
> remain) we need to decide if should set the CSRF token check to false.
> >
> > Apart that my
> https://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306
> branch is ready to create a PR. We can't wait too
> > long about those 2 points, even if the 2nd needs a "bit" of work.
> Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
> >
> > Thanks
> >
> > Jacques
> >
> >
> > Le 26/03/2020 à 07:39, James Yong a écrit :
> >> +1 with CSRF defense enabled in Demo
> >>> Hi,
> >>>
> >>> I thought about that a bit more. I suggest to let the stable version
> (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
> >>> interested in stable, would  see the real situation.
> >>>
> >>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often
> brought to use the trunk for development reasons, would have more latitude;
> as
> >>> they certainly will do locally.
> >>>
> >>> If nobody disagree we will do so at
> https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
> >>>
> >>> If we do so, the link
> https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
> will no longer
> >>> work.
> >>>
> >>> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we
> need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
> >>>
> >>> Jacques
> >>>
> >>>
>

[Jacques Le Roux]

Hi Girish,

Thanks for asking!

I have read in several up to date places that it's better to have both. Notably when you use the lax option that I have left users to choice to,
because this might be needed in some cases. So the CSRF token defense offers a second fence.

OWASP clearly explains why at:
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#samesite-cookie-attribute

Other references:
https://security.stackexchange.com/questions/121971/will-same-site-cookies-be-sufficent-protection-against-csrf-and-xss
https://blog.worldline.tech/2018/07/02/same-site-cookie-a-new-protection-against-csrf.html
https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/

Note that if you want to avoid the heaviness and drawbacks of CSRF token defense (yes, though we made our best, there are some) you can use the
NoCsrfDefenseStrategy. The Same Site Cookie Attribute being set to strict by default will save your back.  BTW this leads me to think that we can now
use the NoCsrfDefenseStrategy on demos.

Jacques

Le 28/03/2020 à 10:39, Girish Vasmatkar a écrit :

> Hi Jacques
>
> I second your points. However, I have the following question -
>
> Since you have explored and followed OWASP very extensively, do you think
> with the introduction of same-site attribute, the whole concept of CSRF
> token becomes somewhat redundant, provided almost every browser has the
> support for this attribute now?
> I haven't gone into too much detail, so my understanding on this is
> limited. However, from what I understood, same-site has the ability to
> become an all-in-one solution for CSRF attacks provided browsers honour it.
>
> Best,
> Girish
>
>
> On Sat, Mar 28, 2020 at 2:39 PM Jacques Le Roux <
> [hidden email]> wrote:
>
>> Hi,
>>
>> Of course, I have my own opinion. Here are my answers to these questions.
>>
>>   1. By default in OFBiz the session timeout is 1 hour. After that, OFBiz
>> generates a new CSRF token before you sign in. I think for OFBiz
>> applications
>>      it's enough security. Of course we could have more fancy defenses like
>> banks which are using random numeric pads for authentication and two-factor
>>      authentication for important operations. Or companies like GitHub
>> which use two-factor authentication in case of machine or browser change. I
>>      don't think it's needed OOTB for OFBiz applications. Some users may
>> need it but it's then to them to implement what they specifically need. So
>>      random values generated by java.security.SecureRandom are safe enough
>> in my opinion.
>>   2. If someone tries to use a not auth protected request the CSRF defenses
>> (token + same-site) will not allow it from another domain if csrf-token is
>>      not set to false. That's already reassuring and we maybe not need to
>> worry much about the remaining 195 cases where auth="false". Because there
>>      are some obviously needed, like all those related to login or password
>> change. For the others it may turn out that they are also needed for other
>>      reasons. For them we need to test them one by one and in some case
>> need to set csrf-token to false, for instance in case of requests in an
>>      anonymous flow. So finally, despite the remaining 195 cases, it should
>> not be too hard and too long to decide on this.
>>
>> Also note that with OFBIZ-11470 <
>> https://issues.apache.org/jira/browse/OFBIZ-11470> we are more secured,
>> in a CSRF perspective, with the same-site
>> cookie attribute. It's not perfect in itself, but according to OWASP, it's
>> the perfect duo for CSRF defense when associated with CSRF tokens.
>>
>> I continue to work on the remaining 195 cases where auth="false"...
>>
>> HTH
>>
>> Jacques
>>
>> Le 27/03/2020 à 19:16, Jacques Le Roux a écrit :
>>> Hi All,
>>>
>>> Before I create a PR as a last opportunity to allow reviews and tests,
>> I'd like to ask 2 last questions:
>>> 1. should we not use a JWT rather than a (pseudo) random value for the
>> CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
>>>     random values generated by java.security.SecureRandom, as currently
>> used, are safe enough. It's just that I wonder about the timeout. Should we
>>> care?
>>> 2. In relation with OFBIZ-4956, we need to check the remaining 195 cases
>> where auth="false" and decide if we should change to "true", with the CSRF
>>>     defense then used by default. In other cases (auth="false" must
>> remain) we need to decide if should set the CSRF token check to false.
>>> Apart that my
>> https://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306
>> branch is ready to create a PR. We can't wait too
>>> long about those 2 points, even if the 2nd needs a "bit" of work.
>> Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>> Le 26/03/2020 à 07:39, James Yong a écrit :
>>>> +1 with CSRF defense enabled in Demo
>>>>> Hi,
>>>>>
>>>>> I thought about that a bit more. I suggest to let the stable version
>> (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
>>>>> interested in stable, would  see the real situation.
>>>>>
>>>>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often
>> brought to use the trunk for development reasons, would have more latitude;
>> as
>>>>> they certainly will do locally.
>>>>>
>>>>> If nobody disagree we will do so at
>> https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
>>>>> If we do so, the link
>> https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
>> will no longer
>>>>> work.
>>>>>
>>>>> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we
>> need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
>>>>> Jacques
>>>>>
>>>>>

[James Yong-2]

Hi Jacques,

For 1, seems like a ICsrfDefenseStrategy class implementation issue. We can use another Jira for the enhancement / discussion when this JIRA (OFBIZ-11306) is completed.

For 2, csrf-token check is independent of auth check, and the current implementation should work as it is. So reviewing whether auth="false" be "true", should be in another JIRA (i.e. OFBIZ-4956). If there is a need for all auth="false" to default to csrf-token="false", we can implement another ICsrfDefenseStrategy class or modify the existing CsrfDefenseStrategy class.

Regards,
James

On 2020/03/27 18:16:58, Jacques Le Roux <[hidden email]> wrote:

> Hi All,
>
> Before I create a PR as a last opportunity to allow reviews and tests, I'd like to ask 2 last questions:
>
>  1. should we not use a JWT rather than a (pseudo) random value for the CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
>     random values generated by java.security.SecureRandom, as currently used, are safe enough. It's just that I wonder about the timeout. Should we care?
>  2. In relation with OFBIZ-4956, we need to check the remaining 195 cases where auth="false" and decide if we should change to "true", with the CSRF
>     defense then used by default. In other cases (auth="false" must remain) we need to decide if should set the CSRF token check to false.
>
> Apart that my https://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306 branch is ready to create a PR. We can't wait too
> long about those 2 points, even if the 2nd needs a "bit" of work. Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
>
> Thanks
>
> Jacques
>
>
> Le 26/03/2020 à 07:39, James Yong a écrit :
> > +1 with CSRF defense enabled in Demo
> >  
> >> Hi,
> >>
> >> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
> >> interested in stable, would  see the real situation.
> >>
> >> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
> >> they certainly will do locally.
> >>
> >> If nobody disagree we will do so at https://issues.apache.org/jira/browse/OFBIZ-11472 with Swapnil
> >>
> >> If we do so, the link https://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y will no longer work.
> >>
> >> https://demo-stable.ofbiz.apache.org/ordermgr should be used and we need to update https://ofbiz.apache.org/ofbiz-demos.html for that.
> >>
> >> Jacques
> >>
> >>
>

[Jacques Le Roux]

Hi James,

 1. I like the idea. Maybe we could create the class but let the implementation (with explanations) for those who really need it?
 2. I did not mean there was a correlation between csrf-token check and auth check. My main idea is to avoid hardcoded things like

         if (requestUri.equals("main")) {             return false;         } else {

We can set that in controllers using csrf-token="false", like it is for "logout". It's not difficult, just a global S/R. I thought there were other
cases but it seems not. so I now wonder if it's a good idea.

I don't think there is a need to systematise a default to csrf-token="false" when auth="false". I just want to work on OFBIZ-4956 and while doing so
check that if we change auth="false" to true, as it implies csrf-token="true", there will not be undesired side effects. And in other cases
(auth="false" must remain) we need to decide if should set the CSRF token check to false.

Anyway it does not hinder our work on CSRF, but I feel I now miss something that I wanted to say then, just an intuitive feeling, certainly nothing
serious

I think we are ready and I'll soon commit...

Jacques

Le 29/03/2020 à 03:28, James Yong a écrit :

> Hi Jacques,
>
> For 1, seems like a ICsrfDefenseStrategy class implementation issue. We can use another Jira for the enhancement / discussion when this JIRA (OFBIZ-11306) is completed.
>
> For 2, csrf-token check is independent of auth check, and the current implementation should work as it is. So reviewing whether auth="false" be "true", should be in another JIRA (i.e. OFBIZ-4956). If there is a need for all auth="false" to default to csrf-token="false", we can implement another ICsrfDefenseStrategy class or modify the existing CsrfDefenseStrategy class.
>
> Regards,
> James
>
> On 2020/03/27 18:16:58, Jacques Le Roux<[hidden email]>  wrote:
>> Hi All,
>>
>> Before I create a PR as a last opportunity to allow reviews and tests, I'd like to ask 2 last questions:
>>
>>   1. should we not use a JWT rather than a (pseudo) random value for the CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
>>      random values generated by java.security.SecureRandom, as currently used, are safe enough. It's just that I wonder about the timeout. Should we care?
>>   2. In relation with OFBIZ-4956, we need to check the remaining 195 cases where auth="false" and decide if we should change to "true", with the CSRF
>>      defense then used by default. In other cases (auth="false" must remain) we need to decide if should set the CSRF token check to false.
>>
>> Apart that myhttps://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306  branch is ready to create a PR. We can't wait too
>> long about those 2 points, even if the 2nd needs a "bit" of work. Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
>>
>> Thanks
>>
>> Jacques
>>
>>
>> Le 26/03/2020 à 07:39, James Yong a écrit :
>>> +1 with CSRF defense enabled in Demo
>>>    
>>>> Hi,
>>>>
>>>> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
>>>> interested in stable, would  see the real situation.
>>>>
>>>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
>>>> they certainly will do locally.
>>>>
>>>> If nobody disagree we will do so athttps://issues.apache.org/jira/browse/OFBIZ-11472  with Swapnil
>>>>
>>>> If we do so, the linkhttps://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y  will no longer work.
>>>>
>>>> https://demo-stable.ofbiz.apache.org/ordermgr  should be used and we need to updatehttps://ofbiz.apache.org/ofbiz-demos.html  for that.
>>>>
>>>> Jacques
>>>>
>>>>

[James Yong-2]

Hi Jacques,

Can look at JWT enhancement later.

+1 for commit.

Regards,
James

On 2020/04/04 13:10:18, Jacques Le Roux <[hidden email]> wrote:

> Hi James,
>
>  1. I like the idea. Maybe we could create the class but let the implementation (with explanations) for those who really need it?
>  2. I did not mean there was a correlation between csrf-token check and auth check. My main idea is to avoid hardcoded things like
>
>          if (requestUri.equals("main")) {             return false;         } else {
>
> We can set that in controllers using csrf-token="false", like it is for "logout". It's not difficult, just a global S/R. I thought there were other
> cases but it seems not. so I now wonder if it's a good idea.
>
> I don't think there is a need to systematise a default to csrf-token="false" when auth="false". I just want to work on OFBIZ-4956 and while doing so
> check that if we change auth="false" to true, as it implies csrf-token="true", there will not be undesired side effects. And in other cases
> (auth="false" must remain) we need to decide if should set the CSRF token check to false.
>
> Anyway it does not hinder our work on CSRF, but I feel I now miss something that I wanted to say then, just an intuitive feeling, certainly nothing
> serious
>
> I think we are ready and I'll soon commit...
>
> Jacques
>
> Le 29/03/2020 à 03:28, James Yong a écrit :
> > Hi Jacques,
> >
> > For 1, seems like a ICsrfDefenseStrategy class implementation issue. We can use another Jira for the enhancement / discussion when this JIRA (OFBIZ-11306) is completed.
> >
> > For 2, csrf-token check is independent of auth check, and the current implementation should work as it is. So reviewing whether auth="false" be "true", should be in another JIRA (i.e. OFBIZ-4956). If there is a need for all auth="false" to default to csrf-token="false", we can implement another ICsrfDefenseStrategy class or modify the existing CsrfDefenseStrategy class.
> >
> > Regards,
> > James
> >
> > On 2020/03/27 18:16:58, Jacques Le Roux<[hidden email]>  wrote:
> >> Hi All,
> >>
> >> Before I create a PR as a last opportunity to allow reviews and tests, I'd like to ask 2 last questions:
> >>
> >>   1. should we not use a JWT rather than a (pseudo) random value for the CSRF token, this for timeout reason? Don't get me wrong I'm sure that the
> >>      random values generated by java.security.SecureRandom, as currently used, are safe enough. It's just that I wonder about the timeout. Should we care?
> >>   2. In relation with OFBIZ-4956, we need to check the remaining 195 cases where auth="false" and decide if we should change to "true", with the CSRF
> >>      defense then used by default. In other cases (auth="false" must remain) we need to decide if should set the CSRF token check to false.
> >>
> >> Apart that myhttps://github.com/JacquesLeRoux/ofbiz-framework/tree/POC-for-CSRF-Token-OFBIZ-11306  branch is ready to create a PR. We can't wait too
> >> long about those 2 points, even if the 2nd needs a "bit" of work. Anyway, for now I'll wait answers, and hopefully help for OFBIZ-4956.
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
> >> Le 26/03/2020 à 07:39, James Yong a écrit :
> >>> +1 with CSRF defense enabled in Demo
> >>>    
> >>>> Hi,
> >>>>
> >>>> I thought about that a bit more. I suggest to let the stable version (soon, R17) as is, ie with  CSRF defense enabled. This way users, mostly
> >>>> interested in stable, would  see the real situation.
> >>>>
> >>>> And to use the NoCsrfDefenseStrategy in trunk. So developers, often brought to use the trunk for development reasons, would have more latitude; as
> >>>> they certainly will do locally.
> >>>>
> >>>> If nobody disagree we will do so athttps://issues.apache.org/jira/browse/OFBIZ-11472  with Swapnil
> >>>>
> >>>> If we do so, the linkhttps://demo-stable.ofbiz.apache.org/ordermgr/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y  will no longer work.
> >>>>
> >>>> https://demo-stable.ofbiz.apache.org/ordermgr  should be used and we need to updatehttps://ofbiz.apache.org/ofbiz-demos.html  for that.
> >>>>
> >>>> Jacques
> >>>>
> >>>>
>