Re: [TEST] Test "POC for CSRF Token"

[Jacques Le Roux]

Hi,

We actually had 2 problems to solve:

1. 8 tests don't pass on trunk.
2. Backport, the merge "worked" but we (at least) miss in RequestHandler.java 
the not backported WIP on REST with notably these missing methods:
 * RequestHandler::resolveURI (OFBIZ-10438)
 * UtilHttp::getRequestMethod "REST: adding segmented URI support", with 
also OFBIZ-11007 and OFBIZ-11332+OFBIZ-11007

With OFBIZ-11470 "Ensure that the SameSite attribute is set to 'strict' for all cookies" OFBiz is already protected from CSRF OOTB in all supported 
branches.


To makes things simple (at least for me) I have decided to not backport the CSRF Token work to current supported releases branches. And, as I have 
already expressed, to not use the CSRF Token defense OOTB in trunk. This solves the 2 problems above. This also avoids to backport some related Jiras 
like OFBIZ-11317 "Add 'controlPath' attribute to 'ofbizUrl' freemarker macro". It has also the advantage of simplifying committers work and demos.


If an user needs to use 'lax' for the SameSite attribute it would be her/his charge to make the backport. Easiest way is to revert the "REST" commits 
from trunk before backporting. Of course if a committer wants to backport the CSRF Token work with "REST" commits in, it's open, another Jira would be 
needed.


You may notice that this does not solve the tests issue in case someone wants to use the CSRF Token defense, it just hides it. So I'll create another 
Jira for that.


And last but not least I have created: OFBIZ-11585 "Update security.adoc with few 
words about our CSRF defense strategy"

Jacques

Le 04/04/2020 à 21:02, Jacques Le Roux a écrit :

Hi James,

The backports in R18 and R17 went well but for RequestHandler.java

We will need to do the merge by hand. I'll begin and let you know

Later...

Jacques

Le 04/04/2020 à 19:19, Jacques Le Roux a écrit :

Hi James, All,

Done, the CSRF defense is in trunk and I'll backport it ASAP (it has a CVE). 
But I need to check that's all is OK before.

There are more things to do anyway...

Jacques

Le 04/04/2020 à 17:48, James Yong a écrit :

Hi Jacques,

Can look at JWT enhancement later.

+1 for commit.

Regards,
James

On 2020/04/04 13:10:18, Jacques Le Roux  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  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 

Re: [TEST] Test "POC for CSRF Token"

[Jacques Le Roux]

Hi James,

The backports in R18 and R17 went well but for RequestHandler.java

We will need to do the merge by hand. I'll begin and let you know

Later...

Jacques

Le 04/04/2020 à 19:19, Jacques Le Roux a écrit :

Hi James, All,

Done, the CSRF defense is in trunk and I'll backport it ASAP (it has a CVE). 
But I need to check that's all is OK before.

There are more things to do anyway...

Jacques

Le 04/04/2020 à 17:48, James Yong a écrit :

Hi Jacques,

Can look at JWT enhancement later.

+1 for commit.

Regards,
James

On 2020/04/04 13:10:18, Jacques Le Roux  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  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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

[Jacques Le Roux]

Hi James, All,

Done, the CSRF defense is in trunk and I'll backport it ASAP (it has a CVE). 
But I need to check that's all is OK before.

There are more things to do anyway...

Jacques

Le 04/04/2020 à 17:48, James Yong a écrit :

Hi Jacques,

Can look at JWT enhancement later.

+1 for commit.

Regards,
James

On 2020/04/04 13:10:18, Jacques Le Roux  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  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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

[James Yong]

Hi Jacques,

Can look at JWT enhancement later.

+1 for commit. 

Regards,
James

On 2020/04/04 13:10:18, Jacques Le Roux  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  
> > 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=ofbiz=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
> 
> 
> 

Re: [TEST] Test "POC for CSRF Token"

[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  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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

[James Yong]

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  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=ofbiz=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
> >>
> >>
> 

Re: [TEST] Test "POC for CSRF Token"

[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 <
jacques.le.r...@les7arts.com> 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 

Re: [TEST] Test "POC for CSRF Token"

[Girish Vasmatkar]

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 <
jacques.le.r...@les7arts.com> 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=ofbiz=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
> >>>
> >>>
>

Re: [TEST] Test "POC for CSRF Token"

[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  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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

[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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

[James Yong]

+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=ofbiz=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
> 
> 

Re: [TEST] Test "POC for CSRF Token"

[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=ofbiz=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

Re: [TEST] Test "POC for CSRF Token"

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

Re: [TEST] Test "POC for CSRF Token"

[Michael Brohl]

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 


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]

Re: [TEST] Test "POC for CSRF Token"

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

Re: [TEST] Test "POC for CSRF Token"

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

since

2008 (without privileges)

*Apache Trafodion, Vice President*
*Apache Directory, PMC Member*
Apache Incubator, committer
Apache Steve, committer


On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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

Re: [TEST] Test "POC for CSRF Token"

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

since

2008 (without privileges)

*Apache Trafodion, Vice President*
*Apache Directory, PMC Member*
Apache Incubator, committer
Apache Steve, committer


On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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

Re: [TEST] Test "POC for CSRF Token"

[Girish Vasmatkar]

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 
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
> since
> > 2008 (without privileges)
> >
> > *Apache Trafodion, Vice President*
> > *Apache Directory, PMC Member*
> > Apache Incubator, committer
> > Apache Steve, committer
> >
> >
> > On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> 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
> 
>

Re: [TEST] Test "POC for CSRF Token"

[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  since
2008 (without privileges)

*Apache Trafodion, Vice President*
*Apache Directory, PMC Member*
Apache Incubator, committer
Apache Steve, committer


On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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

Re: [TEST] Test "POC for CSRF Token"

[Pierre Smits]

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  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Sat, Feb 29, 2020 at 10:28 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> 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
> >>
>

Re: [TEST] Test "POC for CSRF Token"

[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

Re: [TEST] Test "POC for CSRF Token"

[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

[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