Security risk of clients having access to vector clocks

Brian Picciano mediocregopher at gmail.com
Thu Jan 17 21:16:40 EST 2013


If the only thing the client could potentially mess up is the specific key
that vector clock is for then that's fine, I just wanted to check that
there wasn't some equivalent of a sql injection which could be done to
manipulate/delete other keys.


On Thu, Jan 17, 2013 at 9:12 PM, Michael Clemmons
<glassresistor at gmail.com>wrote:

> Manipulating the vclock client side in theory could be used to affect what
> data is stored.  I wouldnt say this is a large problem but I would think
> about whats being stored and if being able to say force a revert is
> profitable.
> On Jan 17, 2013 6:07 PM, "Brian Picciano" <dustfinger1 at gmail.com> wrote:
>
>> A web app that we're building is designed in such a way that the vector
>> clocks returned from a bucket with use_multi:true will be sent to the
>> client, and the client will then return that vector clock in subsequent
>> requests so that we can keep track of state conflicts in riak.
>>
>> My question is: are there any security risks in doing this? We've
>> obfuscated the vector clock (and never call it the vector clock on the
>> client side), but that's just security through obscurity, and probably
>> wouldn't hold up very long. Would a client be able to get any meaninful
>> information out of a vector clock, or manipulate it in such a way that when
>> they return it it could harm the database? Are there any ways we could
>> combat this?
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130117/aaa7b241/attachment.html>


More information about the riak-users mailing list