Hi Jacques:
Thanks again for helping me understand the issues and sharing the same
on this venue (the mailing list). This information will clearly benefit
all those looking at this alternative.
Best of all, when people ask me about this, I can point them to the
mailing list and let them judge for themselves. I hope that is the case
since I am hardly a security expert.
Regards,
Ruth
On 1/29/12 6:06 AM, Jacques Le Roux wrote:
Was just thinking of that, you can consider roughly 2 types of
attacks: persistent and non-persistent.
Non-persistent attacks are the weaker type of attacks. Since the DB is
not compromised outsiders can't get control of the system,
the data are not at risks, notably the credentials!
Nowaydays, Deny Of Service is a well known non-persistent attack
(Anonymous). It's weak but powerfull: the system is down from
outside as long as the attackers want, unless you are able to
dynamically filter IPs address or packets in front-end
(http://en.wikipedia.org/wiki/Denial-of-service_attack#Prevention_and_response)
If the server is so attacked all tenants will be in the same
situation: nobody can access the system from the Web anyway. This is
the only case, I see, where a non persistent attack is really
damageable for all tenants. But it has no durable consequences.
So it's all about balance of choices. Though, if you need/want to
implement Software-As-A-Service (SAAS)
http://en.wikipedia.org/wiki/Software_as_a_service I don't see any
other choices...
Imagine you have to dymamically create clients (I mean tenants DBs for
clients). Only multi-tenant architecture allows to do so (not
implemented in OFBiz OOTB)
I hope these simple explanations help you to be reassured about
multi-tenants security, which is not OFBiz specific BTW (hence my
questions in dev ML)
Jacques
From: "Jacques Le Roux" <[email protected]>
Yes of course, we can't exclude this possibily, as you maybe read in
this article, the other types of vulnerabilites can be
exploited as well. And then, as all the tenants are sharing the same
system, one compromised tenant is potentially compromising
all the system.
The most possible type of attack, apart SQL injection, is XSS. To
really compromise other tenants, the XSS attack must be
permanent
(ie the compromising piece of javascript is stored in some way in the
DB, to be restored/reused). But then this will be only in
one
tenant DB and will not affect the other tenants. Because in OFBiz,
apart the 2 shared tenants specific tables, all the data are DB
separated (in other word OFBiz uses the Separate Databases schema:
http://msdn.microsoft.com/en-us/library/aa479086.aspx). And
it's
impossible, unless proved otherwise, to compromise the 2 shared
tenants specific tables because there are no ways to store a
javascript script there.
Anyway nobody will never be able to guarantee a 100% secure system.
So, as well explained in the article above and in the
Wikipedia
article, it's more about economics. For instance it's far more easier
with multi tenant to create a new account for a new client.
There are "endless" points to consider...
Jacques
From: "Ruth Hoffman" <[email protected]>
Hi Jacques:
Isn't there more to this than just SQL injection? It is not so much
that a single tenant is compromised. It is that a single
tenant might be the ONE doing the compromising. They might be able
to do this because they are a tenant and thus have access to
the system.
That is what I am wondering.
Thanks much for you insight.
Ruth
On 1/28/12 5:23 PM, Jacques Le Roux wrote:
If a SQL injection was able to compromise one tenant DB, it could
indeed be able to compromise the entire system
Note that there are no known/proven SQL injection vulnerabilites in
OFBiz.
The most relevant article I found is
http://iaas.ulitzer.com/node/1624391/mobile (look for "SQL
Injection In Multi Tenant
Database Design")
Also IBM seems to have deposed an intellectual property
http://ip.com/IPCOM/000184999
HTH
Jacques
From: "Ruth Hoffman" <[email protected]>
Hi Adrian:
Ah, but it is. From a business point-of-view, in the "single"
instance case, the only instance compromised is that instance. In
the multi-tenant case, all tenants (still the same instance) could
be compromised. True? or Not?
Regards,
Ruth
On 1/28/12 12:24 PM, Adrian Crum wrote:
The initial multi-tenant implementation was simply a way to run
multiple database instances on a single copy of OFBiz -
basically a user logs into a database instance. Other than that,
nothing much changed - so the dangers of someone hacking into
a multi-tenant instance of OFBiz is no different than a single
instance.
-Adrian
On 1/28/2012 5:17 PM, Ruth Hoffman wrote:
Hans, Pierre and several others have been kind enough to outline
the OFBiz multi-tenant value proposition.
I appreciate this primarily because I can't even count the
number of times prospective OFBiz users have asked me about it.
Now, with this background information, I feel comfortable
articulating the marketing value proposition.
What I still have great angst about, is the security side of
multi-tenancy. Perhaps someone can clarify or answer this basic
question:
What is to stop a hacker or otherwise malicious tenant from
writing a Groovy script (or Java program that is inserted on the
classpath when the system is rebooted) that acts as a "trojan
horse"? For example, how can you stop a savvy tenant from
adding
a program (or, I could even see hacking the Mini-lang since all
it is - is interpreted XML statements) that monitors (JVM)
memory and captures shopping cart objects or usernames and
passwords of the other tenants?
Really, I'd like to endorse multi-tenant implementations. But I
am still left with this one - very significant - security
question.
Anyone care to respond? Am I missing something here?
Regards,
Ruth Hoffman
