firepad

osystem of interesting libraries [3]. I'm really excited by all the powerful libraries that Mozilla has been pumping out these days. The web is a great place to be. [1] https://github.com/firebase/firepad [2] http://plnkr.co/edit/?p=streamer&s=TogetherJS (Demo) [3] https://github.com/substack/stream-handbook#introduction

dom objects[2]. So far, so good. [1]: https://news.ycombinator.com/item?id=4780495 [2]: https://news.ycombinator.com/item?id=3824775 A set of example security rules for Firepad is actually provided as part of the GitHub project, so we can do some analysis of the kinds of checks we will need to bypass in order to break this particular demo ;P. (Of course, this just makes us faster, it isn't what makes this possible.) https://github.com/firebase/firepad/blob/master/examples/sec... https://github.com/firebase/firepad/blob/master/examples/sec... Reading these, it turns out that the only verification that is being done on the snapshots is that 1) they look reasonably valid (have the correct set of fields) and 2) they have the correct author field associated with them (as in, the same one that is used on the history revision item). However, it doesn't do any consistency checks on the data itself. It doesn't even verify that the snapshot we are uploading is different than the one currently on the server, so the problem of corrupting the state is really easy: we just need to pull the current snapshot and modify its data. The only pain we could run into is that it could also verify that the author of the snapshot is the current user; but that doesn't help: all we need to do is to make a quick edit to the document and then use our new revision (which we legitimately own) to build our new corrupted snapshot. That said, while that check is present in the example rules on GitHub, that check isn't actually used in the deployed copy of Firepad on this server as this server is entirely anonymous and thereby none of the users have any auth information at all... we can just pretend to be other users. For users who wish to follow along at home, you just need to have node.js installed, and then do "npm install firebase". You can then use the following script to destroy any document you want: you just need to set the "room" variable to the ID # of the document you want to modify. #!/usr/bin/nodejs var Firebase = require('firebase'); // parseInt(window.location.hash.substring(1)) var room = 44; var shard = room % 15; var db = new Firebase('https://firebase-firepad' + shard + '.firebaseio.com/' + room); var check = db.child('checkpoint'); check.once('value', function (value) { value = value.val(); check.set({ a: value.a, id: value.id, o: [''], // random data would be better // but I'm both lazy and busy today ;P }); }); When the client then restores this snapshot and attempts to play back the resulting history to "catch up" it will instead end up outputting tons of errors to the console, as the operations stored in the history will be referring to document positions that no longer exist or are different. Firepad: Invalid operation. https://firebase-firepad14.firebaseio.com/44 C2GK The client then has two options: it can either skip the history entry or it can decide the entire document is corrupt. In this case, it seems that Firebase believed the better of the two options was to simply skip these operations: new clients then manage to resync their state. But, existing clients now have desynchronized state, so all operations that are being synchronized live between the various clients on either side of this split (ones that started from this snapshot, and ones that pre-existed it) are going to result in this error; that didn't really help. To be very explicit for a second: this is a different scenario than just "well, its an anonymous system, so anyone can delete the data": we didn't just go in and delete the data in the document, we actually corrupted the state of the document, rendering further attempts to edit it useless. It is currently my belief that Firebase's security rules system is simply not powerful enough to secure an OT-based text editor, whether or not it uses snapshots (at least assuming it supports offline; there might be tricks you can play if all users are required to be online at all times). (edit: I am finding it interesting that my previous security analyses of Firebase projects, combined with example code, had been voted up quite high, and this one has now been downvoted to 0. I wonder if people just don't care as much about security anymore? Is it because it is open source? Is the Firebase team themselves going around voting down? ;P)