hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: are column qualifiers safe as user inputed values?
Date Wed, 01 Oct 2014 16:56:49 GMT
Hi Ted,

there is nothing like sql-injection-like hacks into HBase. It's all byte
arrays and nosql. So from that perspective, yes, you are safe to use user
inputed values as the column qualifiers.

2014-10-01 12:15 GMT-04:00 Ted <r6squeegee@gmail.com>:

> ok so it sounds like it's safe :)
>
> I'm not parsing it at all, that's my point, I'm taking what ever the
> user types and doing a Bytes.toBytes(s); on it and using it as the
> column qualifier. I was more or less wondering if there were control
> characters that could lead to anomalies or sql-injection-like hacks.
> It sounds like the answer is "no".
>
> Thanks.
>
> On 9/30/14, Nick Dimiduk <ndimiduk@gmail.com> wrote:
> > This depends more on your parsing code than on HBase. All values are
> > converted into byte[]'s for HBase. Once your code has parsed the user
> input
> > and generated the byte[], there's no place for ambiguity on the HBase
> side.
> >
> > On Tue, Sep 30, 2014 at 5:19 PM, Ted <r6squeegee@gmail.com> wrote:
> >
> >> Hi I'm wondering if it's safe to use user inputed values as column
> >> qualifiers.
> >>
> >> I realised there maybe a sensible size limit, but that's easily checked.
> >>
> >> The scenario is if you wanted to store simple key/value pairs into
> >> column/values like perhaps some ones preferences like :
> >>
> >> FavouriteColour=Red
> >> FavouritePet=Cat
> >>
> >> where the user may get to choose both the key and value.
> >>
> >> Basically the concern is special characters and or special parsing of
> >> the column names, as an example the column names are allegedly =
> >> <family_name> : <column_qualifier>
> >>
> >> so what happens if people put more colons in the qualifier and or
> >> escape characters like backspace or other control characters etc? Is
> >> there any danger or is it all just uninterpreted bytes values after
> >> the first colon?
> >>
> >> thanks
> >> --
> >> Ted.
> >>
> >
>
>
> --
> Ted.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message