Every Sign Has a Story

A few of us Bishop Fox consultants recently read through Google’s G Suite Developer’s guide, just to see what they advised. We came across a lot of tips that left us concerned and pondering the meaning of life.

Every warning has a reason behind it, even if it doesn’t seem obvious or necessary at first.

As security professionals, some stuff seems like second nature to us, but we realize it might not for everyone else. In this post we’re going to review some of those warnings that can easily go unnoticed by developers more focused on functionality than security, but which can help make an app more secure if taken seriously.

Things to look out for:

• Committing sensitive files to repositories
• An app has multiple methods to use OAuth credentials, all depending on specific needs. One of those methods is using JSON and P12 files to store service account private keys. If you use repositories, never include these files in a commit that could be accessed by others. Exposing private and access keys in repositories can grant an attacker access to sensitive information/infrastructure and jeopardize your application.
  

• Not implementing HTTPS EVE-RY-WHERE
  
  

In 2019, there’s really no excuse left for not encrypting your communications. Attackers will use your lack of transport encryption to view the data passed over the network, resulting in data loss and possible compromise of user accounts. Data could not only be stolen but also modified, losing its integrity.

• Unnecessarily reinventing the wheel
  

Writing new code instead of reusing proven and tested functions can introduce security issues. Authorization and encryption flows are tricky to develop and have often proven to be the Achilles heel of many applications. Unless you have a real need to implement your own authentication/encryption flow, use an existing library instead.

• Relying on user controls for security

View-based access controls are nothing but a small inconvenience for a malicious user. A greyed input box or a hidden combo box can easily be manipulated via a simple browser trick. The server must do the heavy lifting here and make sure that the request is valid.

• Blindly using someone else’s code

While snippets and code examples are great place to start when developing a function, it doesn’t mean they were crafted with security in mind. Always consider security when using examples from other developers – not that they are malicious, just that security is generally not a concern when creating simple code examples.

• Losing the keys to the realm

You are responsible for your private keys and your provider can’t do a thing if you lose them. Backup your private keys in a secure way – just don’t commit them to the repository.

• Running apps with excessive privileges

The least-privilege principle should be followed when creating an app. A process only needs the privileges which are essential to perform its intended function. The minimum access your app has – be it to APIs or sensitive data in a database – the better. If things go wrong, this limitation will help you.

• Validating insecure input

Insecure input validation occurs when an application does not apply the correct validation routine based on the type of input received. You cannot be sure how an application will behave when you provide it with unexpected input. Filtering that input server-side is always necessary, even if you think the input can’t be altered. (Spoiler alert: it can!)

• Not keeping up to date with standards

With security demands constantly changing, you need to stay informed on foundational security practices. The internet is full of resources to help guide development for every programming language possible. There’s no shortage of specialized forums for advanced concept discussion, either. Get informed and protect your data.

• Publishing unfinished applications

If you publish private or early stage apps in public, the project can become a nightmare. Users can get access to broken features or dangerous functions that were never tested. Most apps in development expose verbose error messages that can reveal a lot of information about the app to an attacker. Always be careful when publishing test or private apps to the store.

Not everyone needs to be told to keep their eyes open while driving, but every sign was put there for a reason, and will probably help somebody if not you. We hope these advisories inspire researchers to pursue these issues further, and not just tick off boxes when it comes to securing their creations.