Como os balanceadores de carga e o relacionamento de IP real arriscam sua segurança?

Uma das vantagens de ser um especialista em segurança é trabalhar com várias equipes. Após uma auditoria, os especialistas em segurança terão a oportunidade de trabalhar com administradores e analistas de banco de dados. Para que um aplicativo funcione de maneira adequada e segura, essas equipes tentam lidar com vulnerabilidades de segurança que têm uma base comum. Os diálogos entre essas equipes levantam alguns problemas com o IP real.

Conceitos de proxy e IP real

Os aplicativos da web de hoje são executados em vários servidores de aplicativos e sistemas de banco de dados. Imagine dois servidores de aplicativos compartilhando o mesmo código-fonte. As solicitações do usuário estão prontas para serem atendidas por qualquer um desses servidores, dependendo da situação de carga. O mecanismo de balanceamento de carga, que lida com solicitações HTTP na frente dos servidores de aplicativos, decide qual solicitação encaminhar para qual servidor de aplicativos. Isso representa uma grande questão para administradores de sistemas de middleware e desenvolvedores de software: qual é o endereço IP real do usuário?

Os proxies são responsáveis ​​pela transmissão de dados entre dois sistemas. O balanceador de carga é o mecanismo responsável pelo proxy. Em outras palavras, apenas um sistema se comunica tanto com o usuário quanto com o servidor de aplicação. Em termos de tráfego de rede, os servidores web A ou web B sempre se comunicam com o endereço IP do balanceador de carga. O mesmo pode ser dito para os usuários. Para profissionais de segurança, balanceadores de carga causam sérios problemas em ataques de injeção de SQL baseados em tempo. Mas o foco principal aqui é a falsificação de IP.

Relacionamento X-Forwarded-For e IP

Considere a relação entre X-Forwarded-For, desenvolvedor e middleware. Por exemplo, digamos que a tarefa do desenvolvedor de um aplicativo seja registrar todas as atividades, como tentativas incorretas de senha dos usuários, com seus endereços IP. A princípio, o desenvolvedor determinará o endereço IP do usuário quando a requisição HTTP for atendida com a oportunidade oferecida pela linguagem de programação que utiliza e tentará continuar utilizando esses dados no aplicativo.

Como seu endereço IP será fixo ao longo do processo de desenvolvimento, ele sempre verá o mesmo endereço durante os testes porque, geralmente, os computadores dos usuários em redes corporativas trabalham com IP estático sobre endereço MAC. A unidade realizará alguns testes de aceitação; no entanto, haverá problemas com eles. A unidade de teste encaminhará esse problema ao desenvolvedor de software.

Nesta fase, o desenvolvedor pode escrever um controller no ambiente de desenvolvimento e ver a requisição HTTP transmitida para a aplicação na forma bruta, já que todos possuem o mesmo endereço IP. Isso resultará no trabalho com X-Forwarded-For.

As informações do cabeçalho chamadas X-Forwarded-For serão enviadas ao servidor de aplicativos. Nesse estágio, o desenvolvedor de software verá seu endereço IP, que ele controla com ipconfig, não o balanceador de carga que ele vê nos logs. Muitos programadores pensam que podem resolver esse problema com um bloco de código como este:

function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode(',', $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: false;
}


Isso não será suficiente – o desenvolvedor precisa verificar se o valor de entrada é um endereço IP válido.

Tudo acima pertencia à parte manipulada pelo desenvolvedor. Mas, para que um aplicativo funcione de maneira adequada e segura, as equipes — trabalhando juntas na teoria, mas na realidade, em pontos extremos — tentam lidar com as vulnerabilidades de segurança que têm uma base comum. Agora tente ver o problema do ponto de vista da pessoa responsável pela configuração do balanceador de carga.

Os administradores do sistema podem pensar que os desenvolvedores registram informações como X-Forwarded-For porque os dados na solicitação HTTP não são confiáveis. Esses administradores geralmente transmitem X-Forwarded-For; no entanto, eles também transmitem o endereço de origem TCP do sistema que enviou a solicitação como um segundo valor de cabeçalho. A estrutura True-Client-IP é um bom exemplo disso.

Quando você coloca tudo isso junto, duas unidades diferentes seguem caminhos diferentes para o mesmo problema, conhecido como falsificação de IP do cliente. O resultado é um problema crítico em que nenhum registro de IP e autorização baseada em IP funcionarão.

Como a falsificação de IP do cliente é detectada nos testes de penetração?

A maioria dos testadores de penetração usa o Firefox para suas verificações de segurança. Eles configuram o Firefox com um complemento simples, X-Forwarded-For: 127.0.0.1 para todas as solicitações HTTP. E assim, aumenta a possibilidade de detectar tais vulnerabilidades em todos os testes de penetração. A realização de uma auditoria de acordo com a lista de verificação OWASP garante a verificação de tais vulnerabilidades. No entanto, para detectar a vulnerabilidade X-Forwarded-For, você precisa de um módulo no aplicativo que mostre seu endereço IP ou as ações realizadas.

Como resolver a vulnerabilidade X-Forwarded-For

As organizações precisam de um documento obrigatório de desenvolvimento de aplicativos seguros para todas as equipes de software e empresas de terceirização. Por exemplo, se você precisa de um endereço IP do usuário, a empresa deve planejar com antecedência e estabelecer uma regra sobre as informações do cabeçalho que usará aqui. Caso contrário, equipes diferentes produzirão soluções diferentes. Se tal situação não puder ser tratada, os aplicativos de terceirização entrarão em jogo, dificultando a medição dos códigos-fonte. Em geral, as empresas não querem seguir esse caminho.

Mas para resolver esse problema, você pode usar a seguinte regra F5:

when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}


Isso remove o campo X-Forwarded-For na solicitação HTTP do mundo externo. Em seguida, ele transmite a solicitação adicionando o endereço IP do sistema que enviou a solicitação a ele. Dessa forma, uma lista confiável é criada para softwares que agem de acordo com o X-Forwarded-For.

Para resumir, o maior objetivo aqui é realizar algumas verificações nas solicitações HTTP e criar um ambiente confiável. O bloco de código acima é um bom exemplo que você pode usar para isso.

Estruturas e documentação de segurança cibernética para empresas

As unidades que parecem independentes umas das outras são, na verdade, partes de um todo. É por isso que tudo tem que funcionar sistematicamente. As regras previamente determinadas devem ser aplicadas entre cada unidade. Se tal sistema de trabalho não for adotado, muitos problemas, como a vulnerabilidade X-Forwarded-For, podem ocorrer. Para isso, tudo deve ser pensado de antemão e a documentação mais completa possível deve ser utilizada.

E cada unidade neste grande sistema precisa adotar e implementar estruturas de segurança cibernética. Seu ponto de partida deve ser pesquisar e aprender a lógica de funcionamento dessas estruturas.