existe um padrão para encadear cabeçalhos x-forwarded-for?

Question

IETF RFC 2616 Seção 4.2 permite que uma solicitação contenha vários cabeçalhos com o mesmo nome de campo, desde que a ordem cronológica de inserção seja preservada e seus valores possam ser convertidos em cabeçalho único com uma lista de valores separados por vírgula.

link

message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. F5 will not overwrite any existing X-Forwarded-For. Nor will it concatenate existing X-Forwarded-For into a single comma-separated value. Instead, it will insert an additional X-Forwarded-For at the tail end of the collection.

Mas e um ambiente com vários clientes, proxies, CDNs, gerentes de tráfego, servidores envolvidos na manipulação da coleção X-Forwarded-For ?

Parece haver uma vantagem em impor uma prática uniforme. Mas qual é a melhor prática?

O cabeçalho de inserção do perfil HTTP padrão F5 BIG-IP acumula X-Forwarded-For adicional no final da coleção pré-existente de cabeçalhos XFF de uma solicitação, preservando a ordem.

O AWS ELB incentiva a consolidação de múltiplos X-Forwarded-For de uma solicitação recebida em um único cabeçalho contendo uma lista delimitada por vírgulas de IPs XFF, mais o endereço do host do usuário, preservando a ordem.

Outros dispositivos podem empregar outras variações.

Existe uma recomendação acordada ou um padrão de fato para ambientes heterogêneos?

Além disso, são fornecidos quaisquer dados de registro de data e hora que permitiriam que o código classifique definitivamente X-Forwarded-For cabeçalhos em ordem cronológica de adição para o caso em que as manipulações anteriores de cabeçalhos XFF são suspeitas.

    

Answer 1

Sim, há um padrão: não use o X-Forwarded-For.

RFC 7239 define o cabeçalho Forwarded, que tem uma semântica bastante diferente de X-Forwarded-For, e novas implementações devem para usá-lo. Infelizmente ele sofre do mesmo problema que você identificou com o X-Forwarded-Por: aqui ele pode ser definido duas vezes em uma solicitação ou conter uma lista de valores separados por vírgulas. Proxies também podem deletá-lo totalmente.

E sim, há uma prática recomendada: usar um nome de cabeçalho diferente internamente.

Lembre-se de que o X-Forwarded-For e o seu substituto Forwarded contêm entrada não confiável . É trivial para um cliente colocar o que quiser nesse cabeçalho. Se você realmente precisa saber o endereço IP público do que estiver conectado ao seu servidor, coloque-o em um cabeçalho diferente. Por exemplo, a CloudFlare usa o CF-Connecting-IP para essa finalidade. Eu também vi o Client-IP e o X-Real-IP usados no nginx (onde você pode definir o que quiser). Seja qual for o nome usado, seus balanceadores de carga devem enviar o endereço IP do solicitante em algum cabeçalho diferente de X-Forwarded-For ou Forwarded.