Encontre a Chave de API Fixa no Código: Segredos em um Binário Mobile
O desafio
Este app Android leva o segredo de pagamento de produção direto no código-fonte. Há mais de uma constante suspeita aqui, mas só uma é a verdadeira chave de API de produção que o servidor confia. Leia o código de rede e digite essa chave.
O que você vai aprender
- Reconhecer uma credencial fixa embutida no código-fonte de um app mobile
- Diferenciar um segredo de produção confiado pelo servidor de uma chave de criptografia local fraca
- Entender por que qualquer coisa distribuída em um APK pode ser extraída por um atacante
- Ler um interceptor de autenticação Retrofit/OkHttp para descobrir qual credencial é enviada
- Explicar por que segredos do lado do cliente devem ficar no backend
Habilidades testadas
Pré-requisitos
- Leitura básica de Kotlin
- O que é um token Bearer / cabeçalho Authorization
- Noção geral de como um APK é empacotado
Como funciona
Apps mobile são distribuídos como arquivos (um APK ou IPA) que ficam no dispositivo do usuário. Qualquer coisa compilada ou empacotada neles, constantes de string, chaves, endpoints, pode ser extraída com ferramentas padrão como unzip, strings, apktool, ou um descompilador. Então um segredo fixo no código mobile não é um segredo; é uma credencial publicada.
Em ApiClient.kt a constante API_KEY = "sk_live_9f3a2c7d4e1b" é anexada a cada requisição como Authorization: Bearer $API_KEY através de um interceptor OkHttp, e então usada pelo Retrofit para chamar https://api.acmepay.example. O prefixo sk_live_ marca essa chave como um segredo de produção (live). Quem extrair essa chave do binário pode falar com o gateway de pagamento como se fosse o lojista: criar cobranças, ler transações ou emitir reembolsos.
O segundo arquivo é um distrator proposital. LocalCache.kt usa uma chave AES totalmente zerada em modo ECB, uma criptografia genuinamente fraca, mas ela só embaralha um cache local e não é a credencial que o servidor autentica. A habilidade testada aqui é diferenciar um segredo real, confiado pelo servidor, de uma fraqueza local. A resposta é a chave de API de produção, sk_live_9f3a2c7d4e1b.
Erros comuns
- Enviar a chave AES 0000000000000000. Ela é fraca e é uma falha real, mas só ofusca um cache local no dispositivo, o servidor nunca confia nela.
- Informar o nome da variável (API_KEY) em vez do seu valor. A resposta é a string literal do segredo, não o identificador.
- Assumir que a chave é segura por ser private const. Modificadores de visibilidade não impedem a extração do binário empacotado.
- Ignorar o prefixo sk_live_. Esse prefixo é o indício de que se trata de uma credencial de produção, não um valor de teste ou fictício.
Como se proteger
Nunca embuta chaves de API de produção ou outros segredos confiados pelo servidor em um cliente mobile. Trate o binário do app como totalmente legível por qualquer pessoa que o instale.
- Coloque chamadas privilegiadas atrás do seu próprio backend; o app autentica o usuário, e o backend guarda o segredo do gateway.
- Emita tokens de curta duração e com escopo limitado para o cliente, em vez de uma chave mestra de longa duração.
- Rotacione imediatamente qualquer chave que tenha sido distribuída em um cliente, assumindo que ela já está comprometida.
- Faça varredura dos builds no CI em busca de padrões de segredo (por exemplo,
sk_live_) para que nunca cheguem a um release.