Segurança de apps na era agêntica

Olá, meu nome é Kristen.

Olá, eu sou a Sabs.

Hoje, vamos falar sobre segurança na era agêntica.

No ano passado, pagamos mais de US$ 2 milhões em recompensas pelo programa Android Bug Hunters e mais de US$ 200 mil para dispositivos móveis.

Na era agêntica de hoje, a segurança de apps está em constante evolução.

Então, vamos falar sobre as ferramentas que nos ajudam a resolver esses problemas de forma rápida e eficaz.

Para melhorar o desempenho dos agentes na segurança do Android, a resposta não é um comando melhor.

São ferramentas e fluxos de trabalho para ajudar os agentes a entender nossos conjuntos de ferramentas e APIs para manter seu app seguro.

São 16h30.

Em uma quinta-feira.

Você está lançando uma versão, e a CI fica vermelha, com apenas um erro: um broadcast receiver registrado sem uma flag de exportação.

Portanto, seja em uma equipe pequena, em que você faz de tudo, ou em uma grande, em que as verificações de segurança são feitas durante o lançamento, a realidade é a mesma.

Somos engenheiros de produto, lançamos recursos de alta qualidade rapidamente e não somos necessariamente pesquisadores de segurança.

Então, qual é o instinto natural?

Então, enviamos esse aviso para uma ferramenta agêntica e pedimos uma correção ao agente.

No entanto, a ferramenta de agente, que funciona sem o contexto do projeto, tem três pontos cegos.

Talvez ele não saiba que seu app é criado com módulos de recursos dinâmicos ou pacotes de vários APKs.

Ele vê um arquivo, não um artefato enviado.

Ele pode não saber ou não conseguir rastrear o fluxo de dados da interface do Kotlin até a lógica compartilhada do KMP nas chamadas JNI nativas do C++.

Ele vê apenas uma camada.

Por último, mas não menos importante, ele pode não ter conhecimento do SDK mínimo ou das variações de build do Gradle.

Então, apontamos um agente para o app e pedimos uma auditoria de segurança.

Seis descobertas foram retornadas.

E aqui está o problema.

Cada um deles está certo.

Elas são defensáveis, mas apenas uma delas é o bug com que começamos.

O restante é uma mistura de boas práticas, coisas para investigar mais, especulações e coisas que podem nem se aplicar.

Agora, você escala isso para uma base de código real, com mais avisos, e em cada solicitação de pull, você vai querer usar o suppress lint.

Você terá que fazer uma mudança para que essa alteração seja mesclada ou pode até mesmo perder uma vulnerabilidade.

É assim que vulnerabilidades reais passam despercebidas.

A ferramenta não foi descuidada, foi cuidadosa, mas cuidadosa não é o mesmo que útil.

Vamos dar um exemplo concreto.

Por exemplo, você pede ao agente: "Audite todos os componentes exportados neste app para redirecionamento de intent do app".

Essa é uma tarefa de segurança real e, em um app com vários módulos, é uma tarefa grande.

Esse é o tipo de solicitação em que o custo realmente aparece.

Sem orientações específicas sobre o Android, o agente não tem uma estratégia para responder à pergunta.

Então, ele usa força bruta.

Ele pode ler módulos que não exportam nada.

Ele pode derivar novamente do primeiro princípio o que torna um redirecionamento de intent explorável.

Ele pode seguir caminhos que nunca foram alcançáveis.

Você está pagando pela exploração, não pela análise.

Uma habilidade é o que fornece a estratégia que falta.

As habilidades de segurança do Android, por exemplo, fornecem ao agente instruções que seguem as orientações atuais, a mesma sequência de etapas que um pesquisador de segurança seguiria, e o agente para de adivinhar.

Ele não redescobre as regras porque elas foram fornecidas pela habilidade.

No momento, lançamos duas habilidades de segurança: segurança de intent e permissões.

A segurança de intents se refere ao que outros apps podem fazer com o seu.

Seu app tem permissões e uma sessão de login que eles não têm.

Portanto, cada componente exportado e cada intent pendente que você distribui é uma maneira potencial de alguém agir por você.

A habilidade ajuda a proteger contra isso.

A habilidade de permissões ajuda a diminuir a diferença entre uma permissão declarada e uma que é realmente aplicada.

Ele pode ajudar você a escrever a verificação de permissões adequada.

Ele ajuda a identificar se um provedor com um caminho curinga concede acesso a todo o banco de dados em vez de apenas um diretório.

Ele também detecta permissões excessivas.

Por exemplo, solicitar acesso amplo quando o seletor de fotos seria suficiente.

Use-o com a CLI do Android e pergunte: "Auditar a segurança de intents".

Nenhuma configuração.

Nenhum ajuste de regra.

Assim, a saída não é uma parede de avisos.

É uma avaliação.

Aqui está um bug, aqui está o motivo de ele ser importante para seu app e aqui está a correção.

E aqui vai uma dica profissional.

Use a CLI do Android para facilitar a localização e a instalação.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

Como a habilidade sabe exatamente o que procurar no seu projeto, ela vê o app da forma como ele é enviado.

Ele respeita o SDK mínimo para que a correção seja compilada, os caminhos de arquivo reais e os números de linha reais.

Esta é a avaliação que você recebe.

Ele aponta para o arquivo e a linha exatos, explica a ameaça real e a explicação para a mudança, não apenas o Lint diz isso.

Ele cita qual habilidade foi usada.

Ele leu a configuração do build, viu o SDK mínimo 26 e escolheu ContextCompat para que a correção funcione, além de fornecer um diff para você aplicar.

Esse é o aviso que abrimos, mas agora com uma sugestão de correção e um motivo.

As habilidades anteriores detectam bugs de segurança.

Agora vamos falar sobre outra área: conformidade com as políticas de apps.

Por exemplo, imagine que você é um novo desenvolvedor de apps que quer lançar um produto na Google Play Store.

Preencher o formulário de Segurança dos dados é uma etapa importante no lançamento do app. Por isso, vamos usar todas as ferramentas possíveis para garantir que tudo esteja correto antes do envio.

A habilidade de política do Google Play realiza uma análise estática na sua base de código.

Se você estiver publicando um app que já está na Google Play Store, também é possível comparar essa análise de código estático com as declarações da Google Play Store.

Com essa habilidade, você pode identificar possíveis problemas com as políticas do Google Play antes do envio do app, o que ajuda a acelerar o processo.

O fluxo de trabalho é semelhante ao das outras habilidades que discutimos: importe o app e peça para o Gemini "Auditar este app para verificar a conformidade com as políticas do Google Play antes de enviá-lo".

À direita, você verá uma captura de tela de um exemplo de relatório e, abaixo, os comandos da CLI do Android para instalá-lo.

android skills list
android skills add play-policy-insights

Então, tudo o que falamos até agora acontece antes do envio: auditoria de intents, verificação de permissões, validação de compliance.

Essa é a segurança do tempo de compilação, que é essencial.

Mas há toda uma classe de ameaças que só existe quando o APK está no mundo, em execução em dispositivos que você talvez não controle.

A API Play Integrity responde a três perguntas no momento da execução que seu próprio código não pode responder sobre si mesmo: esta é uma versão genuína e não modificada do seu app?

O app está sendo executado em um dispositivo Android genuíno?

E essa é uma conta de usuário do Google Play?

Assim, você pode usar a API Play Integrity para retornar vereditos sobre a integridade do app, do dispositivo e muito mais.

Além de tornar mais rápido e fácil publicar seu app com segurança, também estamos facilitando a proteção da receita e da reputação dele.

Portanto, defenda sua empresa contra fraudes e abusos.

O novo painel Protegido com o Google Play, que você pode ver aqui, ajuda a monitorar e configurar suas defesas de integridade, distribuição e monetização em um só lugar.

Também estamos reduzindo a latência de inicialização da API Play Integrity para que você possa usar essas verificações durante jornadas do usuário em que a velocidade é essencial para bloquear ameaças e dispositivos de risco mais rapidamente.

Acabamos de falar sobre os recursos e as ferramentas do Android que ajudam a manter os apps seguros, mas e os usuários?

Primeiro, vamos analisar a proteção de OTP por SMS.

Digamos que você queira implementar a verificação de usuário por SMS no seu app e enviar códigos de verificação.

A permissão de SMS dá ao app acesso a dados de mensagens, incluindo dados sensíveis, como senhas únicas.

Por isso, introduzimos algumas APIs no seu app para que você possa implementar isso, sem precisar solicitar permissões amplas de SMS, mas ainda assim conseguir receber códigos OTP de SMS para verificação.

A API SMS Retriever permite que seu app verifique automaticamente as OTPs sem permissões amplas de SMS.

Você anexa um hash de 11 caracteres que identifica seu app à mensagem, e o sistema entrega apenas essa mensagem.

Se não for possível controlar o formato da mensagem, use a API SMS User Consent.

O sistema mostra um único comando.

O usuário toca em "Permitir" ou "Negar". Se ele permitir, você vai receber essa mensagem única.

Ainda não é necessária uma permissão ampla de SMS.

Alguns apps podem precisar do local exato apenas uma vez para concluir tarefas.

A permissão única atual tem alta fricção para o usuário. Por isso, às vezes os desenvolvedores pedem uma permissão precisa mais ampla.

O botão de localização é uma ferramenta que oferece uma maneira simples de conceder ao app acesso único à localização exata.

É um elemento da interface do Android que pode ser personalizado e incorporado por desenvolvedores de apps.

Lançamos a primeira versão da biblioteca Jetpack do botão de localização Alfa em junho.

Aqui, você pode ver as permissões necessárias para ativar o botão de localização no manifesto do Android.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

É necessário declarar a permissão de localização padrão, adicionando a flag de permissão onlyForLocationButton, além da permissão dedicada USE_LOCATION_BUTTON exigida pelo serviço de renderização remota do sistema.

À direita, está o código do Jetpack para implementá-lo.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Aqui, estamos criando um botão de localização e inicializando um callback.

Esse callback é acionado quando o usuário toca no botão de localização para decidir se a permissão será concedida ou negada.

O Modo de Proteção Avançada é um recurso voltado para usuários em risco ou que se preocupam com a segurança, mas qualquer pessoa pode ativar.

Por exemplo, se você tem um app bancário, não force a autenticação multifator extra em todas as transferências, porque os usuários comuns não gostam desse atrito extra.

No entanto, quando o Modo de Proteção Avançada está ativado, o app sabe que o usuário quer o máximo de proteção. Assim, você pode exigir automaticamente a autenticação biométrica em todas as transferências.

O Modo Proteção Avançada implementa um conjunto de configurações predefinidas para reforçar a proteção do dispositivo.

Aqui, mostramos como fazer a integração ao seu app.

Você precisa solicitar a permissão, consultar o Modo Proteção Avançada e verificar se o usuário ativou o Modo Proteção Avançada usando o serviço do sistema do Gerenciador do Modo Proteção Avançada no dispositivo.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Em seguida, você pode detectar mudanças no ambiente de execução registrando o callback.

Abordamos muitos tópicos hoje.

Aqui estão alguns links rápidos para você saber mais sobre eles.

Vamos fazer uma pausa para você anotar os URLs necessários.

Nossa equipe agradece.

Nossa equipe agradece.