DEV Community: Leehendry Pauletto

Evite subir chaves de API para o GitHub em seu projeto Android, veja como.

Leehendry Pauletto — Fri, 04 Dec 2020 16:10:58 +0000

Imagem de capa por Bruno Martins @ Unsplash

Aviso

Nenhuma medida por si só tornará nossas aplicações seguras. A segurança dum app depende duma combinação de medidas, e até mesmo as sofisticadas podem ser quebradas;
Dito isso, destaco que este tutorial não consiste numa bala de prata para todos os nossos problemas de segurança, mas numa medida que pode deixar nossos apps menos sujeitos a vazamentos de dados.

Não li, nem lerei

Chaves de API são utilizadas para autenticação de clientes em serviços específicos;
A revelação de informações sensíveis, como as chaves de API, pode acarretar usos e consequências não planejados;
BuildConfig do Gradle permite ao nosso projeto ler dados sensíveis contidos num arquivo local, na forma de código gerado.

Contexto

A divulgação de dados sensíveis tem o potencial de causar danos tanto aos nossos próprios interesses quanto aos das pessoas impactadas por nossos projetos.

Embora tenha focado em chaves de API, outros dados sensíveis como endpoints e credenciais também podem ser guardados localmente com a abordagem descrita aqui.

Os quês

Antes de tudo, é melhor termos a certeza de que estamos falando das mesmas coisas:

Cliente refere-se ao software ou hardware que faz uso dos serviços disponíveis num servidor, no modelo cliente-servidor <1>;
API significa Interface de Programação de Aplicativos, que, em termos gerais, é um conjunto de regras a serem observadas na comunicação entre programas, geralmente um cliente e um serviço <2>;
Segredo, token ou chave de API é um identificador único utilizado na autenticação de um cliente num serviço<3>;
Geração de código é o processo pelo qual um compilador converte representações de código em instruções que podem ser prontamente executadas pelo dispositivo <4>.

Os porquês

Chaves de API permitem identificar clientes e são geradas para fins específicos. Por isso, é comum que a conta do cliente incorra em custos de acordo com as quotas de uso do serviço. - Google Maps Platform é um bom exemplo disso, já que os preços variam conforme a utilização;
Evitar a revelação dessas chaves é fundamental na prevenção de usos indevidos.

Apesar disso, o versionamento de chaves de API é um erro que não apenas eu mesmo cometi no passado, mas que também vi colegas de profissão cometerem, independentemente da experiência.

A verdade é que, infelizmente, práticas de Segurança da Informação ainda são pouquíssimo divulgadas nas nossas comunidades de desenvolvimento.

O como

A classe BuildConfig do Gradle permite a leitura de valores a partir de arquivos locais e a disponibilização deles na forma de código gerado;
Contanto que indiquemos corretamente os arquivos no .gitignore, a divulgação das nossas chaves de API no GitHub, GitLab e afins não deverá ser um problema.

O código

São oito as etapas:

1. Criar `keys.properties` na raiz

Na raiz do projeto, crie um arquivo chamado keys.properties e adicione a ele a chave da API desta forma:

api.key=API_KEY_HERE

2. Adicionar o caminho do arquivo `.gitignore`

Muita atenção a esta etapa, pois o .gitignore é que indica quais arquivos ficam fora do versionamento!
Para prevenir o versionamento do keys.properties, adicione o caminho do arquivo ao .gitignore desta forma:

/keys.properties

Rode no terminal o comando git status. O arquivo keys.properties não deverá estar listado para versionamento. Caso esteja, significa que a configuração do .gitignore está errada! Repita a etapa.

3. Criar `keys.gradle` na raiz

Para recuperar os valores do keys.properties, adicione à raiz do projeto um arquivo chamado keys.gradle, onde o seguinte código Groovy será adicionado:

// Define como carregar as informações do arquivo local
def getStringFromFile(fileName, property) {
    Properties props = new Properties()

    props.load(project.rootProject.file(fileName).newDataInputStream())

    return props[property].toString()
}


// Indica keys.properties como o arquivo para recuperação dos valores
def getStringFromKeysFile(property) {
    return getStringFromFile('keys.properties', property).toString()
}


// Expõe a chave definida no keys.properties como uma variável para uso em todo o projeto
ext.keys = ["apiKey": getStringFromKeysFile('api.key'),]

4. Importe `keys.gradle` dentro do `project/build.gradle`

Para utilizar os métodos definidos no keys.gradle, importe o arquivo dentro do build.gradle do projeto:

buildscript {
    apply from: project.rootProject.file("keys.gradle")

    ...

}

A esta altura, a BuildConfig já consegue automaticamente converter nossa chave em código compilado -- mas só faremos isso na etapa 6.

5. Definir uma constante para a chave dentro do `app/build.gradle`

Defina uma constante chamada API_KEY no build.gradle do app desta forma:

android {

...

    buildTypes {

     // Embora esteja configurado para 'debug', certifique-se de quais build variants (debug, staging, release etc) precisarão da chave:
        debug {

            ...

            it.buildConfigField "String", "API_KEY", keys.apiKey
        }
}

6. Limpar e recompilar o projeto

Para que o código seja efetivamente gerado, selecione Build > Clean Project e depois Build > Rebuild Project no menu superior do Android Studio.

7. Chamar a variável via `BuildConfig` dentro do projeto

Chame a constante via BuildConfig.API_KEY, conforme etapa 5, onde for necessário no código. Por exemplo:

class CustomApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        Firebase.init(this, BuildConfig.API_KEY)
    }
}

8. Compartilhar o arquivo `keys.properties` de forma segura dentro do time

Já que evitamos o versionamento da chave da API, é necessário utilizar uma maneira segura de compartilhar o keys.properties entre as pessoas da equipe;
Caso seu trabalho conte com um time de Segurança da Informação, verifique com ele qual a melhor forma de compartilhar o arquivo;
Do contrário, ferramentas como 1Password podem ajudar, já que permitem a gestão de direitos de acesso aos arquivos.

Considerações finais

Outras informações sensíveis como endpoint e credenciais também pode sem mantidas localmente com essa abordagem;
Nomes como keys.properties, api.key, keys.gradle e API_KEY são arbitrários -- apenas mantenha as extensões (.properties, .key, .gradle) ao renomear;
NOTE QUE BuildConfig gera código compilado, o que significa que engenharia reversa do .apk ainda pode expor chaves de API e outros segredos;
Apenas a combinação de medidas de segurança pode nos ajudar a manter nossos apps seguros. Busque também ferramentas de otimização e ofuscação de código como R8 para reduzir as chances de vazamento de dados.

Agradecimentos especiais ao Victor Vieira por me ensinar essa abordagem há um ano; e ao Walmyr Carvalho por me estimular a escrever aqui no dev.to!

Avoid uploading API keys and other sensitive info to GitHub on Android, here's how.

Leehendry Pauletto — Thu, 03 Dec 2020 22:39:33 +0000

Cover image by Bruno Martins @ Unsplash

Disclaimer

There’s no measure alone that will make your app secure. Securing an app requires a combination of measures, and even sophisticated ones can eventually be cracked;
That said, this tutorial is not a silver bullet for all our security problems, but one of those measures that can make our apps less prone to information leak.

TL;DR

API keys are used to authenticate users on specific services;
Disclosure of sensitive info such as keys can lead to unintended use and consequences;
Gradle's BuildConfig can be used to read sensitive values from a local file and provide them to our project via generated code.

Context

Disclosing sensitive info may result in damage not only to ourselves, but also to users of our projects.

Although I have focused on API keys, other sensitive info like endpoints and credentials can also be kept locally with this approach.

The Whats

First of all, let's make sure we're talking about the same stuff:

Client refers to software or hardware making use of services provided by a server, in a client-server model <1>;
API stands for Application Programming Interface, which is basically a set of rules you must observe for communication between programs, often a client and a service <2>;
API secret, token or key is a unique identifier used to authenticate a client on an API service <3>;
Code generation is a process by which a compiler can convert representations of code into ones that can be readily executed by the machine <4>.

The Whys

API keys are a way of identifying users and are generated for specific purposes. Due to that, user accounts are often charged second to service use quotas. - Google Maps Platform is a good example of that, as prices vary depending on how services are used.
Avoiding public disclosure of such keys is fundamental to prevent unintended service use.

Despite that, API key versioning is a mistake that not only have I committed in the past, but also seen committed by fellow junior and more senior developers alike.

Unfortunately, Information Security -- or Info Sec -- practices are still poorly spread within our developer communities.

The How

Gradle's BuildConfig class allows us to read values from local files and then generate code to be used by our app.
As long as we correctly add such files to .gitignore, public disclosure of our API keys on GitHub, GitLab or the likes should be less of a problem.

The Code

There are eight steps:

1. Create `keys.properties` at the root

At the root of the project, create a file named keys.properties and add your API key to the file as such:

api.key=API_KEY_HERE

2. Add file path to `.gitignore`

To prevent the versioning of keys.properties, add the file path to .gitignore file as such:

/keys.properties

3. Create `keys.gradle` at the root

In order to retrieve the keys in keys.properties, add to the root of the project a file named keys.gradle, where the following Groovy code should be added:

// Define how to load a string from a properties file:
def getStringFromFile(fileName, property) {
    Properties props = new Properties()

    props.load(project.rootProject.file(fileName).newDataInputStream())

    return props[property].toString()
}


// Specify keys.properties file as the source
def getStringFromKeysFile(property) {
    return getStringFromFile('keys.properties', property).toString()
}


// Expose the key defined in keys.properties as a variable available for the whole project
ext.keys = ["apiKey": getStringFromKeysFile('api.key'),]

4. Import `keys.gradle` inside `project/build.gradle`

In order to use the methods defined in keys.gradle, import the file inside the build.gradle file of the project:

buildscript {
    apply from: project.rootProject.file("keys.gradle")

    ...

}

At this point, BuildConfig is already able to automatically convert the key into compiled code -- but we'll do that on the step 6.

5. Define a constant for the key inside the `app/build.gradle`

Define a constant named API_KEY in the build.gradle file of the app, as follows:

android {

...

    buildTypes {

     // Although it's set to 'debug', certify what build variants (say debug, staging, release) will need to access the key:
        debug {

            ...

            it.buildConfigField "String", "API_KEY", keys.apiKey
        }
}

6. Clean and recompile the project

For the code to be effectively generated, select Build > Clean Project and then Build > Rebuild Project at the upper menu of Android Studio.

7. Call the key variable via `BuildConfig` inside the project

Call the constant named in step 5 as BuildConfig.API_KEY where it's needed. For example:

class CustomApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        Firebase.init(this, BuildConfig.API_KEY)
    }
}

8. Share `keys.properties` in a secure manner inside your team

Since we have avoided the versioning of the API key, we need a secure way of sharing the keys.properties file between the members of the development team;
If your company has an Info Sec team, check with them what's the best way to share the file;
If not, solutions like 1Password may be a good choice to do so, since it offers manners of managing user privileges.

Final considerations

Other sensitive info like endpoints and credentials can also be kept locally with this approach;
Names like keys.properties, api.key, keys.gradle and API_KEY are all arbitrary -- just keep their extensions (.properties, .key, .gradle) when renaming them.
NOTE THAT BuildConfig generates compiled code, which means that reverse engineering our app's .apk could still expose API keys and other secrets;
Only a combination of security measures can help us keep our apps secure. Look into code optimisation and obfuscation tools such as R8 to diminish the chances of info leaks.

Special thanks to Victor Vieira for teaching me the approach a year back; and to Walmyr Carvalho for stimulating me to write on dev.to!