Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: CQL injection attacks?
From: Eric Evans <eevans@rackspace.com>
To: user@cassandra.apache.org
In-Reply-To: <1309630640.4e0f60b01d222@itchen.qinetiq.com>
References: <1309374771.4e0b7933ac960@itchen.qinetiq.com>
	 <BANLkTi=KuMtYArhzK=DRRdNk+xkARvBUeA@mail.gmail.com>
	 <BANLkTik9td-v+-H2PU7pLwxNeue6t6YpWw@mail.gmail.com>
	 <1309630640.4e0f60b01d222@itchen.qinetiq.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 02 Jul 2011 19:12:32 -0500
Message-ID: <1309651952.2053.51.camel@erebus.lan>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sat, 2011-07-02 at 19:17 +0100, dnallsopp@taz.qinetiq.com wrote:
> Just to illustrate; the typical injection pattern is:
> 
> String user = getUserName()
> String cql = "select * from users where KEY='"+user+"';"
> execute_cql(cql)
> 
> Now, if the user string is obtained from an external source (e.g. web
> form or
> other UI), then the attacker may enter a username of:
> 
> jsmith'; DROP COLUMNFAMILY 'users
> 
> which results in a CQL query of:
> 
> select * from users where KEY='jsmith'; DROP COLUMNFAMILY 'users'; 

No, each CQL query must contain exactly one statement, so this sort of
attack would not work.

And, as a rule of thumb, there are also no statement types that contain
other statements, which would be another common vector for an
injection.  

Now, there are batch statements for INSERT and UPDATE that are
essentially a collection of statements for that type.  That's probably
enough to say that, hypothetically speaking, it's possible in the
presence of an extremely buggy driver implementation, and some very
sloppy client code, for a clever attacker to create a new record (or
overwrite an existing one).

TTBMK, there are currently no drivers with bugs that egregious, so make
use of the driver's parameter substitution, sanitize your input, and you
shouldn't have anything to worry about (there is almost certainly less
risk of an injection attack than with SQL).

-- 
Eric Evans
eevans@rackspace.com