Multi-tenant Security
Locked
 
|
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 |
|
|
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 |
|
|
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 > |
Administrator
|
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" <[hidden email]> > 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 >> |
|
|
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" <[hidden email]> >> 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 >>> > |
|
Administrator
|
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" <[hidden email]> > 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" <[hidden email]> >>> 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 >>>> >> |
|
In reply to this post by Ruth Hoffman-2
Hi Ruth,
Your bank does not provide you with your own personal mainframe and your own personal database. Your bank balance is in a row in a table with other customers' balances above and below, which you should not be able to discover. We've been living with those risks for decades. Of course, an OFBiz user with permissions to log on to OFBiz and use its services should not have the rights to modify a classpath or upload a Groovy script. An OFBiz user should not have write permission on anything that is executable. That applies to single-tenant as well as multi-tenant situations. It applies to web applications in general, not just OFBiz, not just Java. If such an exploit were ever found, I would be willing to bet that a single-tenant OFBiz would be vulnerable as much as a multi-tenant OFBiz. Any OFBiz site that is public-facing (for example, for e-commerce) might have visitors who are hostile to the owner and seeking to exploit a security flaw to do damage. That applies to single-tenant as well as multi-tenant situations. Multi-tenancy should not greatly increase the risk of these or other exploits. You're running pretty well the same code, it's just a matter of what database you're connected to. So I don't see multi-tenant as a totally new or unique situation. It's a difference of degree, not kind. Cheers Paul Foxworthy
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
|
|
Paul is correct, the multi-tenant stuff has nothing to do with code deployment and tenants don't have access to code. If you use OFBiz in a multi-tenant mode all tenants will be running on the same code base. Whoever is managing that code base could write tenant-aware code so that it only operates for one or more tenants, but that would not be the tenant setting it up, it would be the group who controls the central code base. The confusion in your question, Ruth, seemed to be the the multi-tenant functionality somehow gives each tenant the ability to add code, and it does not. -David Paul Foxworthy wrote: > Hi Ruth, > > Your bank does not provide you with your own personal mainframe and your own > personal database. Your bank balance is in a row in a table with other > customers' balances above and below, which you should not be able to > discover. We've been living with those risks for decades. > > Of course, an OFBiz user with permissions to log on to OFBiz and use its > services should not have the rights to modify a classpath or upload a Groovy > script. An OFBiz user should not have write permission on anything that is > executable. That applies to single-tenant as well as multi-tenant > situations. It applies to web applications in general, not just OFBiz, not > just Java. If such an exploit were ever found, I would be willing to bet > that a single-tenant OFBiz would be vulnerable as much as a multi-tenant > OFBiz. > > Any OFBiz site that is public-facing (for example, for e-commerce) might > have visitors who are hostile to the owner and seeking to exploit a security > flaw to do damage. That applies to single-tenant as well as multi-tenant > situations. > > Multi-tenancy should not greatly increase the risk of these or other > exploits. You're running pretty well the same code, it's just a matter of > what database you're connected to. > > So I don't see multi-tenant as a totally new or unique situation. It's a > difference of degree, not kind. > > Cheers > > Paul Foxworthy > > > Ruth Hoffman-2 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 >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Multi-tenant-Security-tp4336437p4337693.html > Sent from the OFBiz - User mailing list archive at Nabble.com. |
|
Administrator
|
In reply to this post by Jacques Le Roux
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" <[hidden email]> > 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" <[hidden email]> >> 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" <[hidden email]> >>>> 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 >>>>> >>> |
|
|
In reply to this post by David E. Jones-2
Hi Paul, David:
Thanks much for this further clarification. Please do not think I'm not denigrating the implementation in any way. I want to clearly articulate the alternatives to anyone who asks. And, many people have asked. Thanks again. Have a great day. Ruth On 1/29/12 2:34 AM, David E Jones wrote: > Paul is correct, the multi-tenant stuff has nothing to do with code > deployment and tenants don't have access to code. If you use OFBiz in a > multi-tenant mode all tenants will be running on the same code base. > Whoever is managing that code base could write tenant-aware code so that > it only operates for one or more tenants, but that would not be the > tenant setting it up, it would be the group who controls the central > code base. > > The confusion in your question, Ruth, seemed to be the the multi-tenant > functionality somehow gives each tenant the ability to add code, and it > does not. > > -David > > > Paul Foxworthy wrote: >> Hi Ruth, >> >> Your bank does not provide you with your own personal mainframe and your own >> personal database. Your bank balance is in a row in a table with other >> customers' balances above and below, which you should not be able to >> discover. We've been living with those risks for decades. >> >> Of course, an OFBiz user with permissions to log on to OFBiz and use its >> services should not have the rights to modify a classpath or upload a Groovy >> script. An OFBiz user should not have write permission on anything that is >> executable. That applies to single-tenant as well as multi-tenant >> situations. It applies to web applications in general, not just OFBiz, not >> just Java. If such an exploit were ever found, I would be willing to bet >> that a single-tenant OFBiz would be vulnerable as much as a multi-tenant >> OFBiz. >> >> Any OFBiz site that is public-facing (for example, for e-commerce) might >> have visitors who are hostile to the owner and seeking to exploit a security >> flaw to do damage. That applies to single-tenant as well as multi-tenant >> situations. >> >> Multi-tenancy should not greatly increase the risk of these or other >> exploits. You're running pretty well the same code, it's just a matter of >> what database you're connected to. >> >> So I don't see multi-tenant as a totally new or unique situation. It's a >> difference of degree, not kind. >> >> Cheers >> >> Paul Foxworthy >> >> >> Ruth Hoffman-2 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 >>> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble.com/Multi-tenant-Security-tp4336437p4337693.html >> Sent from the OFBiz - User mailing list archive at Nabble.com. |
|
|
In reply to this post by Jacques Le Roux
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" <[hidden email]> >> 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" <[hidden email]> >>> 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" <[hidden email]> >>>>> 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 >>>>>> >>>> > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |