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