Adicionar mais cabeçalhos de solicitação HTTP

Pavol Drotar
Pavol Drotar

As solicitações HTTP contêm cabeçalhos como User-Agent ou Content-Type. Além dos cabeçalhos anexados por navegadores, os apps Android podem adicionar cabeçalhos extras, como Cookie ou Referrer, usando a intent extra EXTRA_HEADERS. Por motivos de segurança, o Chrome filtra alguns dos cabeçalhos extras dependendo de como e onde uma intent é iniciada.

As solicitações entre origens exigem uma camada extra de segurança, já que o cliente e o servidor não são de propriedade da mesma parte. Este guia discute o lançamento dessas solicitações usando guias personalizadas do Chrome, ou seja, intents iniciadas por apps que abrem um URL na guia do navegador. Até o Chrome 83, os desenvolvedores podiam adicionar qualquer cabeçalho ao iniciar uma guia personalizada. A partir da versão 83, o Chrome começou a filtrar todos os cabeçalhos de origem cruzada, exceto os da lista de permissões, porque os cabeçalhos não incluídos na lista representavam um risco de segurança. A partir do Chrome 86, é possível anexar cabeçalhos não aprovados à lista a solicitações entre origens diferentes quando o servidor e o cliente estão relacionados usando um link de recurso digital. Esse comportamento é resumido na tabela a seguir:

Versão do Chrome Cabeçalhos CORS permitidos
antes do Chrome 83 na lista de aprovados e não aprovados
Do Chrome 83 ao Chrome 85 na lista de permissões
do Chrome 86 em diante na lista de aprovação, fora da lista de aprovação quando um link de recurso digital é configurado

Tabela 1: Filtragem de cabeçalhos CORS não aprovados na lista.

Este artigo mostra como configurar uma conexão verificada entre o servidor e o cliente e usá-la para enviar cabeçalhos HTTP aprovados e não aprovados. Você pode pular para Adicionar cabeçalhos extras às intents de guias personalizadas para conferir o código.

Contexto

Cabeçalhos de solicitação de CORS com e sem lista de aprovação

O Compartilhamento de recursos entre origens (CORS) permite que um aplicativo da Web de uma origem solicite recursos de outra origem. A lista de cabeçalhos aprovados pelo CORS é mantida no padrão HTML. Confira na tabela a seguir exemplos de cabeçalhos na lista de aprovação:

Cabeçalho Descrição
accept-language anuncia as linguagens naturais que o cliente entende
content-language descreve a linguagem destinada ao público-alvo atual
content-type indica o tipo de mídia do recurso

Tabela 2: Exemplo de cabeçalhos CORS aprovados.

Os cabeçalhos da lista de aprovação são considerados seguros porque não contêm informações confidenciais do usuário e é improvável que façam com que o servidor execute operações potencialmente prejudiciais.

Exemplos de cabeçalhos não aprovados são mostrados na tabela a seguir:

Cabeçalho Descrição
token do portador autentica o cliente em um servidor
origem indica a origem da solicitação
biscoito contém cookies definidos pelo servidor

Tabela 3: Exemplo de cabeçalhos CORS não aprovados.

O anexo de cabeçalhos não aprovados às solicitações do CORS é desencorajado pelo padrão HTML, e os servidores assumem que as solicitações de origem cruzada contêm apenas cabeçalhos aprovados. O envio de cabeçalhos não aprovados de domínios de origem cruzada permitiria que apps de terceiros maliciosos criassem cabeçalhos que usam indevidamente cookies do usuário que o Chrome (ou outro navegador) armazena e anexa às solicitações. Os cookies podem autenticar transações maliciosas de servidores que, de outra forma, não seriam possíveis.

Como anexar cabeçalhos aprovados pelo CORS a solicitações de guias personalizadas

As Guias personalizadas são uma maneira especial de abrir páginas da Web em uma guia de navegador personalizada. As intents de guia personalizada podem ser criadas usando CustomTabsIntent.Builder(). Também é possível anexar cabeçalhos a essas intents usando um Bundle com a flag Browser.EXTRA_HEADERS:

CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();

Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");   
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);

intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));

Podemos anexar cabeçalhos aprovados às solicitações CORS de guias personalizadas. No entanto, o Chrome filtra cabeçalhos não aprovados por padrão. Embora outros navegadores possam ter comportamentos diferentes, os desenvolvedores devem esperar que os cabeçalhos não aprovados sejam bloqueados em geral.

A maneira recomendada de incluir cabeçalhos não aprovados na lista em guias personalizadas é verificar primeiro a conexão entre origens diferentes usando um link de acesso digital. A próxima seção mostra como fazer a configuração e iniciar uma intent de guias personalizadas com os cabeçalhos necessários.

Adicionar mais cabeçalhos a intents de guia personalizada

Para permitir que cabeçalhos não aprovados na lista de permissões sejam transmitidos por intents da guia personalizada, é necessário configurar um link de recurso digital entre o aplicativo Android e da Web que verifique se o autor é o proprietário dos dois aplicativos.

Siga o guia oficial para configurar um link de recurso digital. Para a relação de link, use "delegate_permission/common.use_as_origin", que indica que os dois apps pertencem à mesma origem depois que o link é verificado.

Criar intent de guia personalizada com cabeçalhos extras

Há várias maneiras de criar uma intent de guias personalizadas. É possível usar o builder disponível no AndroidX adicionando a biblioteca às dependências de build:

MULTI_LINE_CODE_PLACEHOLDER_1

Crie a intent e adicione cabeçalhos extras:

MULTI_LINE_CODE_PLACEHOLDER_2

Uma conexão de guias personalizadas é usada para configurar um CustomTabsSession entre o app e a guia do Chrome. Precisamos da sessão para verificar se o app e o da Web pertencem à mesma origem. A verificação só é aprovada se os links de recursos digitais forem configurados corretamente.

É recomendável chamar CustomTabsClient.warmup(). Ele permite que o aplicativo do navegador seja pré-inicializado em segundo plano e acelere o processo de abertura de URL.

MULTI_LINE_CODE_PLACEHOLDER_3

Configurar um callback que inicia a intent após a validação

O CustomTabsCallback foi transmitido para a sessão. Configuramos o onRelationshipValidationResult() para iniciar o CustomTabsIntent criado anteriormente assim que a verificação de origem for bem-sucedida.

MULTI_LINE_CODE_PLACEHOLDER_4

Vincular a conexão do serviço de guias personalizadas

Vincular o serviço inicia o serviço, e o onCustomTabsServiceConnected() da conexão será chamado eventualmente. Não se esqueça de desvincular o serviço adequadamente. A vinculação e a desvinculação geralmente são feitas nos métodos de ciclo de vida da atividade onStart() e onStop().

// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
    CustomTabsClient.getPackageName(MainActivity.this, null), connection);

// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);

Código do aplicativo de demonstração

Saiba mais sobre o serviço de guias personalizadas neste link. Consulte o repositório do GitHub android-browser-helper para conferir um app de exemplo funcional.

Resumo

Este guia demonstrou como adicionar cabeçalhos arbitrários às solicitações CORS de guias personalizadas. Cabeçalhos em lista de aprovação podem ser anexados a todas as solicitações CORS de guias personalizadas. Os cabeçalhos não aprovados geralmente são considerados inseguros em solicitações CORS, e o Chrome os filtra por padrão. A vinculação deles é permitido apenas para clientes e servidores da mesma origem, verificados por um link de recurso digital.