Published on Dec 9, 2022 by Arpad Ray
TL;DR: A misconfigured bucket meant that images generated by Repography were publicly discoverable, even for private repos.
On Friday Dec 2, 2022, I received an email from a sharp-eyed visitor, who found that it was possible to view the file listing of
images.repography.com, a storage bucket where we upload images (dashboards and posters) generated by Repography.
It's intended that the images themselves are publicly accessible, so that they can be directly embedded, but it should only be possible to view an image if the URL is shared by someone who legitimately has access. Obviously the ability to list the contents of the bucket was defeating this aim.
First of all I'd like to offer my sincere apologies to anyone affected by this. It's certainly my fault - I'm the sole developer of Repography, and it's an embarassing mistake. I'm posting this because I think it's important that affected users are made aware of the issue, and also I want to show my sincerity in building a service that you can trust.
If you used the Repography app before this was fixed on Dec 2, 2022, then the images we generated for your repository were publicly discoverable and accessible.
These images are based on the metadata and history of your repository, so may include information like:
I haven't deleted existing files because I don't want to break images which users have already embedded elsewhere, but if you want to move your Repography images to a new unguessable URL you can remove your repo and add it again within the Repography app.
Please note that images might be accessible for a while after being deleted due to caching.
images.repography.com is a Google Cloud Storage bucket. Upon receiving the email I immediately checked the bucket and found that I'd given "allUsers" the permission "Storage Object Viewer".
Google Cloud Storage has roles which distinguish between bucket access and object access, so it's surprising to me at least that "Storage Object Viewer" includes: "Can also list the objects in a bucket."
To restrict "allUsers" to only read objects given the correct path, we actually want the "Storage Legacy Object Reader" role which grants only the "storage.objects.get" permission.
I made this change as quickly as possible (three minutes after receiving the email) and then purged the cache on our CDN.
If you used Repography with a private repo before the fix on Dec 2, 2022 you should see a notification within the Repography app with a link pointing you towards this blog post for more information. I've identified 87 such users including myself.
If you used the CLI script to analyse a local repository without using the GitHub app then you would also have been briefly affected by this, but these images are automatically deleted after 24 hours. I don't store any information for these repos so don't have a means of contacting these users.
If you are concerned by this issue, whether you received the notification or not, and would like more information or assistance, please get in touch at [email protected].
The security and trust of our users are extremely important to me. In the past week I've reviewed the whole codebase from a security perspective and will continue to do so, hardening our services wherever possible.
This has also been an eye-opener. I'm an experienced developer and I'm surprised (and naturally, disappointed) that I made the error which lead to this issue. To minimise the chance of errors like this and to improve the security of Repography overall I'm making two commitments to be done before I remove the "beta" label (hopefully Q1 2023):
If you'd like to support Repography and help me make time to improve it, please consider purchasing one of our paid plans on the GitHub marketplace.
Many thanks to Wouter Bolsterlee who found this issue and alerted me to it.
One click, no signup required