hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wilm Schumacher <wilm.schumac...@cawoom.com>
Subject Re: hbase attack scenarios?
Date Thu, 07 Aug 2014 04:14:39 GMT


Am 06.08.2014 um 19:07 schrieb Andrew Purtell:
> We have no known vulnerabilities that equate to a SQL injection attack
> vulnerability. However, as Esteban says you'd want to treat HBase like any
> other datastore underpinning a production service and out of an abundance
> of caution deploy it into a secure enclave behind an internal service API,
> so random (possibly untrusted) clients are not hitting it directly.
this is of course a very good point. Not specific to hbase, but of
course true for hbase, too.

There should be of course only one type of client who hit the db
directly: the operating service clients.

> If you'd like to encrypt data flowing in and out of the secure enclave on
> the wire, deploy a KDC for cluster services and enable strong
> authentication plus SASL "auth-conf" protection level. Requires HBase
> 0.98.3 or higher (HBASE-11149).
thanks for the hints.

> The administrative UIs might have some kind of cross-site vulnerability
> because we don't worry about that; the UIs are expected to be firewalled
> for admin access only.
this is of course an important point, too.

So my takeaway from your responses are:
* make the db as encapsuled as possible => should be hit only by the
service api which has to be as restrictive as possible
* least priviliges of course
* every administrative interface should be firewalled (actually I would
also use openvpn, but the general point is clear)

However, this are very general points (true of course, but very general
and generic for all dbs or whatever system does the work).

That's there is nothing else to consider makes me kind of nervous. So if
there is something like a login, where the user can post "username" and
"password", and I do a getRow for the username (=rowkey), and than e.g.
make a check for the passwd (sha encrypted of course) etc. ... basically
the user can define whatever string the user wants to the getRow rowkey.

So the application does not need to "escape" the username for the getRow
which is then pumped more or less directly into the db (even if it is
just a getRow) ... just makes me nervous :D.

However, the attack scenarios pointed out by Esteban (evil RPC => OOME)
showed me, that I should restrict the possible strings (e.g. usernames
in this case) to e.g. [a-Z0-9]{2,100}, even if there is no possible
vulnerablity known.

Perhaps I did SQL too long to be a little more trustful. I guess this is
the adaption process for me and "real" NoSQL. God, I love hbase ;).

Thanks for the replies and keep up the good work

Wilm

Mime
View raw message