How I hacked a Firebase leaderboard in 5 minutes

[Lucas Salvatore]

Hello, I am reporting a hack on the leaderboard for the HTML5-Asteroids game, not because this particular game is important, but because its a forked repository on Firebase's github, and serves as a really bad security practice, simply because of how fast I was able to manipulate the leaderboard. I will also make the case that even if this developer had wrote security rules to validate the score, there would still be no way for him to stop me from writing my own score into the leaderboard. This leaderboard is also vulnerable here: https://github.com/firebase/examples/blob/master/leaderboard/rules.json. The hack is simply breaking and modifying a reference in the developer console. I put the full instructions below. 

This leads me to conclude that client-side user data in Firebase is impossible to protect from malicious writes. I've read the security docs several times, and its focused mostly on ensuring the data is the correct schema. Don't get me wrong, ensuring that and the user is authenticated is critical and protects from maliciously setting other users data. But there's nothing to stop clients from writing whatever data they want into their own legal writable data, hundreds of times in a row. Firebase might protect from malicious spamming, but simply setting a fake score in a game doesn't seem like something that can be fixed without server-side code. 

In the Tetris example, malicious clients can just reset the board whenever they want. The game is a great learning exercise, but the entire architecture of maintaining client state is just very insecure to the point that it's questionable why there are even security rules at all, if anyone can just easily ruin any game. 

Which is why Firebase should advocate the server-side admin for writing and maintaining game state as a more secure option. Its the only way to truly validate gameplay. By only allowing the admin write access to the game state and leaderboard, it becomes impossible for the client to manipulate these values. 

Firebase should remove "and perhaps most importantly, there is no need for an intermediate referee, such as a server, to protect data from the world" from its security docs because the opposite of that is true from what I discovered. A server-side admin is more secure, and also hides your proprietary logic, which is another topic. I don't think anyone would seriously release a production game with 100% client-side code, as anyone can just steal it. 

Please let me know if I am missing something. I'm going to re-architect my game around state on the server, and I wish I had considered this approach in the first place. If Firebase agrees I think the security docs should be updated to reflect a more realistic app architecture. 

The hack : 

Go here:

https://mmoasteroids.firebaseapp.com/

Put a breakpoint after scoreListRef is declared, line 199 in game.js 

Enter in console: scoreListRef.push({user:currentUser, score: '123456'})

[Kato Richardson]

Hi Lucas,

Thanks for sending this in! We do love us some feedback.

There are a lot of tradeoffs in creating example apps, primarily between simplicity and completeness (i.e. complexity). It requires a decent balance to make them understandable to a target user group without exposing bad practices. If you need to create a purely client-side leaderboard and can't work out how to lock down security on this for a production app, let me know. I'll be happy to work with you. I'll also put a task in our internal queue to see if we can get some more solid rules in the example app without muddying the usefulness as a learning tool.

Game security is always a very complex topic and creating bugs is easy. No disagreement here, as someone who wrote an example implementing purely client side in-game trading. But the fact that game logic is hard does not mean that client-side user data in Firebase is impossible to protect from malicious writes. The problem here is logical complexity and properly testing the rules, and not the capabilities of the security rules to secure data.

A server can simplify some use cases, and we certainly advocate using a server for complex, atomic, interactions that users could exploit to gain advantages in games. But when dealing with complex logic, you can make the same mistakes in server code that you do in a client, so this isn't any more foolproof.

Thanks again for the feedback. It's certainly giving us something to chew on for the day. I love this community!

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/21ffaf3d-82c4-454c-89cb-c9d15c034ef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Lucas]

Hey Kato, 

Thanks for the reply! I've had a blast using Firebase while building my app, a multiplayer card game. The game logic for what I thought was a simple multiplayer game took much longer than I expected, and there's no question that my skillset from 5 years ago could not have built this even with Firebase. So my product is nearly complete, and I'd say most of my bugs and logic problems are behind me. 

I was looking at this Stack Overflow thread, and it looks like you've wrote an awesome exhaustive reply to this issue already! Regarding the "Use an audit path" approach you mentioned, it seemed like a pain to be writing this in a json file, when I could just use serverside logic and implement my validation there instead. Plus, I wasn't totally convinced on the audit trail- can't the malicious client just push a fake audit onto the trail? 

Anyway, this would purely be for curiosity, I've already decided I'm going to be moving my code to the server, with the privileged worker approach. I was able to push a Node.js app in Google's App Engine really quickly today, so I'm feeling better about using Firebase there in addition to client.  

The thread: http://stackoverflow.com/questions/26250019/firebase-how-to-secure-numeric-data-from-manipulation-by-users-eg-game-score

Easy Node.js deploy https://cloud.google.com/nodejs/getting-started/hello-world

Thanks for your work on this,

-Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/21ffaf3d-82c4-454c-89cb-c9d15c034ef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kato Richardson]

Great find! I'd forgotten about that post. Lots of good material there. 

Sounds like you have a solid approach; nothing wrong with taking the logic to the server, and often a best practice for game logic.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/613b2c90-ba66-4dff-a8a2-fa2af34993c2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.