Re: CSRF attack and prevention

[Nicolas Malin]

Hi Girish,

Thanks for your warm. If you want to detail your please prefer send an 
email to secur...@ofbiz.apache.org instead of open an issue to JIRA.


Nicolas


On 02/09/2018 17:36, girish.vasmat...@hotwaxsystems.com wrote:

Hi All

  It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I 
am logged in to ofbiz instance on my local and create a sample standalone HTML 
page and try to submit to either a GET or a POST ofbiz URL, I am successfully 
through and various cookies (applicable to the domain) are also sent by the 
browser to Ofbiz instance. That essentially is CSRF. This can be reproduced 
with a script tag with a valid ofbiz URL as src and you can actually see in the 
developer console the request made through and response is received.

Of course this attack has a context - that the user is logged in and happens on 
the victim's browser.

I replaced ofbiz URL with gmail and made sure I am logged in to my gmail 
account. I saw a vague/obsure response from gmail in the console meaning it 
prevented itself.

  I feel we can handle it in multiple ways and one of the ways is adding 
SameSite cookie which is a fairly new concept and per latest information Chrome 
already supports it and FireFox has also added support for the same. Browsers 
supporting this Cookie will not send JSESSIONID or any other SameSite cookie to 
the request if the request is cross-site. Each cookie needs to be flagged with 
SameSite with possible values being strict or lax.
Here's its IETF draft - 
https://tools.ietf.org/html/draft-west-first-party-cookies-07

  I also think we should not rely on this as the sole prevention mechanism and 
should also do something on the server side in the sense that we should not 
rely on the browser support. Tomcat does support a filter - 
org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for every 
request and stores the same in session.

We should also add support for checking Origin and Referrer headers. I think 
there is a lot we can do.

I have not seen any reference in the current trunk code for both SameSite 
cookie and CsrfPreventionFilter filter. If we can make everyone on the same 
page on CSRF, I would like to propose we go ahead with this change. I think we 
will need to handle it in multiple ways.

I can create a JIRA with all details provided we have the necessary concord.


Thanks and Best regards,
Girish Vasmatkar
HotWax Systems

CSRF attack and prevention

[girish . vasmatkar]

Hi All

 It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I 
am logged in to ofbiz instance on my local and create a sample standalone HTML 
page and try to submit to either a GET or a POST ofbiz URL, I am successfully 
through and various cookies (applicable to the domain) are also sent by the 
browser to Ofbiz instance. That essentially is CSRF. This can be reproduced 
with a script tag with a valid ofbiz URL as src and you can actually see in the 
developer console the request made through and response is received.

Of course this attack has a context - that the user is logged in and happens on 
the victim's browser. 

I replaced ofbiz URL with gmail and made sure I am logged in to my gmail 
account. I saw a vague/obsure response from gmail in the console meaning it 
prevented itself.

 I feel we can handle it in multiple ways and one of the ways is adding 
SameSite cookie which is a fairly new concept and per latest information Chrome 
already supports it and FireFox has also added support for the same. Browsers 
supporting this Cookie will not send JSESSIONID or any other SameSite cookie to 
the request if the request is cross-site. Each cookie needs to be flagged with 
SameSite with possible values being strict or lax. 
Here's its IETF draft - 
https://tools.ietf.org/html/draft-west-first-party-cookies-07

 I also think we should not rely on this as the sole prevention mechanism and 
should also do something on the server side in the sense that we should not 
rely on the browser support. Tomcat does support a filter - 
org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for every 
request and stores the same in session.

We should also add support for checking Origin and Referrer headers. I think 
there is a lot we can do.

I have not seen any reference in the current trunk code for both SameSite 
cookie and CsrfPreventionFilter filter. If we can make everyone on the same 
page on CSRF, I would like to propose we go ahead with this change. I think we 
will need to handle it in multiple ways.

I can create a JIRA with all details provided we have the necessary concord.


Thanks and Best regards,
Girish Vasmatkar
HotWax Systems

Re: Move accounting ap and ar to plugin ?

[Jacques Le Roux]

Thanks Pierre,

Good and clear arguments!

But do you really need to show all your medals in each email :) ?

Jacques


Le 02/09/2018 à 10:14, Pierre Smits a écrit :

It is great to see that after approx. 2 years some viewpoints are swinging
towards having 3rd party solutions (the payment and shipment integrations)
disentangled from resp. accounting and product. With these disentanglements
these base components will be more business-domain oriented (process), and
easier to maintain and explain (documentation-wise).

Configuration- and overview-wise, each 3rd party solution integration
should be contained in its own component, feeding only transactional data
to the base application (payments to accounting, shipment-handling to
warehousing).
With the 3rd party payment integration solution MultSafepay, I outlined in
2016 how this could be achieved (see [1] and [2])

[1] https://github.com/ORRTIZ/omultisafepay
[2] https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement




Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Sun, Sep 2, 2018 at 9:33 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Taher,

Obviously AR and AP are parts of accounting, but they should not be shown
at the application level.

At the very least they should sub-menus of accounting. This would give
some air to the apps tabs, w/o separating them.

Then come the thirdparty accounting elements which are clearly defined in
java/org/apache/ofbiz/accounting/thirdparty but are also scattered in
other places (services, etc.)

I totally agree with Nicolas that they should not be part of accounting.
They are mostly payments means, but that does not mean they should be in
the accounting applications, they are 3rd parties elements.

Separating them in plugins would be a good thing, OFBIZ-7415 is a WIP
aimed at that.

Moreover some are outdated, if not deprecated. Ideal for instance should
be moved to the Attic:  OFBIZ-5303 is a WIP.

Jacques



Le 01/09/2018 à 20:19, Taher Alkhateeb a écrit :


Hi Nicolas,

I'm not an expert accountant, but if I'm not mistaken then accounts
receivable and accounts payable are a fundamental accounting function
that comes with any accounting system, and perhaps the only reason we
notice them is because they are defined as separate webapps.

I have no strong opinion, but I would suggest perhaps an opposite
direction, as in integrating the the accounts receivable and payable
to the accounting component. I don't understand why they were
separated to different webapps in the first place.
On Sat, Sep 1, 2018 at 3:22 PM Jacques Le Roux
 wrote:


That's a great idea Nicolas!

+1

Jacques


Le 01/09/2018 à 14:09, Nicolas Malin a écrit :


Hello,

After analyze the webapp accounting AR and accounting AP, I didn't see
any logic to keep them on the functional framework. The main webapp is
accounting, AP/AR are a business orientation that we can load at demand
through plugins.

Your opinion ?

PS: In the same idea we can move on separate plugin all thirdparty
accounting element to slimdown the accounting component and must harness the
plugin system :)

Nicolas

Re: Should we keep the multi-tenants feature in OFBiz?

[Jacques Le Roux]

Hi Rajesh,

Rest inline...

Le 29/08/2018 à 15:27, Rajesh Mallah a écrit :

Hi  ,

I strongly feel we should.

For me, multi-tenency is the key feature in supporting more number of 
organisations
with a single instance of Java/tomcat. Think of running 20  under-utilized 
OFBiz instances
each *locking* up say 1GB ram versus 1 multi-tenant OFBiz instance allocated 
with a
copious amount of RAM say 4-8GB ram.

a dozens or maybe even few hundreds tenants, after it begin to be a lot of 
DBs!


I would want to understand for whom does it becomes a *lot* of DB ?
I worked with a startup. They had a business model where they would only win if they could have tens of thousands of tenants (if not hundreds of 
thousands).

Their goal was to ultimately get millions of them. It was not about URIs, but 
*separated *DBs. Obviously OFBiz multi-tenant could not sustain that.


In case it is about persistent connections to 100s' of distinct uris (ie. 
host+user+db combination)
from the JDBC pool, we can offload the connection pooling feature to an external
pooler , (eg: pgpool or pgbouncer , in case of postgreSQL) , and convert the 
connection
mode from persistent to non-persistent at the tomcat level . So a *new* 
connection is made
on a HTTP request and disconnected as soon as the request is served.
in oracle we have: 
https://docs.oracle.com/cd/B28359_01/appdev.111/b28395/oci09adv.htm#LNOCI87721
in postgreSQL: 
https://dba.stackexchange.com/questions/56559/postgresql-high-availability-scalability-using-haproxy-and-pgbouncer
In case it is the sheer number of db connections i feel users can come up with 
their own
architectures suiting their environment.

Are you using your suggestions in production?



(disclaimer: I am not expert in tomcat but i am trying to draw parallels with 
other application servers)

And its not only a matter of resource sharing only, deploying  a new client on 
a multi tenant OFBiz
instance is 10 times simpler than creating a new instance and configuring a new 
OFBiz instance
itself ( discounting the factor or chef/puppet /salt/ansible/your favorite 
automation tool) .

Actually in their case the instance would have been initially always the same. 
So deploying copies was not a problem.


I feel It will be a big loss unless an equivalent feature is found out ,
the equivalent  IMHO is multi-tenant feature itself without the warts :-).

You are not the only one to express concerns. We need to consider that, but we 
also need to consider what tenants entails in OFBiz code.



@Jacques Le Roux  there is also:
https://issues.apache.org/jira/browse/OFBIZ-10284 for which i had worked on

Thanks for the reminder, more on that later...

Jacques


a patch.

my 2 cents

regds
mallah.


On Wed, Aug 29, 2018 at 6:19 PM Shi Jinghai mailto:huaru...@hotmail.com>> wrote:

Hi Jacques,

Honestly I was shocked by this email, I'm working on deploying OFBiz in 
Kubernetes, are you monitoring me?

In 2010, Kubernetes was quite new and not good enough, now it's the 
standard on cloud deploy management, and we can support it.

Before doing that, we have to answer some common questions in cloud running 
lifecycle, such as how may instances/requests can share one CPU, how
to deliver(create) an instance, how to isolate an instance, how to offline, 
how to remove, how to online again and etc.

Personally I don't think we have to remove current multi-tenants 
implements, add a SAAS implement would be OK.

Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com 
]
发送时间: 2018年8月29日 17:46
收件人: dev@ofbiz.apache.org 
主题: Should we keep the multi-tenants feature in OFBiz?

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not 
millions (actually they failed), of tenants, obviously OFBiz can't do that.

I don't break any secret to say that I was working with David (and Andrew) 
on a project in 2010 when David had to quickly answer to the client's
demand who wanted to have tenants. David brilliantly and quickly delivered, 
but it was only a start.

After many improvements, this feature still have some issues
https://issues.apache.org/jira/browse/OFBIZ-6066
https://issues.apache.org/jira/browse/OFBIZ-7900
https://issues.apache.org/jira/browse/OFBIZ-6164
https://issues.apache.org/jira/browse/OFBIZ-6065

Also this is somehow related
https://issues.apache.org/jira/browse/OFBIZ-6712

And most importantly
https://issues.apache.org/jira/browse/OFBIZ-7112
https://issues.apache.org/jira/browse/OFBIZ-7754

I recently read this article


https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/