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 <[email protected]>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" <[email protected]> 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 >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >>
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
