This is the one big thing that really needed to happen to Firebase to get it ready for the world and having worked with these guys a bit, I know it was a difficult problem to solve. I think the solution they came up with is actually pretty novel and exhibits the qualities I strive for these days:
1) It's as declarative of an approach as it can be without sacrificing flexibility.
2) It follows the structure of your data and is itself a datastructure that can be trivially manipulated.
3) It centralizes a concern. Security measures often end up spread all over the place, making it very difficult to reason about what is or is not correctly handled. Not so with this model.
I'm excited to see what people do with Firebase now that the one thing that was really holding it back has a solution. I know from my standpoint, it's certainly nice to have someone else dealing with the nightmares of real-time scaling and security so that I don't have to.
We've been using Firebase now for about 6 months to power Roll20[1], it's allowed us to grow from 100 to 1,000 concurrents without having to make any changes to our code or even think about handling the additional scale. That's incredibly valuable to us, since it frees us up to focus on creating features and helping customers, not worry about keeping yet another server from crashing. Andrew, Michael, and James have always been available to answer questions, and it's been a pleasure to watch Firebase grow. The new security API is just the icing on the cake for us since it will allow us to further fine-tune what different participants have the ability to do in our games.
I highly recommend it if you're looking at creating a real-time app!
This is really great work, guys. We've been using Firebase for a while now. The uptime, low-latency, and consistency have been impressive. A good security framework was really our last hurdle. We're digging in to the new security features and pretty happy so far. Another good resource (in addition to the blogpost above) is the quick start page. [1]
Also, one side note: it's not always clear from reading the docs, but changes to the security rules can be made dynamically and take immediate effect.
Hand-wavy terms are preferred if the text is end-user facing (and when end-users tend to not be too technical). Of course, a tooltip or "more details" link explaining the real technologies should then be used.
[Firebase founder here] This is one of the nice things about running a company that is 100% developer focused. We can communicate in clear terms with customers that actually understand the nuances of what we're building. We'd much rather be specific than hand-waving.
For what it's worth, and as weird as this is going to sound:
You don't in particular want the "security API" of an app framework to get externally validated. For the most part, the "security" components of app frameworks are boring, modulo some really simple- to- answer questions ("how do you store passwords", "how do you handle password resets").
When people talk about "security frameworks", they tend to be thinking about what we used to call "AAA systems" (authentication/"authn", authorization/"authz", and accountability/logging). You don't need to be an appsec practitioner to look at an AAA system and see whether it's any good. Does it apply authn by default? How easy would it be to accidentally expose a method that didn't require a login? Does it apply authz rules by default? How much of a pain would it be to reliably apply authz rules across my project? If stuff is easy and has sane defaults, you'll use them and benefit --- like you do in Rails, if you use association finders off a "current user" instead of the class object finders.
The bad news is, what you want tested in an app framework is everything else. How's it handling database persistence? How does it handle corner cases, like deliberately pathologically huge queries, out-of-range numerics, conversions between multipart and standard encoding, output encoding of HTML, Javascript, and CSS, CSRF validation, file upload, database column access, &c &c. It's the stuff you don't normally think of as "security code" that's most likely to bite you.
At Matasano, we have a "seven deadly features" in web apps that we tend to find the first and worst flaws in web apps in; they're:
1. Password reset
2. Email functionality
3. Interfaces to thick clients; "REST API" &c
4. File upload
5. File download
6. Templating
7. "Advanced search"
Only one of those is a security feature, and it's also a security feature that most "security APIs" don't actually implement (because every app wants to have a different UX for it).
Lest this sound self-interested: most frameworks haven't been formally externally tested. I'd be thrilled if someone had their framework tested formally, but I don't tell people not to use Rails or Django or Spring just because they haven't been pentested by an appsec firm.
How should one properly secure a "password reset" feature?
Ooh, I think I can actually do this: You send the address on file an email which contains a random, time-limited, one-use token which allows them to log into their account. You should not disclose presence or absence of the account via the reset mechanism on the site (only via email), but that's a comparatively minor issues. A successful password reset should end all in-progress sessions for the account. You should also do all the table-stakes web development things like e.g. not allowing SQL injection or XSS on the page.
There's plenty of failure conditions for password resets:
1) You create non-random reset tokens, such as MD5(user.id) or MD5(user.email), potentially compromising security of accounts.
2) You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)
3) You allow password reset tokens to get re-used, which increases the attack surface against individual accounts by e.g. making saved-to-disk emails into attack vectors for them. (Standard reset mechanisms only make emails-in-flight into attack vectors.)
> You allow resets of your teams' admin accounts to happen through the publicly accessible password request feature. (n.b. Almost never a good idea, for one because it means you're probably doing shared authn/authe between your app and your admin console and that is generally a very bad idea. I say this in spite of shipping it in every product I write.)
Can you please elaborate more, or link to articles about why this is a bad idea? What are the common failure scenarios that splitting normal & admin users fixes?
Briefly: there are a lot of common vulnerability classes which can compromise a user of your application / their cookie / their DB record, for example mass assignment (to update the "role" attribute in a free trial account to "admin") or XSS (tweet at your support account and have them click a link to your domain, bam, the adversary now has your cookie and can log in as you).
Separating the admin app and the normal app upper-bounds the impact of those flaws at something lower than "The worst thing someone could possibly do with the admin console." Given that many admin consoles have fairly extensive functionality, that's generally a good idea. (I mean, my businesses are pretty low risk as things go, and my admin consoles would trivially do about $20k of damage just with refunds if compromised.)
I just tested one recently that used client-side Javascript to generate the new temporary password for whatever account was submitted in the POST parameter.
Needless to say, you could arbitrarily set any account's password to whatever you wanted.
Account harvesting through the password reset functionality is one that pops up all the time. A lot of businesses now just accept the risk (which I no longer really get all that worked up over, at least provided they aren't also enforcing account lockout for invalid attempts)
During the design process, we solicited feedback from several security experts (security firms and ad-hoc hackers alike). It hasn't gone through a formal outside audit at this point though. (And please do keep in mind that we're still a beta product. We're pretty confident in what we've built, but we're not making promises at this point.)
I'm curious about this as well. When I hear "without writing any server code" in the demo video, my mind says that this is client-side validation, which does not suggest it is secure to me. What server-side validation happens under the hood to deal with modified clients/proxies like Burp?
Here's a little secret. The security rules you, as a Firebase developer, write for your Firebase, are actually server-side validation code. It just doesn't look like typical code, and we've carefully designed them to have a lot of good properties regarding performance, correctness, and analyzability. And we (Firebase) take care of enforcing them for you.
But it /is/ server-side validation, that you as a developer get to specify.
(That said, we're definitely happy to get feedback on our approach from any security experts out there that want to take a look!)
I have a beta acccount and was waiting for this until I started playing around with it. Thanks! I'm pretty excited about building something on top of this platform.
The Scratchpad.io tool that has been on HN for the last couple of days has really blown me away with what Firebase is capable of. Keep up the good work guys!
I especially like Firebase tutorials and docs. After finishing tutorial on Firebase first launch I immediately knew where and how can I use Firebase in the future. When the time came we used it for real-time worker/web-app communication at http://dubjoy.com/ and it worked like a charm. I still don't know how to use web sockets and I hope I never will :) While working with Firebase we needed some ACL-like security features and Firebase delivered again. Amazing.
Thanks! We're certainly grateful for all of the input and feedback we received while designing this thing (especially from our beta users who came through time and time again, giving us countless security use cases and providing feedback on our prototype implementations).
I will point out though that what you described looks like an ACL system with groups (akin to unix permissions), and we think our Security Rules system is actually quite a bit more powerful than that (you could easily build ACL / groups on top of it, but you can build lots of other models too). :-)
Firebase doesn't use cookies for authentication so CSRF isn't an issue. You have to explicitly call auth() on our JavaScript SDK with valid credentials, or include valid credentials in the querystring of a REST request.
I like having the flexibility of being able to use Firebase's servers or my own, makes it easy to use for completely client-side apps, or alternatively you can throw it on top of a server-side application. Great work guys!
[Firebase founder here] We did a ton of interviews with devs, and we found that authentication was one of the areas where developers wanted the most control / customization. We therefore opted for maximum flexibility here.
Very interesting. How are rules updated dynamically? Take a Flickr picture for example. I start it as public, then later decide I want to make it friends & family. How does the client side securely update those rules?
This is where Security Rules shine over ACL's or other more rigid security models. As the application developer, you have complete control over that sort of functionality since the rules are quite flexible and have direct access to your Firebase data.
So you could store a 'public' flag on every picture in your Firebase data, and then write a single rule that checks the value of that flag, and if it's true, allows anonymous access (and if it's not true, checks that the accessing user is in the picture owner's friends/family list).
Assuming your rules let the picture owner edit the 'public' flag, they'll be able to flip it on and off, granting or revoking access to non-friends/family. And since everything in Firebase is real-time, the change will instantly take effect.
This is a great update and really opens it up for a hackathon project that I wanted to extend after the event, but the security issues had meant that it was better to wait until now.
Well done James T. and the rest of the Firebase team.
[meteor dev] Meteor treats the server as an environment for running arbitrary privileged code. You can write server-side logic that consults third-party services, logs client writes to a separate audit trail, keeps authentication state between requests, or implements complex transactions across multiple tables. Similarly you can write code to run periodic database updates on an interval, or respond to incoming HTTP requests from other clients.
Not all apps need this stuff right away, of course, and some never do. But it's hard to do these things w/o a secure server environment for privileged code.
And then of course there's the usual tradeoffs between having control over your hosting environment (a la Meteor) and outsourced backends as a service (a la Firebase).
We're big fans of Firebase, BTW. We think more databases will move to a realtime model. Excited to check this out.
[Firebase dev] I've mentioned this in the chat several times, but I should probably mention this on the HN thread as well.
We're big fans of Meteor as well. Firebase is just a data layer -- we do high-performance, scalable real-time data sync -- but we aren't a complete Framework for building an app. Generally devs will want to use something like Meteor (or Ember, or Backbone, or Spine, etc) to help them organize their code and manipulate the DOM.
In the future we hope to have a Meteor integration, so you can power your Meteor app without running any of your own servers (and do it on a super-low-latency, highly scalable backend).
I should also mention that Firebase does let you run trusted code if you want to -- you can run a server as a Firebase client using our Node.js library or using our REST API. Then you can do anything you would normally do with a server, and still get Firebase's real-time updates.
The model is reversed in this case though, where instead of clients talking to your application server, clients talk to your database (Firebase), and your application server only ever talk to your database (Firebase). It's a bit of a conceptual shift, but we have many customers doing this in production and it works quite well.
that would be really great. I'm working on my first meteor app, building a real time project management collaboration app (old app at taskup.com written in PHP), and I would love to use firebase for real time data integration.
plug: beta at taskup.meteor.com
Meteor relies on developers writing server-side code. This is flexible, but it means you need to run your own servers -- meaning scaling, operations, etc are up to you. Scaling real-time / persistent connections is especially challenging.
Our rules are expression-based, so they have fast and predictable execution times, meaning we can run these on our own servers and scale your app for you with guaranteed performance.
Our rules also let you specify all of your security logic in one place, rather than sprinkling it around your code, meaning it's easier to review and reason about (and avoid holes).
The Candle Plan is and will continue to be free! (All of the pricing on the website is just to give people an idea of what the pricing will be when we leave beta. It's not being enforced right now.)
Michael from Firebase here. By using declarative rules instead of arbitrary code to enforce Security, we can do lots of optimization and guarantee predictable execution time (arbitrary code can take an arbitrarily long time to execute). It also lets us do various static analysis on your rules to catch common mistakes.
Having rule expressions attached directly to data locations also ends up being much more concise (which means less boilerplate code and less opportunities for mistakes), which we think is important for a security API.
Since the whole rules language is custom, we're not using any off-the-shelf projects presently, and to be honest, we've only scratched the surface of what's possible.
Most of what we have in place right now is at the level of type-checking and other expression-correctness checks (we're intentionally more strict about a number of things than JavaScript).
But given the nature of the rules we can do a lot of cooler analysis, like detect redundant or conflicting rules. We should also be able to do interesting analysis for the developer like answer questions like "What parts of my Firebase data can an unauthenticated client read or write?", "What parts can a user authenticated as 'joe' read or write?"
This sort of analysis should help developers reason about their rules and verify their correctness. Honestly, I'm pretty excited about the possibilities. :-)
Yeah. That bugs us too. :-) We might support a non-JSON format for easier authoring at some point, but we thought JSON was the right starting point since people are familiar with it and it has a lot of good tooling and interoperability advantages.
The key difference is that we are a real-time backend. We push data changes down to clients when things change and trigger callbacks so the apps can remain responsive. Parse, Kinvey, etc are based on a request / response model. I know some of them can do mobile push notifications, but those aren't really analogous and are a separate service from their data service.
We're real-time, all the time.
We're also focused on the data layer of your app, and on the web, rather than being a mobile-focused company.
1) It's as declarative of an approach as it can be without sacrificing flexibility.
2) It follows the structure of your data and is itself a datastructure that can be trivially manipulated.
3) It centralizes a concern. Security measures often end up spread all over the place, making it very difficult to reason about what is or is not correctly handled. Not so with this model.
I'm excited to see what people do with Firebase now that the one thing that was really holding it back has a solution. I know from my standpoint, it's certainly nice to have someone else dealing with the nightmares of real-time scaling and security so that I don't have to.