Is Your Private GitHub Organization Really Private?

09 Jun

Your private GitHub organization might not be so private. Without a third-party access policy applications are able to act on behalf of your users. This includes any scopes that the user grants permissions to the application- potentially including access to private repositories.

GitHub makes a lot of things very convenient. GitHub flavored markdown, issues, and pull requests combined are very powerful tools for any private or public project. Jira is way too heavyweight for my liking, so I started searching for a solution that integrated with GitHub. I found a very useful application that supplements the GitHub issue tracker very nicely. Upon clicking “Sign Up” I found myself at the page below.

app-authorization

Signing up for websites or granting permission to applications is a very common thing. Most people have a habit of just clicking through the big green buttons. In this case, let’s look a little closer. All I see is green, nothing indicating a risky action. Hmmm, let’s look a little closer.

app-authorization-detailsWait, this application wants permissions to “read and write all public and private repository data”. That includes code, issues, pull requests, wikis, settings, webhooks and services, and deploy keys. Why does a project management tool that supposedly works with just the issues API need all of this? The answer is that they simply have no choice, it’s not their fault. GitHub doesn’t have resource-specific scopes, so the application can’t just ask for access to the “issues” scope. Scopes are higher level constructs that control access to groups of resources. In this case, the only way to give an application the ability to manage your issues is to give them access to everything.

GitHub, can you either provide more scopes or spread the word about this?

But you might ask “isn’t this okay, since it’s my account?” The answer is “it depends”. Note at the bottom of the screenshot above the green check mark beside SomeOrganization at the bottom. This means that the application will have the access described for the entire organization! Now this should be getting a little more scary.

Organizations are in control of third party application access. They will either have no restrictions or a whitelist of allowed applications. Whitelisted applications will be able to act on behalf of the organization member. This means that the application I attempted to sign up for would be able to access all of the proprietary code in my companies organization!

Without access restrictions, private is no longer private.

Let’s walk through how to check if your organization is configured correctly. Being properly configured decreases the likelihood that a bad actor will get access to your private data.

1. Click the gear at the top right of the GitHub UI

user-home-arrow2. Click the organization you want to manage at the bottom of the left side bar

user-management-arrow3. Click Third-party access in the left side bar

organization-management-arrow4. Check if you have access policy restrictions

If you see “No restrictions” like in the screenshot below, then your GitHub organization allows any application an organization member authenticates with to act on behalf of the user.

no-restrictions-arrowIf you see “Access restricted” like in the screenshot below, then your organization is protected from bad applications. You can stop here.

restrictions-arrow5. Click the “Setup application access restrictions” button

setup-restrictions-arrow6. Click “Restrict third-party application access” after reading page contents

enable-restrictions-arrow

That’s it! Now your GitHub organization is protected from bad applications. You can navigate to your existing applications and allow any that should be a part of your organization.

Tyler Cross
Tyler Cross
tcross@bandwidth.com

Tyler Cross is a passionate software engineer from eastern North Carolina with a breadth of knowledge to draw on from the web, bioinformatics, and telecommunications. So far during his 2 years at Bandwidth he has worked on teams that gave him exposure to all technical aspects of our products- backend provisioning systems, real-time communications software, networking, and prototype development in the Bandwidth Incubator. In addition to being a techie, he is an avid runner and athlete in general. He is proud to be a Bandwidth employee and live up to all our principles and ideals.

No Comments

Post A Comment