You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Brian O'Neill <bo...@alumni.brown.edu> on 2013/06/18 14:02:08 UTC

"SQL" Injection C* (via CQL & Thrift)

Mostly for fun, I wanted to throw this out there...

We are undergoing a security audit for our platform (C* + Elastic Search +
Storm).  One component of that audit is susceptibility to SQL injection.  I
was wondering if anyone has attempted to construct a SQL injection attack
against Cassandra?  Is it even possible?

I know the code paths fairly well, but...
Does there exists a path in the code whereby user data gets interpreted,
which could be exploited to perform user operations?

>From the Thrift side of things, I've always felt safe.  Data is opaque.
 Serializers are used to convert it to Bytes, and C* doesn't ever really do
anything with the data.

In examining the CQL java-driver, it looks like there might be a bit more
exposure to injection.  (or even CQL over Thrift)  I haven't dug into the
code yet, but dependent on which flavor of the API you are using, you may
be including user data in your statements.

Does anyone know if the CQL java-driver does anything to protect against
injection?  Or is it possible to say that the syntax is strict enough that
any embedded operations in data would not parse?

just some food for thought...
I'll be digging into this over the next couple weeks.  If people are
interested, I can throw a blog post out there with the findings.

-brian

-- 
Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://brianoneill.blogspot.com/
twitter: @boneill42

Re: "SQL" Injection C* (via CQL & Thrift)

Posted by Edward Capriolo <ed...@gmail.com>.
My first interaction with cassandra: ../nodeprobe -p 9160 ...
Hum I can't seem to reach it :) Ow its no longer running...

You've come along way baby.


On Thu, Jun 20, 2013 at 12:59 PM, Robert Coli <rc...@eventbrite.com> wrote:

> On Thu, Jun 20, 2013 at 2:15 AM, aaron morton <aa...@thelastpickle.com>
> wrote:
> >> As for the thrift side (i.e. using Hector or Astyanax), anyone have a
> crafty way to inject something?
> >
> > The only thing I've ever heard of coming close was a thrift bug that
> allowed a malformed request to crash the server. But that was a while ago
> https://issues.apache.org/jira/browse/CASSANDRA-475
>
> Oh, that brings me back. Literally my first interaction with a
> cassandra server :
>
> - start cassandra
> - telnet localhost 9160
> - "asdasdasdasdsa"
> - "Connection reset by peer"
> - notice server has crashed
>
> Not *really* a Cassandra bug, but hilarious nonetheless. :)
>
> =Rob
>

Re: "SQL" Injection C* (via CQL & Thrift)

Posted by Robert Coli <rc...@eventbrite.com>.
On Thu, Jun 20, 2013 at 2:15 AM, aaron morton <aa...@thelastpickle.com> wrote:
>> As for the thrift side (i.e. using Hector or Astyanax), anyone have a crafty way to inject something?
>
> The only thing I've ever heard of coming close was a thrift bug that allowed a malformed request to crash the server. But that was a while ago https://issues.apache.org/jira/browse/CASSANDRA-475

Oh, that brings me back. Literally my first interaction with a
cassandra server :

- start cassandra
- telnet localhost 9160
- "asdasdasdasdsa"
- "Connection reset by peer"
- notice server has crashed

Not *really* a Cassandra bug, but hilarious nonetheless. :)

=Rob

Re: "SQL" Injection C* (via CQL & Thrift)

Posted by aaron morton <aa...@thelastpickle.com>.
> As for the thrift side (i.e. using Hector or Astyanax), anyone have a crafty way to inject something?

The only thing I've ever heard of coming close was a thrift bug that allowed a malformed request to crash the server. But that was a while ago https://issues.apache.org/jira/browse/CASSANDRA-475

Cheers

-----------------
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 19/06/2013, at 1:46 AM, Brian O'Neill <bo...@alumni.brown.edu> wrote:

> 
> Perfect.  Thanks Sylvain.  That is exactly the input I was looking for, and I agree completely.
> (t's easy enough to protect against)
> 
> As for the thrift side (i.e. using Hector or Astyanax), anyone have a crafty way to inject something?
> 
> At first glance, it doesn't appear possible, but I'm not 100% confident making that assertion. 
> 
> -brian
> 
> ---
> Brian O'Neill
> Lead Architect, Software Development
> Health Market Science
> The Science of Better Results
> 2700 Horizon Drive • King of Prussia, PA • 19406
> M: 215.588.6024 • @boneill42  •  
> healthmarketscience.com
> 
> This information transmitted in this email message is for the intended recipient only and may contain confidential and/or privileged material. If you received this email in error and are not the intended recipient, or the person responsible to deliver it to the intended recipient, please contact the sender at the email above and delete this email and any attachments and destroy any copies thereof. Any review, retransmission, dissemination, copying or other use of, or taking any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited.
>  
> 
> 
> From: Sylvain Lebresne <sy...@datastax.com>
> Reply-To: <us...@cassandra.apache.org>
> Date: Tuesday, June 18, 2013 8:51 AM
> To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
> Subject: Re: "SQL" Injection C* (via CQL & Thrift)
> 
> If you're not careful, then "CQL injection" is possible.
> 
> Say you naively build you query with
>   "UPDATE foo SET col='" + user_input + "' WHERE key = 'k'"
> then if user_input is "foo' AND col2='bar", your user will have overwritten a column it shouldn't have been able to. And something equivalent in a BATCH statement could allow to overwrite/delete some random row in some random table.
> 
> Now CQL being much more restricted than SQL (no subqueries, no generic transaction, ...), the extent of what you can do with a CQL injection is way smaller than in SQL. But you do have to be careful.
> 
> As far as the Datastax java driver is concerned, you can fairly easily protect yourself by using either:
> 1) prepared statements: if the user input is a prepared variable, there is nothing the user can do (it's "equivalent" to the thrift situation).
> 2) using the query builder: it will escape quotes in the strings you provided, thuse avoiding injection.
> 
> So I would say that injections are definitively possible if you concatenate strings too naively, but I don't think preventing them is very hard.
> 
> --
> Sylvain
> 
> 
> On Tue, Jun 18, 2013 at 2:02 PM, Brian O'Neill <bo...@alumni.brown.edu> wrote:
>> 
>> Mostly for fun, I wanted to throw this out there...
>> 
>> We are undergoing a security audit for our platform (C* + Elastic Search + Storm).  One component of that audit is susceptibility to SQL injection.  I was wondering if anyone has attempted to construct a SQL injection attack against Cassandra?  Is it even possible?
>> 
>> I know the code paths fairly well, but...
>> Does there exists a path in the code whereby user data gets interpreted, which could be exploited to perform user operations?
>> 
>> From the Thrift side of things, I've always felt safe.  Data is opaque.  Serializers are used to convert it to Bytes, and C* doesn't ever really do anything with the data.
>> 
>> In examining the CQL java-driver, it looks like there might be a bit more exposure to injection.  (or even CQL over Thrift)  I haven't dug into the code yet, but dependent on which flavor of the API you are using, you may be including user data in your statements.  
>> 
>> Does anyone know if the CQL java-driver does anything to protect against injection?  Or is it possible to say that the syntax is strict enough that any embedded operations in data would not parse?
>> 
>> just some food for thought...
>> I'll be digging into this over the next couple weeks.  If people are interested, I can throw a blog post out there with the findings.
>> 
>> -brian
>> 
>> -- 
>> Brian ONeill
>> Lead Architect, Health Market Science (http://healthmarketscience.com)
>> mobile:215.588.6024
>> blog: http://brianoneill.blogspot.com/
>> twitter: @boneill42
> 


Re: "SQL" Injection C* (via CQL & Thrift)

Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Perfect.  Thanks Sylvain.  That is exactly the input I was looking for, and
I agree completely.
(t's easy enough to protect against)

As for the thrift side (i.e. using Hector or Astyanax), anyone have a crafty
way to inject something?

At first glance, it doesn't appear possible, but I'm not 100% confident
making that assertion.

-brian

---
Brian O'Neill
Lead Architect, Software Development
Health Market Science
The Science of Better Results
2700 Horizon Drive € King of Prussia, PA € 19406
M: 215.588.6024 € @boneill42 <http://www.twitter.com/boneill42>   €
healthmarketscience.com


This information transmitted in this email message is for the intended
recipient only and may contain confidential and/or privileged material. If
you received this email in error and are not the intended recipient, or the
person responsible to deliver it to the intended recipient, please contact
the sender at the email above and delete this email and any attachments and
destroy any copies thereof. Any review, retransmission, dissemination,
copying or other use of, or taking any action in reliance upon, this
information by persons or entities other than the intended recipient is
strictly prohibited.
 


From:  Sylvain Lebresne <sy...@datastax.com>
Reply-To:  <us...@cassandra.apache.org>
Date:  Tuesday, June 18, 2013 8:51 AM
To:  "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject:  Re: "SQL" Injection C* (via CQL & Thrift)

If you're not careful, then "CQL injection" is possible.

Say you naively build you query with
  "UPDATE foo SET col='" + user_input + "' WHERE key = 'k'"
then if user_input is "foo' AND col2='bar", your user will have overwritten
a column it shouldn't have been able to. And something equivalent in a BATCH
statement could allow to overwrite/delete some random row in some random
table.

Now CQL being much more restricted than SQL (no subqueries, no generic
transaction, ...), the extent of what you can do with a CQL injection is way
smaller than in SQL. But you do have to be careful.

As far as the Datastax java driver is concerned, you can fairly easily
protect yourself by using either:
1) prepared statements: if the user input is a prepared variable, there is
nothing the user can do (it's "equivalent" to the thrift situation).
2) using the query builder: it will escape quotes in the strings you
provided, thuse avoiding injection.

So I would say that injections are definitively possible if you concatenate
strings too naively, but I don't think preventing them is very hard.

--
Sylvain


On Tue, Jun 18, 2013 at 2:02 PM, Brian O'Neill <bo...@alumni.brown.edu>
wrote:
> 
> Mostly for fun, I wanted to throw this out there...
> 
> We are undergoing a security audit for our platform (C* + Elastic Search +
> Storm).  One component of that audit is susceptibility to SQL injection.  I
> was wondering if anyone has attempted to construct a SQL injection attack
> against Cassandra?  Is it even possible?
> 
> I know the code paths fairly well, but...
> Does there exists a path in the code whereby user data gets interpreted, which
> could be exploited to perform user operations?
> 
> From the Thrift side of things, I've always felt safe.  Data is opaque.
> Serializers are used to convert it to Bytes, and C* doesn't ever really do
> anything with the data.
> 
> In examining the CQL java-driver, it looks like there might be a bit more
> exposure to injection.  (or even CQL over Thrift)  I haven't dug into the code
> yet, but dependent on which flavor of the API you are using, you may be
> including user data in your statements.
> 
> Does anyone know if the CQL java-driver does anything to protect against
> injection?  Or is it possible to say that the syntax is strict enough that any
> embedded operations in data would not parse?
> 
> just some food for thought...
> I'll be digging into this over the next couple weeks.  If people are
> interested, I can throw a blog post out there with the findings.
> 
> -brian
> 
> -- 
> Brian ONeill
> Lead Architect, Health Market Science (http://healthmarketscience.com)
> mobile:215.588.6024
> blog: http://brianoneill.blogspot.com/
> twitter: @boneill42




Re: "SQL" Injection C* (via CQL & Thrift)

Posted by Sylvain Lebresne <sy...@datastax.com>.
If you're not careful, then "CQL injection" is possible.

Say you naively build you query with
  "UPDATE foo SET col='" + user_input + "' WHERE key = 'k'"
then if user_input is "foo' AND col2='bar", your user will have overwritten
a column it shouldn't have been able to. And something equivalent in a
BATCH statement could allow to overwrite/delete some random row in some
random table.

Now CQL being much more restricted than SQL (no subqueries, no generic
transaction, ...), the extent of what you can do with a CQL injection is
way smaller than in SQL. But you do have to be careful.

As far as the Datastax java driver is concerned, you can fairly easily
protect yourself by using either:
1) prepared statements: if the user input is a prepared variable, there is
nothing the user can do (it's "equivalent" to the thrift situation).
2) using the query builder: it will escape quotes in the strings you
provided, thuse avoiding injection.

So I would say that injections are definitively possible if you concatenate
strings too naively, but I don't think preventing them is very hard.

--
Sylvain


On Tue, Jun 18, 2013 at 2:02 PM, Brian O'Neill <bo...@alumni.brown.edu>wrote:

>
> Mostly for fun, I wanted to throw this out there...
>
> We are undergoing a security audit for our platform (C* + Elastic Search +
> Storm).  One component of that audit is susceptibility to SQL injection.  I
> was wondering if anyone has attempted to construct a SQL injection attack
> against Cassandra?  Is it even possible?
>
> I know the code paths fairly well, but...
> Does there exists a path in the code whereby user data gets interpreted,
> which could be exploited to perform user operations?
>
> From the Thrift side of things, I've always felt safe.  Data is opaque.
>  Serializers are used to convert it to Bytes, and C* doesn't ever really do
> anything with the data.
>
> In examining the CQL java-driver, it looks like there might be a bit more
> exposure to injection.  (or even CQL over Thrift)  I haven't dug into the
> code yet, but dependent on which flavor of the API you are using, you may
> be including user data in your statements.
>
> Does anyone know if the CQL java-driver does anything to protect against
> injection?  Or is it possible to say that the syntax is strict enough that
> any embedded operations in data would not parse?
>
> just some food for thought...
> I'll be digging into this over the next couple weeks.  If people are
> interested, I can throw a blog post out there with the findings.
>
> -brian
>
> --
> Brian ONeill
> Lead Architect, Health Market Science (http://healthmarketscience.com)
> mobile:215.588.6024
> blog: http://brianoneill.blogspot.com/
> twitter: @boneill42
>