Reescrever cabeçalhos HTTP e URL com o Gateway de Aplicativo

O Gateway de Aplicativo permite reescrever o conteúdo selecionado em solicitações e respostas. Com esse recurso, você pode traduzir URLs, consultar parâmetros de cadeia de caracteres e modificar cabeçalhos de solicitação e resposta. Você também pode adicionar condições para garantir que a URL ou os cabeçalhos especificados sejam reescritos somente quando determinadas condições forem atendidas. Essas condições se baseiam nas informações de solicitação e resposta.

Os recursos de reescrita de cabeçalho HTTP e de URL estão disponíveis somente para o SKU do Gateway de Aplicativo v2.

Cabeçalhos de solicitação e resposta

O Gateway de Aplicativo permite adicionar, remover ou atualizar solicitações HTTP e cabeçalhos de resposta, enquanto os pacotes de solicitação e resposta são transferidos entre os pools de cliente e de back-end. Os cabeçalhos HTTP permitem que um cliente e um servidor passem informações extras com uma solicitação ou resposta. Ao reescrever esses cabeçalhos, você pode realizar tarefas importantes, incluindo:

• Adicionando campos de cabeçalho relacionados à segurança, como HSTS e X-XSS-Protection
• Removendo campos de cabeçalho de resposta que podem revelar informações confidenciais
• Removendo informações de porta de cabeçalhos X-Forwarded-For

Você pode reescrever todos os cabeçalhos nas solicitações e respostas, exceto para os cabeçalhos Connection e Upgrade. Você também pode usar o gateway de aplicativo para criar cabeçalhos personalizados e adicioná-los às solicitações e respostas que estão sendo roteadas por ele. Para saber como reescrever cabeçalhos de solicitação e resposta com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.

Caminho de URL e cadeia de caracteres de consulta

Com a capacidade de reescrita de URL no Gateway de Aplicativo, você pode:

• Reescrever o nome do host, o caminho e a cadeia de caracteres de consulta da URL de solicitação

• Escolha reescrever a URL de todas as solicitações em um ouvinte ou apenas aquelas solicitações que correspondem a uma ou mais das condições que você definir. Essas condições são baseadas nas propriedades de solicitação (cabeçalho da solicitação e variáveis do servidor).

• Escolher rotear a solicitação (selecione o pool de back-end) com base na URL original ou na URL reescrita

Para saber como reescrever a URL com o Gateway de Aplicativo usando o portal do Azure, confira aqui.

Noções básicas sobre regravações no Gateway de Aplicativo

Um conjunto de reescrita é uma coleção de uma regra de roteamento, uma condição e uma ação.

• Associação da regra de roteamento da solicitação: A configuração da reescrita é associada a um ouvinte de origem por meio de sua regra de roteamento. Quando você usa uma regra de roteamento do tipo Basic, a configuração de reescrita associa-se ao ouvinte e funciona como uma regravação global. Ao usar uma regra de roteamento baseada em caminho, você define a configuração de reescrita de acordo com o mapa de caminho de URL. Nesse caso, ela se aplica somente à área de caminho específico de um site. Você pode aplicar um conjunto de reescrita a várias regras de roteamento, mas uma regra de roteamento pode ter apenas uma regra de reescrita associada a ela.

• Condição de reescrita: Essa configuração é opcional. Com base nas condições definidas, o Gateway de Aplicativo avalia o conteúdo das solicitações e respostas HTTP(S). A "ação de reescrita" subsequente ocorrerá se a solicitação ou resposta HTTP(S) corresponder a essa condição. Se você associar mais de uma condição a uma ação, a ação ocorrerá somente quando todas as condições forem atendidas. Em outras palavras, é uma operação AND lógica. Você pode usar condições de reescrita para avaliar o conteúdo de solicitações e respostas HTTP(S). Essa configuração opcional permite que você execute uma reescrita apenas quando uma ou mais condições forem atendidas. O gateway de aplicativo usa esses tipos de variáveis para avaliar o conteúdo de solicitações e respostas:

  Você pode escolher os seguintes tipos para procurar uma condição:

  • Cabeçalho HTTP (Solicitação e Resposta)
  • Variáveis de servidor compatíveis

  Uma condição permite avaliar se existe um cabeçalho ou variável especificado, verificando a correspondência de seus valores por meio de texto ou de um padrão Regex. Para configurações avançadas de reescrita, você também pode capturar o valor de cabeçalho ou variável de servidor para uso posterior em Ação de Reescrita. Saiba mais sobre padrão e captura.

• Reescrita ação: O conjunto de ações de reescrita permite que você reescreva cabeçalhos (solicitação ou resposta) ou os componentes da URL.

  Uma ação pode ter os seguintes tipos de valor ou combinações deles:

  • Text.
  • Valor do cabeçalho de solicitação – para usar o valor de um cabeçalho de solicitação capturado, especifique a sintaxe como {http_req_headerName}.
  • Valor do cabeçalho de resposta – para usar o valor de um cabeçalho de resposta capturado da condição anterior, especifique a sintaxe como {http_resp_headerName}. O bloco de Ação de Reescrita também dá suporte ao campo “Correspondente de Valor de Cabeçalho” do cabeçalho Set-Cookie. Este campo opcional permite associar e capturar o valor de um cabeçalho específico quando existem vários cabeçalhos Set-Cookie com o mesmo nome. Para manipular o valor capturado desse cookie específico, você pode usar {capt_header_value_matcher}. Saiba mais sobre captura no conjunto de ações.
  • Variável de servidor – Para usar uma variável de servidor, especifique a sintaxe como {var_serverVariable}. Lista de variáveis de servidor compatíveis.

Quando você usa uma ação para reescrever uma URL, há suporte para as seguintes operações:

• Caminho da URL: o novo valor que deve ser definido como o caminho.
• Cadeia de caracteres de consulta da URL: o valor para o qual a cadeia de caracteres de consulta precisa ser reescrita.
• Reavaliar o mapa do caminho: especifique se o mapa do caminho da URL precisa ser reavaliado após a reescrita. Se você não selecionar essa opção, o caminho da URL original será usado para corresponder ao padrão de caminho no mapa do caminho da URL. Se você definir essa opção como true, o mapa do caminho da URL será reavaliado para verificar a correspondência com o caminho reescrito. Habilitar essa opção ajuda a rotear a solicitação para um pool de back-end diferente após a reescrita.

Captura e padrões correspondentes

Application Gateway dá suporte à correspondência de padrões e à captura sob Condição e Ação. Em Ação, ele dá suporte à correspondência de padrões e à captura apenas para um cabeçalho específico.

Correspondência de padrões

O Gateway de Aplicativo usa expressões regulares para padrões correspondentes na condição. Use expressões compatíveis com RE2 (Expressão Regular 2) ao escrever sua sintaxe de correspondência de padrões.

Você pode usar padrões correspondentes em Condição e também em Ação.

• Condição: use essa configuração para corresponder aos valores de um cabeçalho ou variável de servidor. Para corresponder a um padrão em "Condições", use a propriedade "pattern".
• Ação: A correspondência de padrões no Conjunto de Ações está disponível apenas para o cabeçalho de resposta Set-Cookie. Para corresponder a um padrão de Set-Cookie em uma ação, use a propriedade HeaderValueMatcher. Se capturado, seu valor pode ser usado como {capt_header_value_matcher}. Como pode haver vários Set-Cookie cabeçalhos, a correspondência de padrões aqui permite que você procure um cookie específico. Por exemplo, para uma determinada versão do agente de usuário, você deseja reescrever o set-cookie cabeçalho de resposta para cookie2 com max-age=3600 (uma hora). Nesse caso, você pode usar
  • Condição – Tipo: Cabeçalho da solicitação, Nome do cabeçalho: user-agent, Padrão para corresponder: *2.0
  • Ação – Tipo de reescrita: cabeçalho de resposta, tipo de ação: Set, Nome do cabeçalho: Set-Cookie, Correspondente de Valor de Cabeçalho: cookie2=(.*), Valor do cabeçalho: cookie2={capt_header_value_matcher_1};Max-Age=3600

Sintaxe para captura

Você pode usar padrões para capturar uma subcadeia de caracteres para uso posterior. Coloque parênteses em torno de um sub-padrão na definição regex. O primeiro par de parênteses armazena sua subcadeia de caracteres em 1, o segundo par em 2 e assim por diante. Você pode usar quantos parênteses desejar. Perl define mais variáveis numeradas para representar essas cadeias de caracteres capturadas. Você pode encontrar alguns exemplos nesta orientação de programação perl.

• /(\d)(\d)/ # Corresponder dois dígitos, capturando-os nos grupos 1 e 2
• /(\d+)/ # Corresponder um ou mais dígitos, capturando todos eles no grupo 1
• /(\d+)/ # Corresponder um dígito uma ou mais vezes, capturando o último no grupo 1

Depois de capturados, você pode referenciá-los no conjunto de ações usando o seguinte formato:

• Para uma captura de cabeçalho de solicitação, você deve usar {http_req_headerName_groupNumber}. Por exemplo, {http_req_User-Agent_1} ou {http_req_User-Agent_2}
• Para uma captura de cabeçalho de resposta, você deve usar {http_resp_headerName_groupNumber}. Por exemplo, {http_resp_Local_1} ou {http_resp_Local_2}. Enquanto para um cabeçalho de resposta Set-Cookie capturado por meio da propriedade "HeaderValueMatcher", você precisa usar {capt_header_value_matcher_groupNumber}. Por exemplo, {capt_header_value_matcher_1} ou {capt_header_value_matcher_2}.
• Para uma variável de servidor, você deve usar {var_serverVariableName_groupNumber}. Por exemplo, {var_uri_path_1} ou {var_uri_path_2}

Variáveis de servidor

O Gateway de Aplicativo usa variáveis de servidor para armazenar informações úteis sobre o servidor, a conexão com o cliente e a solicitação atual na conexão. Exemplos de informações armazenadas incluem o endereço IP do cliente e o tipo de navegador da Web. As variáveis de servidor são alteradas dinamicamente, por exemplo, quando uma nova página é carregada ou quando um formulário é postado. Você pode usar essas variáveis para avaliar as condições de reescrita e reescrever cabeçalhos. Para reescrever cabeçalhos usando variáveis de servidor, especifique essas variáveis na sintaxe {var_serverVariableName}

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor:

Variáveis do servidor de autenticação mútua

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor para cenários de autenticação mútua. Use essas variáveis de servidor como faria com outras variáveis de servidor.

Cenários comuns de reescrita de cabeçalho

Remover informações da porta do cabeçalho X-Forwarded-For

O Gateway de Aplicativo insere um cabeçalho X-Forwarded-For em todas as solicitações antes de encaminhar as solicitações ao back-end. Esse cabeçalho é uma lista separada por vírgulas de portas IP. Pode haver cenários nos quais os servidores back-end só precisam que os cabeçalhos contenham endereços IP. Você pode usar a reescrita de cabeçalho para remover informações da porta do cabeçalho X-Forwarded-For. Uma maneira de fazer isso é definir o cabeçalho para a variável de servidor add_x_forwarded_for_proxy. Como alternativa, você também pode usar a variável client_ip:

Modificar uma URL de redirecionamento

Modificar uma URL de redirecionamento pode ser útil em determinadas circunstâncias. Por exemplo, você pode redirecionar clientes originalmente para um caminho como "/blog", mas agora deseja enviá-los para "/updates" devido a uma alteração na estrutura de conteúdo.

Quando o serviço de aplicativo envia uma resposta de redirecionamento, ele usa o mesmo nome de host no cabeçalho do local da sua resposta e na solicitação que recebe do gateway de aplicativo. Portanto, o cliente fará a solicitação diretamente para contoso.azurewebsites.net/path2 em vez de passar pelo gateway de aplicativo (contoso.com/path2). Ignorar o gateway de aplicativo não é desejável.

Você pode resolver esse problema definindo o nome do host no cabeçalho do local como o nome de domínio do gateway de aplicativo.

Veja aqui as etapas para substituir o nome do host:

1. Crie uma regra de reescrita com uma condição que verifica se o cabeçalho de local na resposta contém azurewebsites.net. Insira o padrão '(https?)://. azurewebsites.net(.).

2. Execute uma ação para reescrever o cabeçalho do local para que ele tenha o nome do host do gateway de aplicativo. Insira {http_resp_Location_1}://contoso.com{http_resp_Location_2} como o valor do cabeçalho. Como alternativa, você também pode usar a variável de servidor host para definir o nome do host para corresponder à solicitação original.

   

Implementar cabeçalhos HTTP de segurança para evitar vulnerabilidades

Você pode corrigir várias vulnerabilidades de segurança implementando os cabeçalhos necessários na resposta do aplicativo. Esses cabeçalhos de segurança incluem X-XSS-Protection, Strict-Transport-Security e Content-Security-Policy. Você pode usar o Gateway de Aplicativo para definir esses cabeçalhos para todas as respostas.

Excluir cabeçalhos indesejados

Talvez você queira remover os cabeçalhos que revelam informações confidenciais de uma resposta HTTP. Por exemplo, o ideal é remover informações como o nome do servidor back-end, o sistema operacional ou os detalhes da biblioteca. Você pode usar o gateway de aplicativo para remover estes cabeçalhos:

Não é possível criar uma regra de reescrita para excluir o cabeçalho do host. Se você tentar criar uma regra de reescrita com o tipo de ação definido como "excluir" e o cabeçalho definido como "host", isso resultará em um erro.

Verificar a presença de um cabeçalho

Você pode avaliar um cabeçalho de solicitação ou de resposta HTTP quanto à presença de um cabeçalho ou variável de servidor. Essa avaliação é útil quando você deseja executar uma reescrita de cabeçalho somente quando um determinado cabeçalho está presente.

Cenários comuns de reescrita de URL

Seleção de caminho baseado em parâmetro

Para realizar cenários em que você quer escolher o pool de back-end com base no valor de um cabeçalho, parte da URL ou cadeia de caracteres de consulta na solicitação, usar uma combinação de capacidade de Reescrita de URL e roteamento baseado em caminho.

Crie um conjunto de reescrita com uma condição que verifica um parâmetro específico (cadeia de caracteres de consulta, cabeçalho etc.) e, em seguida, executa uma ação em que altera o caminho da URL (verifique se o mapa de caminho de reavaliação está habilitado). Associe o conjunto de regras de reescrita a uma regra baseada em caminho. A regra baseada em caminho deve conter os mesmos caminhos de URL especificados no conjunto de reescrita e no pool de back-end correspondente.

Assim, o conjunto de reescrita permite que você verifique um parâmetro específico e atribua a ele um novo caminho, e a regra baseada em caminho permite atribuir pools de back-end a esses caminhos. Enquanto a opção "Reavaliar o mapa do caminho" estiver habilitada, as rotas de tráfego serão baseadas no caminho especificado no conjunto de reescrita.

Para obter um exemplo de caso de uso usando cadeias de caracteres de consulta, consulte Rotear o tráfego usando a seleção de caminho baseado em parâmetro no portal.

Reescrever parâmetros de cadeia de caracteres de consulta com base na URL

Considere um cenário de um site de compras em que o link visível pelo usuário é simples e legível, mas o servidor de back-end precisa dos parâmetros de cadeia de caracteres de consulta para mostrar o conteúdo certo.

Nesse caso, o Gateway de Aplicativo pode capturar parâmetros da URL e adicionar pares chave-valor de cadeia de caracteres de consulta desses parâmetros na URL. Por exemplo, se o usuário quiser reescrever https://www.contoso.com/fashion/shirtshttps://www.contoso.com/buy.aspx?category=fashion&product=shirts, você poderá atingir essa meta por meio da seguinte configuração de regravação de URL.

Condição – Se a variável uri_path de servidor for igual ao padrão /(.+)/(.+)

Ação - Defina o caminho da URL para buy.aspx e a cadeia de caracteres de consulta para category={var_uri_path_1}&product={var_uri_path_2}

Para um guia passo a passo para alcançar o cenário descrito anteriormente, consulte Reescrever URL com o Gateway de Aplicação usando o portal do Azure.

Reescrever as armadilhas comuns da configuração

• Você não pode habilitar 'Reavaliar mapa de caminho' para regras básicas de roteamento de solicitação. Essa restrição impede um loop de avaliação infinita para uma regra básica de roteamento.

• Para regras de roteamento baseadas em caminho, você precisa de pelo menos uma regra de reescrita condicional ou uma regra de reescrita sem o "mapa de caminho de reavaliação" habilitado. Esse requisito impede um loop de avaliação infinita para uma regra de roteamento baseada em caminho.

• Se um loop for criado dinamicamente com base nas entradas do cliente, as solicitações de entrada terminarão com um código de erro 500. O Gateway de Aplicativo continua a atender a outras solicitações sem nenhuma degradação neste cenário.

Usando a reescrita de URL ou a reescrita de cabeçalho de host com o Firewall do Aplicativo Web (WAF_v2 SKU)

Quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, o WAF avaliará a solicitação após a modificação do cabeçalho da solicitação ou dos parâmetros da URL (pós-reescrita). Quando você remover a configuração da reescrita de URL ou da reescrita do cabeçalho de host no seu Gateway de Aplicativo, a avaliação do WAF acontecerá antes da reescrita do cabeçalho (pré-reescrita). Essa ordem garante que as regras do WAF se apliquem à solicitação final recebida pelo pool de back-end.

Por exemplo, suponha que você tenha a seguinte regra de regra de reescrita de cabeçalho para o cabeçalho "Accept" : "text/html" – se o valor do cabeçalho "Accept" for igual a "text/html", reescreva o valor para "image/png".

Com apenas a reescrita de cabeçalho configurada, a avaliação do WAF acontece em "Accept" : "text/html". Mas quando você configura a regravação de URL ou a reescrita do cabeçalho do host, a avaliação do WAF ocorre em "Accept" : "image/png".

Reescrita de URL versus Redirecionamento de URL

Para uma regravação de URL, o Gateway de Aplicativo reescreve a URL antes de enviar a solicitação para o back-end. Essa ação não altera o que os usuários veem no navegador porque as alterações estão ocultas do usuário.

No caso do redirecionamento de URL, o Gateway de Aplicativo envia uma resposta de redirecionamento ao cliente com a nova URL. Essa resposta requer que o cliente reenvia sua solicitação para a nova URL fornecida no redirecionamento. A URL que o usuário vê no navegador será atualizada para a nova URL.

Limitações

• Não há suporte para reescritas quando o gateway de aplicativo está configurado para redirecionar as solicitações ou para mostrar uma página de erro personalizada.
• Os nomes dos cabeçalhos de solicitação podem conter caracteres alfanuméricos e hifens. Os nomes de cabeçalho que contêm outros caracteres são descartados quando uma solicitação é enviada para o destino de backend.
• Os nomes de cabeçalhos podem conter qualquer caractere alfanumérico e símbolos específicos, conforme definido no RFC 7230.
• Você não pode reescrever os cabeçalhos X-Original-Host, Connection e upgrade.
• Não há suporte para reescritas em respostas 4xx e 5xx geradas diretamente do Gateway de Aplicativo.

Próximas etapas

• Saiba como reescrever cabeçalhos HTTP com o Gateway de Aplicativo usando o portal do Azure
• Saiba como reescrever a URL com o Gateway de Aplicativo usando o portal do Azure