August 17, 2016
You are wonderful. We’ve been experiencing this day by day for almost ten years now. Whether you’re getting in touch with a question, or a suggestion on how to improve mite: we experience savvy and knowledge, sympathy and kindness. And, most notably, helpfulness. For this, we thank all of you.
Today, we’d like to thank one person especially: Marcel Eichner. He informed us about a security vulnerability last Thursday. Thanks to his detailed description, we could immediately reproduce it. We deployed a security fix three hours later. Thanks for your support, Marcel!
One, we do not have indication for an exploit of the vulnerability. Two, personal data could not have been read or modified. Nevertheless, as a matter of principle we want to inform you in detail.
The problem had slipped in to our open data interface, the mite.api. Every project in mite has a unique identification number (ID), and is optionally assigned to a customer. Over the API, time entries can be created for a given project. The project is referenced by its ID. mite checks if a project with this ID exists, and whether it belongs to your own account. If the check fails, the project ID in the server response is set back to “null”.
To improve performance, the server response not only contains the project ID, but also, if existent, the ID, name, and hourly rate of the project’s customer. The vulnerability was hiding in the check outlined above, within its chronological order. If the project ID belonged to an account other than you own, the project ID was correctly nulled as described, but the server response contained, if existent, the described data of its customer.
The server response did not disclose to which mite.account the customer belonged. Thus, one could have found out that any company that uses mite works for a customer such as “Acme Inc.”, but not, which company. And fortunately, it is not highly sensible information that any undefined team on the world works for a customer such as “Acme Inc.”.
The vulnerability thus wasn’t a highly critical one, and it is now closed. But it was able to slip in, even though we take security very seriously. That’s why we are so thankful to Marcel. And that’s why we’d like to ask all of you to please get in touch with us immediately if you should become aware of any other weak spots in the future.
E-mail works best in such cases. Please find our PGP key as well as all other communication channels right here. Please describe as detailed as possible what you did, how mite reacted, and how mite should have reacted. Code snippets help a lot, also screenshots, information on the technology you use, or anything else that might be important to help us reproduce the problem – and fix it as fast as possible. Please support us in keeping mite healthy and bug-free. For all of you.