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
