Reescrever cabeçalhos HTTP e URL com o Application Gateway

O Application Gateway permite reescrever o conteúdo selecionado de 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. Ele também permite que você adicione condições para garantir que a URL ou os cabeçalhos especificados sejam reescritos somente quando determinadas condições forem atendidas. Estas condições baseiam-se nas informações do pedido e da resposta.

Os recursos de cabeçalho HTTP e reconfiguração de URL só estão disponíveis para o Application Gateway v2 SKU.

Cabeçalhos de solicitação e resposta

O Application Gateway permite adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP enquanto os pacotes de solicitação e resposta se movem entre os pools de cliente e back-end. Os cabeçalhos HTTP permitem que um cliente e um servidor passem informações adicionais com uma solicitação ou resposta. Ao reescrever esses cabeçalhos, você pode realizar tarefas importantes, como adicionar campos de cabeçalho relacionados à segurança, como HSTS/ X-XSS-Protection, remover campos de cabeçalho de resposta que possam revelar informações confidenciais e remover informações de porta de cabeçalhos X-Forwarded-For.

Você pode reescrever todos os cabeçalhos em solicitações e respostas, exceto os Connectioncabeçalhos , 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 meio dele. Para saber como reescrever cabeçalhos de solicitação e resposta com o Application Gateway usando o portal do Azure, consulte aqui.

Caminho da URL e cadeia de caracteres de consulta

Com o recurso de regravação de URL no Application Gateway, você pode:

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

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

• Escolha 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, consulte aqui.

Noções básicas sobre regravações no Application Gateway

Um conjunto de regravações é uma coleção de uma Regra de Roteamento, Condição e Ação.

• Associação de regra de roteamento de solicitação: a configuração de regravação é 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 regravação é associada ao seu ouvinte e funciona como uma regravação global. Quando você usa uma regra de roteamento baseada em caminho, a configuração de regravação é definida de acordo com o mapa de caminho de URL. Neste último caso, aplica-se apenas a uma área de caminho específica de um sítio. Você pode aplicar um conjunto de regravação a várias regras de roteamento, mas uma regra de roteamento pode ter apenas uma regravação associada a ela.

• Condição de reescrita: Esta é uma configuração opcional. Com base nas condições que você definir, o Application Gateway avaliará 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 lógica E. Você pode usar condições de regravação para avaliar o conteúdo de solicitações e respostas HTTP(S). Essa configuração opcional permite que você execute uma regravação somente 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 suportadas

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

• Ação de reescrita: o conjunto de ações de regravação permite reescrever cabeçalhos (solicitação ou resposta) ou os componentes de URL.

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

  • Texto.
  • Valor do cabeçalho da solicitação - Para usar um valor de cabeçalho de solicitação capturado, especifique a sintaxe como {http_req_headerName}.
  • Valor do cabeçalho de resposta - Para usar um valor de cabeçalho de resposta capturado da Condição anterior, especifique a sintaxe como {http_resp_headerName}. Você pode usar {capt_header_value_matcher} quando o valor é capturado do cabeçalho de resposta "Set-Cookie" do Action set. Saiba mais sobre a captura em 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 suportadas.

  Ao usar uma ação para reescrever uma URL, as seguintes operações são suportadas:

  • Caminho da URL: o novo valor a ser definido como o caminho.
  • Cadeia de Caracteres de Consulta de URL: O novo valor para o qual a cadeia de caracteres de consulta deve ser reescrita.
  • Reavaliar mapa de caminho: especifique se o mapa de caminho de URL deve ser reavaliado após a regravação. Se mantido desmarcado, o caminho da URL original será usado para corresponder ao padrão de caminho no mapa de caminho da URL. Se definido como true, o mapa de caminho de 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 regravação.

Correspondência e captura de padrões

A correspondência e a captura de Patten são suportadas em Condição e Ação (em Ação, é suportada apenas para um cabeçalho específico).

Correspondência de padrões

O Application Gateway usa expressões regulares para correspondência de padrões. Você deve usar expressões compatíveis com Expressão Regular 2 (RE2) ao escrever sua sintaxe de correspondência de padrão.

Você pode usar a correspondência de padrões em Condição e Ação.

• Condição: Isso é usado 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 em Conjunto de Ações só está disponível para o cabeçalho de resposta "Set-Cookie". Para corresponder a um padrão para 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, uma correspondência de padrão aqui permite que você procure um cookie específico. Exemplo: Para uma determinada versão do user-agent, você deseja reescrever o cabeçalho de resposta set-cookie para "cookie2" com max-age=3600 (uma hora). Neste caso, pode utilizar
  • Condição - Tipo: Cabeçalho da solicitação, Nome do cabeçalho: user-agent, Padrão a corresponder: *2.0
  • Ação - Tipo de reescrita: Cabeçalho de resposta, Tipo de ação: Conjunto, Nome do cabeçalho: Set-Cookie, Valor do cabeçalho Matcher: cookie2=(.*), Valor do cabeçalho: cookie2={capt_header_value_matcher_1}; Idade-máx=3600

Nota

Se você estiver executando um Application Gateway Web Application Firewall (WAF) com o Core Rule set 3.1 ou anterior, poderá ter problemas ao usar expressões regulares compatíveis com Perl (PCRE) ao fazer asserções lookahead e lookbehind (negativas ou positivas).

Sintaxe para captura

Os padrões também podem ser usados para capturar uma subcadeia de caracteres para uso posterior. Coloque parênteses em torno de um subpadrão na definição de regex. O primeiro par de parênteses armazena sua substring em 1, o segundo par em 2 e assim por diante. Você pode usar quantos parênteses quiser; Perl apenas continua definindo mais variáveis numeradas para você 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-os todos no grupo 1
• (\d)+ # Corresponder um dígito uma ou mais vezes, capturando o último no grupo 1

Uma vez capturados, você pode usá-los no valor do 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_Location_1} ou {http_resp_Location_2}. Enquanto para um cabeçalho de resposta Set-Cookie capturado através da propriedade "HeaderValueMatcher", você deve 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}

Nota

• O uso de / para prefixar e sufixar o padrão não deve ser especificado no padrão para corresponder ao valor. Por exemplo, (\d)(\d) corresponderá a dois dígitos. /(\d)(\d)/ não corresponde a dois dígitos.
• O caso da variável de condição precisa corresponder ao caso da variável de captura. Por exemplo, se minha variável de condição for User-Agent, minha variável de captura deverá ser para User-Agent (ou seja, {http_req_User-Agent_2}). Se minha variável de condição for definida como user-agent, minha variável de captura deverá ser para user-agent (ou seja, {http_req_user-agent_2}).
• Se você quiser usar o valor inteiro, você não deve mencionar o número. Basta usar o formato {http_req_headerName}, etc. sem o groupNumber.

Variáveis de servidor

O Application Gateway 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 mudam dinamicamente, por exemplo, quando uma nova página é carregada ou quando um formulário é postado. Você pode usar essas variáveis para avaliar condições de regravação e reescrever cabeçalhos. Para usar o valor das variáveis de servidor para reescrever cabeçalhos, você precisa especificar essas variáveis na sintaxe {var_serverVariableName}

O gateway de aplicativo suporta as seguintes variáveis de servidor:

Nome da variável	Description
add_x_forwarded_for_proxy	O campo de cabeçalho de solicitação do cliente X-Forwarded-For com a variável (veja a client_ip explicação mais adiante nesta tabela) anexada a ele no formato IP1, IP2, IP3 e assim por diante. Se o campo X-Forwarded-For não estiver no cabeçalho da solicitação do cliente, a add_x_forwarded_for_proxy variável será igual à $client_ip variável. Essa variável é útil quando você deseja reescrever o cabeçalho X-Forwarded-For definido pelo Application Gateway para que o cabeçalho contenha apenas o endereço IP sem as informações da porta.
ciphers_supported	Uma lista das cifras suportadas pelo cliente.
ciphers_used	A cadeia de caracteres de cifras usada para uma conexão TLS estabelecida.
client_ip	O endereço IP do cliente do qual o gateway de aplicativo recebeu a solicitação. Se houver um proxy reverso antes do gateway de aplicativo e do cliente de origem, client_ip retornará o endereço IP do proxy reverso.
client_port	A porta do cliente.
client_tcp_rtt	Informações sobre a conexão TCP do cliente. Disponível em sistemas que suportam a opção de soquete TCP_INFO.
client_user	Quando a autenticação HTTP é usada, o nome de usuário fornecido para autenticação.
host	Nesta ordem de precedência: o nome do host da linha de solicitação, o nome do host do campo Cabeçalho da solicitação do host ou o nome do servidor correspondente a uma solicitação. Exemplo: Na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor do host é contoso.com
cookie_nome	O cookie de nome .
http_method	O método usado para fazer a solicitação de URL. Por exemplo, GET ou POST.
http_status	O status da sessão. Por exemplo, 200, 400 ou 403.
http_version	O protocolo de solicitação. Normalmente, HTTP/1.0, HTTP/1.1 ou HTTP/2.0.
query_string	A lista de pares de variáveis/valores que se segue ao "?" no URL solicitado. Exemplo: Na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, query_string valor é id=123&title=fabrikam
received_bytes	O comprimento da solicitação (incluindo a linha da solicitação, o cabeçalho e o corpo da solicitação).
request_query	Os argumentos na linha de solicitação.
request_scheme	O esquema de solicitação: http ou https.
request_uri	O URI de solicitação original completo (com argumentos). Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, request_uri valor é /article.aspx?id=123&title=fabrikam
sent_bytes	O número de bytes enviados para um cliente.
server_port	A porta do servidor que aceitou uma solicitação.
ssl_connection_protocol	O protocolo de uma conexão TLS estabelecida.
ssl_enabled	"Ligado" se a conexão operar no modo TLS. Caso contrário, uma cadeia de caracteres vazia.
uri_path	Identifica o recurso específico no host que o cliente da Web deseja acessar. A variável refere-se ao caminho da URL original, antes de qualquer manipulação. Esta é a parte do URI de solicitação sem os argumentos. Por exemplo, na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor uri_path é /article.aspx.

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

O Application Gateway oferece suporte às seguintes variáveis de servidor para cenários de autenticação mútua. Use essas variáveis de servidor da mesma maneira que acima com as outras variáveis de servidor.

Nome da variável	Description
client_certificate	O certificado do cliente no formato PEM para uma conexão SSL estabelecida.
client_certificate_end_date	A data final do certificado do cliente.
client_certificate_fingerprint	A impressão digital SHA1 do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_issuer	A cadeia de caracteres "DN do emissor" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_serial	O número de série do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_start_date	A data de início do certificado do cliente.
client_certificate_subject	A cadeia de caracteres "DN do assunto" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_verification	O resultado da verificação do certificado do cliente: SUCCESS, FAILED:<reason> ou NONE se um certificado não estiver presente.

Cenários comuns para reescrita de cabeçalho

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

O Application Gateway insere um cabeçalho X-Forwarded-For em todas as solicitações antes de encaminhar as solicitações para o back-end. Este cabeçalho é uma lista separada por vírgulas de portas IP. Pode haver cenários em que os servidores back-end só precisam dos cabeçalhos para conter endereços IP. Você pode usar a regravação de cabeçalho para remover as 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 um URL de redirecionamento

A modificação de um URL de redirecionamento pode ser útil em determinadas circunstâncias. Por exemplo: os clientes foram originalmente redirecionados para um caminho como "/blog", mas agora devem ser enviados para "/updates" devido a uma mudança na estrutura do conteúdo.

Aviso

A necessidade de modificar uma URL de redirecionamento às vezes surge no contexto de uma configuração pela qual o Application Gateway é configurado para substituir o nome do host em direção ao back-end. O nome do host visto pelo back-end é, nesse caso, diferente do nome do host visto pelo navegador. Nessa situação, o redirecionamento não usaria o nome de host correto. Esta configuração não é recomendada.

As limitações e implicações de tal configuração são descritas em Preservar o nome de host HTTP original entre um proxy reverso e seu aplicativo Web de back-end. A configuração recomendada para o Serviço de Aplicativo é seguir as instruções para "Domínio Personalizado (recomendado)" em Configurar o Serviço de Aplicativo com o Gateway de Aplicativo. Reescrever o cabeçalho do local na resposta, conforme descrito no exemplo abaixo, deve ser considerado uma solução alternativa e não aborda a causa raiz.

Quando o serviço de aplicativo envia uma resposta de redirecionamento, ele usa o mesmo nome de host no cabeçalho do local de sua resposta que o da solicitação que recebe do gateway de aplicativo. Assim, o cliente faz a solicitação diretamente em contoso.azurewebsites.net/path2 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 para o nome de domínio do gateway de aplicativo.

Aqui estão as etapas para substituir o nome do host:

1. Crie uma regra de reescrita com uma condição que avalie se o cabeçalho do 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 de host do gateway de aplicativo. Faça isso inserindo {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 host de servidor 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 Application Gateway para definir esses cabeçalhos para todas as respostas.

Excluir cabeçalhos indesejados

Talvez você queira remover cabeçalhos que revelam informações confidenciais de uma resposta HTTP. Por exemplo, talvez você queira 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 esses 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 para excluir e o cabeçalho definido como host, isso resultará em um erro.

Verificar a presença de um cabeçalho

Você pode avaliar uma solicitação HTTP ou cabeçalho de resposta para a 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 para reconfiguração de URL

Seleção de caminho baseada em parâmetros

Para realizar cenários em que você deseja 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, você pode usar uma combinação de recurso de Regravação de URL e roteamento baseado em caminho.

Para fazer isso, crie um conjunto de regravação com uma condição que verifique um parâmetro específico (cadeia de caracteres de consulta, cabeçalho, etc.) e, em seguida, execute uma ação em que ele altera o caminho da URL (certifique-se de que Reavaliar mapa de caminho esteja habilitado). O conjunto de reescrita deve então ser associado a uma regra baseada em caminho. A regra baseada em caminho deve conter os mesmos caminhos de URL especificados no conjunto de regravação e seu pool de back-end correspondente.

Assim, o conjunto de reescrita permite que os usuários verifiquem um parâmetro específico e atribuam a ele um novo caminho, e a regra baseada em caminho permite que os usuários atribuam pools de back-end a esses caminhos. Desde que a opção "Reavaliar mapa de caminho" esteja ativada, o tráfego será interrompido com base 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 baseada em parâmetros 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 do usuário deve ser simples e legível, mas o servidor de back-end precisa dos parâmetros da cadeia de caracteres de consulta para mostrar o conteúdo correto.

Nesse caso, o Application Gateway pode capturar parâmetros da URL e adicionar pares chave-valor da cadeia de caracteres de consulta daqueles da URL. Por exemplo, digamos que o usuário queira reescrever, https://www.contoso.com/fashion/shirts para https://www.contoso.com/buy.aspx?category=fashion&product=shirts, isso pode ser alcançado através 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 e a buy.aspx cadeia de caracteres de consulta como category={var_uri_path_1}&product={var_uri_path_2}

Para obter um guia passo a passo para alcançar o cenário descrito acima, consulte Reescrever URL com o Gateway de Aplicativo usando o portal do Azure

Reescrever armadilhas comuns de configuração

• Habilitar 'Reavaliar mapa de caminho' não é permitido para regras básicas de roteamento de solicitações. Isso é para evitar loop de avaliação infinito para uma regra de roteamento básica.

• Precisa haver pelo menos 1 regra de reescrita condicional ou 1 regra de reescrita que não tenha 'Reavaliar mapa de caminho' habilitado para regras de roteamento baseadas em caminho para evitar loop de avaliação infinito para uma regra de roteamento baseada em caminho.

• As solicitações de entrada seriam encerradas com um código de erro 500 no caso de um loop ser criado dinamicamente com base nas entradas do cliente. O Application Gateway continua a atender outras solicitações sem qualquer degradação nesse cenário.

Usando a regravação de URL ou a regravação de cabeçalho de host com o Web Application Firewall (WAF_v2 SKU)

Quando você configura a regravação de URL ou a regravação de cabeçalho de host, a avaliação do WAF acontece após a modificação do cabeçalho da solicitação ou dos parâmetros de URL (pós-regravação). E quando você remove a regravação de URL ou a configuração de regravação de cabeçalho de host no Application Gateway, a avaliação do WAF é feita antes da regravação do cabeçalho (pré-regravação). Essa ordem garante que as regras do WAF sejam aplicadas à solicitação final que seria recebida pelo seu pool de back-end.

Por exemplo, digamos que você tenha a seguinte regra de reconfiguração 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 em "image/png".

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

Reescrita de URL vs redirecionamento de URL

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

Para um redirecionamento de URL, o Application Gateway envia uma resposta de redirecionamento para o cliente com a nova URL. Isso, por sua vez, exige que o cliente reenvie sua solicitação para a nova URL fornecida no redirecionamento. O URL que o usuário vê no navegador atualiza para o novo URL.

Limitações

• Não há suporte para regravações quando o gateway de aplicativo é configurado para redirecionar as solicitações ou mostrar uma página de erro personalizada.
• Os nomes dos cabeçalhos de solicitação podem conter caracteres alfanuméricos e hífenes. Os nomes de cabeçalhos que contenham outros caracteres serão descartados quando uma solicitação for enviada para o destino de back-end.
• Os nomes dos cabeçalhos de resposta podem conter caracteres alfanuméricos e símbolos específicos, conforme definido na RFC 7230.
• Os cabeçalhos de conexão e atualização não podem ser reescritos
• Não há suporte para regravações para respostas 4xx e 5xx geradas diretamente do Application Gateway

Próximos passos

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