Every developer worth his or her salt knows better than to hard code API tokens, encryption keys, and user credentials. But a quick search on public GitHub repositories shows this happens all too often.
Latest case in point: Researchers from website security firm Detectify found more than 1,500 Slack tokens on GitHub. The developers had shared their code thinking others may be able to reuse a bot for their Slack teams.
However, several of the publicly shared bot projects contained the organization's API keys and Slack tokens. In the wrong hands, these tokens could expose sensitive data shared within Slack teams, such as chats, files, private messages, database credentials, and login information to internal resources. If the developer didn't remove the organization's unique API key or token from the bot code before pushing it to GitHub, then someone else could take that token and use it to access the original developer's Slack account.
"Now, because the code contains these tokens, the developer is actually giving anyone who finds the token access to the developer's company's internal chats and files on Slack," Detectify's team wrote in its analysis.
Hard-coding credentials when writing code is a common -- and unfortunate -- scenario. Login credentials for databases and Amazon Web Services keys get pushed to public repositories, for example. There's also Google Dorking, which refers to using advanced search operators on Google to find information, such as SSH keys and other sensitive strings.
Sometimes these problems pop up when developers are being fast while working on new functionality. Oftentimes it's throwaway code being used for testing purposes. And other times, it's a small project no one expects anyone to notice.
But inserting credentials in code isn't the issue here; not removing them afterward is. Move secrets out of code into configuration files and use environment variables.
GitHub's Help page provides detailed instructions on how to remove sensitive data from the repository. Files with sensitive information should be added to the .gitignore list in the local repository. When the user is pushing code for the final commit to the public repository, none of the files in that list gets copied. The Help page also suggests using programs like GitHub Desktop or gitk to see exactly which files are being added, deleted, and modified.
"Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised," the Help page warns. "If you committed a password, change it! If you committed a key, generate a new one." If a password is entered, it should be changed. Even if the file itself has been removed from the repository, references will remain in the repository's history.
Slack told Detectify that it's proactively looking for exposed tokens and disabling them so that they can't be abused. While tracking where tokens and API keys are being posted is helpful, it isn't Slack's job. GitHub is just one public repository out of many. It shouldn't be up to Slack to keep track of all the possible places where tokens may be leaked.
It's the engineer's job to treat tokens like the sensitive pieces of information they are. And it's the organization's responsibility to make sure engineers are following the necessary steps to make sure tokens and credentials are protected at all times.
Organizations need to know what public repositories the developers are using, says Richard Sutton, vice president of engineering at Nexgate, a division of security company Proofpoint. Slack allows team owners to restrict who can create integrations and tokens. In the case of Amazon Web Services and other platforms, developers should not be able to use administrator accounts. The generated keys should be restricted to specific roles and privileges the application needs.
Developers frequently are given free rein to create tokens and to commit code to public repositories. Organizations need to have a process for checking what is being committed into these repositories, as well as to track what kind of credentials developers are using in their applications. And developers need to remind their teammates that they shouldn't be pushing secrets to public repositories.