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.
Sign up for CIO Asia eNewsletters.