Every Sign Has a Story

by Thiago Campos, on Aug 12, 2019 9:24:00 AM

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.

190801-blog-googleGsuite-every-sign3

Caption: 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

    2019-08-13 13_59_13-Build your app  _  G Suite Marketplace  _  Google Developers

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

    190806-bishop-fox-blog-every-sign-2-1

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

    Warning to use OAuth 2.0 libraries instead of custom code.

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

190806-bishop-fox-blog-every-sign-4

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

Warning to not use someone else 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

Warning sign to store and manage private keys securely

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

Caution sign about execution identity

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

Tip sign about insecure input types

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

Note about best practice on security measures

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

Warning sign on published application visibility

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.

Funny road sign asking drivers to keep their eyes open

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.

Topics:Category - Technical

Subscribe by Email

Comments