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

O Gateway de Aplicativo permite que você reescreva o conteúdo selecionado de solicitações e respostas. Com esse recurso, você pode traduzir URLs, parâmetros de cadeia de caracteres de consulta e modificar cabeçalhos de solicitação e resposta. Ele também permite adicionar condições para garantir que o URL ou os cabeçalhos especificados sejam reescritos apenas 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 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 podem 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 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 de 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, consulte aqui.

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

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

• Associação da regra de roteamento da solicitação: a configuração da reescrita está associada ao ouvinte de origem por meio da regra de roteamento. Quando você usa uma regra de roteamento do tipo Básico, a configuração de reescrita é associada ao ouvinte e funciona como uma reescrita global. Quando você usa uma regra de roteamento com base em caminho, a configuração de reescrita é definida de acordo com o mapa de caminho da 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: é uma configuração opcional. Com base nas condições definidas, o Gateway de Aplicativo 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 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 que você avalie se existe uma variável ou cabeçalho especificado, correspondendo os valores deles por meio de texto ou 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.

• Ação de Reescrita: 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. Esse campo opcional permite que você corresponda, assim como capture o valor de um cabeçalho específico quando existirem 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 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 compatíveis.

Ao usar uma Ação para reescrever uma URL, há suporte para as seguintes operações:

• Caminho da URL: o novo valor a 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 mantido desmarcado, o caminho da URL original será usado para corresponder ao padrão do caminho no mapa do caminho da URL. Se definido como verdadeiro, 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

Há suporte para correspondência e captura de padrão em Condição e Ação (em Ação, ele tem suporte 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. Você deve usar expressões compatíveis com RE2 (Expressão Regular 2) ao escrever sua sintaxe de padrões correspondentes.

Você pode usar padrões correspondentes em Condição e também em 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 "Conditions", use a propriedade "pattern".
• Ação: os padrões correspondentes 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ões aqui permite que você procure um cookie específico. Exemplo: para uma determinada versão do usuário-agente, você deseja reescrever o cabeçalho de resposta set-cookie 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={capt_header_value_matcher_1}; Max-Age=3600

Sintaxe para captura

Os padrões também podem ser usados para capturar uma sub-cadeia 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; o Perl continua definindo mais variáveis ​​numeradas para você representar essas cadeias de caracteres capturadas. Você pode encontrar alguns exemplos nestas diretrizes de programação em 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 da mesma maneira que acima com as 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

A modificação de uma 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 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 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 do 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 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 de 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 obter cenários em que você escolhe 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 capacidade de reescrita de URL e roteamento baseado em caminho.

Para fazer isso, 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, execute uma ação em que isso altera o caminho da URL (verifique se Reavaliar o mapa do caminho está habilitado). Em seguida, o conjunto de reescrita deve ser associado 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 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. Se "Reavaliar o mapa do caminho" estiver habilitado, o tráfego será roteado 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 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 no qual o link visível ao usuário deve ser simples e legível, mas o servidor back-end precisa dos parâmetros da cadeia de caracteres de consulta para mostrar o conteúdo correto.

Nesse caso, o Gateway de Aplicativo pode capturar parâmetros da URL e adicionar pares chave-valor de cadeia de caracteres de consulta a partir daqueles da URL. Por exemplo, digamos que o usuário deseja reescrever, https://www.contoso.com/fashion/shirts para https://www.contoso.com/buy.aspx?category=fashion&product=shirts. Isso pode ser feito por meio da configuração de reescrita de URL a seguir.

Condição - Se a variável de servidor uri_path 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 obter um guia passo a passo para obter o cenário descrito acima, consulte Reescrever URL com o Gateway de Aplicativo usando o portal do Azure

Reescrever as armadilhas comuns da configuração

• Não é permitido habilitar a opção "Reavaliar o mapa do caminho" para as regras básicas de roteamento de solicitações. Isso evita um loop infinito de avaliação para uma regra básica de roteamento.

• Deve haver, pelo menos, uma regra de reescrita condicional ou uma regra de reescrita sem a opção "Reavaliar mapa do caminho" habilitada para as regras de roteamento baseadas em caminho. Isso evita um loop infinito de avaliação para uma regra de roteamento baseada em caminho.

• As solicitações de entrada seriam encerradas com um código de erro 500 caso um loop fosse criado dinamicamente com base nas entradas do cliente. O Gateway de Aplicativo continuará a atender outras solicitações sem degradações nesse 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). E quando você remover a configuração da reescrita de URL ou do cabeçalho de host no seu Gateway de Aplicativo, o WAF fará a avaliação antes da reescrita do cabeçalho (pré-reescrita). 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 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".

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

Reescrita de URL versus Redirecionamento de URL

No caso da reescrita de URL, o Gateway de Aplicativo reescreve a URL antes que a solicitação seja enviada ao back-end. Isso não vai alterar o que os usuários veem no navegador, pois as alterações ficam 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. Isso, por sua vez, exige que o cliente reenvie 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 de cabeçalho de solicitação podem conter caracteres alfanuméricos e hifens. Os nomes de cabeçalhos que contiverem outros caracteres serão descartados quando uma solicitação for enviada para o destino de back-end.
• Os nomes de cabeçalhos podem conter qualquer caractere alfanumérico e símbolos específicos, conforme definido no RFC 7230.
• Os cabeçalhos de conexão e atualização não podem ser reescritos
• 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