In che modo i sistemi di bilanciamento del carico e la relazione IP reale mettono a rischio la tua sicurezza?

Uno dei vantaggi di essere uno specialista della sicurezza è lavorare con numerosi team. Dopo un audit, gli specialisti della sicurezza avranno l’opportunità di lavorare con gli amministratori e gli analisti del database. Affinché un’applicazione funzioni correttamente e in modo sicuro, questi team cercano di affrontare le vulnerabilità di sicurezza che hanno una base comune. I dialoghi tra questi team sollevano alcuni problemi con la proprietà intellettuale reale.

Concetti di proxy e IP reale

Le odierne applicazioni Web vengono eseguite su più server di app e sistemi di database. Immagina due server delle applicazioni che condividono lo stesso codice sorgente. Le richieste dell’utente sono pronte per essere soddisfatte da uno di questi server a seconda della situazione di carico. Il meccanismo di bilanciamento del carico, che gestisce le richieste HTTP davanti ai server delle applicazioni, decide quale richiesta inoltrare a quale server delle applicazioni. Ciò pone una grande domanda per gli amministratori di sistema middleware e gli sviluppatori di software: qual è il vero indirizzo IP dell’utente?

I proxy sono incaricati di trasmettere i dati tra due sistemi. Il bilanciamento del carico è il meccanismo responsabile del proxy. In altre parole, un solo sistema comunica sia con l’utente che con l’application server. In termini di traffico di rete, i server Web A o Web B comunicano sempre con l’indirizzo IP del sistema di bilanciamento del carico. Lo stesso si può dire per gli utenti. Per i professionisti della sicurezza, i sistemi di bilanciamento del carico causano seri problemi negli attacchi SQL injection basati sul tempo. Ma l’obiettivo principale qui è lo spoofing IP.

X-Forwarded-For e relazione IP

Considera la relazione tra X-Forwarded-For, sviluppatore e middleware. Ad esempio, supponiamo che il compito dello sviluppatore di un’applicazione sia quello di registrare tutte le attività, come i tentativi di password errati da parte degli utenti, con i loro indirizzi IP. Inizialmente, lo sviluppatore determinerà l’indirizzo IP dell’utente quando la richiesta HTTP viene soddisfatta con l’opportunità fornita dal linguaggio di programmazione che utilizza e proverà a continuare a utilizzare questi dati nell’applicazione.

Poiché il suo indirizzo IP verrà fissato durante tutto il processo di sviluppo, vedrà sempre lo stesso indirizzo durante i test perché generalmente i computer degli utenti nelle reti aziendali funzionano con IP statico su indirizzo MAC. L’unità eseguirà alcuni test di accettazione; tuttavia, ci saranno problemi con questi. L’unità di test inoltrerà questo problema allo sviluppatore del software.

In questa fase, lo sviluppatore può scrivere un controller nell’ambiente di sviluppo e vedere la richiesta HTTP trasmessa all’applicazione in forma non elaborata, poiché tutti hanno lo stesso indirizzo IP. Ciò si tradurrà nel lavorare con X-Forwarded-For.

Le informazioni di intestazione denominate X-Forwarded-For verranno inviate al server delle applicazioni. In questa fase, lo sviluppatore del software vedrà il proprio indirizzo IP, che controlla con ipconfig, non il bilanciamento del carico che vede nei log. Molti programmatori pensano di poter risolvere questo problema con un blocco di codice come questo:

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;
}


Questo non sarà sufficiente: lo sviluppatore deve verificare se il valore in entrata è un indirizzo IP valido.

Tutto quanto sopra apparteneva alla parte gestita dallo sviluppatore. Ma affinché un’applicazione funzioni correttamente e in modo sicuro, i team, che lavorano insieme in teoria, ma in realtà, a punti estremi l’uno dall’altro, cercano di affrontare le vulnerabilità di sicurezza che hanno una base comune. Ora prova a esaminare il problema dal punto di vista della persona responsabile della configurazione del bilanciamento del carico.

Gli amministratori di sistema potrebbero pensare che gli sviluppatori registrino informazioni come X-Forwarded-For perché i dati nella richiesta HTTP non possono essere considerati attendibili. Questi amministratori spesso trasmettono X-Forwarded-For; tuttavia, trasmettono anche l’indirizzo sorgente TCP del sistema che ha inviato la richiesta come secondo valore di intestazione. La struttura True-Client-IP ne è un buon esempio.

Quando metti insieme tutte queste cose, due unità diverse seguono percorsi diversi per lo stesso problema, noto come spoofing IP del client. Il risultato è un problema critico in cui non funzionerà alcuna registrazione IP e autorizzazione basata su IP.

Come viene rilevato lo spoofing IP del client nei test di penetrazione?

La maggior parte dei penetration tester utilizza Firefox per i controlli di sicurezza. Configurano Firefox con un semplice componente aggiuntivo, X-Forwarded-For: 127.0.0.1 per tutte le richieste HTTP. E così, aumenta la possibilità di rilevare tali vulnerabilità in tutti i penetration test. L’esecuzione di un audit in base alla lista di controllo OWASP garantisce la verifica di tali vulnerabilità. Tuttavia, per rilevare la vulnerabilità X-Forwarded-For, è necessario un modulo nell’applicazione che mostri il tuo indirizzo IP o le azioni intraprese.

Come risolvere la vulnerabilità X-Forwarded-For

Le organizzazioni hanno bisogno di un documento obbligatorio per lo sviluppo di applicazioni sicure per tutti i team software e le società di outsourcing. Ad esempio, se hai bisogno di un indirizzo IP utente, l’azienda dovrebbe pianificare in anticipo e stabilire una regola sulle informazioni di intestazione che utilizzerà qui. Altrimenti, team diversi produrranno soluzioni diverse. Se una tale situazione non può essere affrontata, entreranno in gioco le applicazioni di outsourcing, rendendo difficile la misurazione dei codici sorgente. In generale, le aziende non vogliono seguire un percorso del genere.

Ma per risolvere questo problema, puoi usare la seguente regola F5:

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


Questo rimuove il campo X-Forwarded-For nella richiesta HTTP dal mondo esterno. Quindi trasmette la richiesta aggiungendo l’indirizzo IP del sistema che gli ha inviato la richiesta. In questo modo, viene creato un elenco affidabile per il software che agisce secondo X-Forwarded-For.

Per riassumere, l’obiettivo principale qui è eseguire alcuni controlli sulle richieste HTTP e creare un ambiente affidabile. Il blocco di codice sopra è un buon esempio che puoi usare per questo.

Framework e documentazione sulla sicurezza informatica per le imprese

Le unità che sembrano essere indipendenti l’una dall’altra sono in realtà parti di un tutto. Ecco perché tutto deve funzionare sistematicamente. Le regole stabilite in precedenza devono essere applicate tra ciascuna unità. Se un tale sistema di lavoro non viene adottato, possono verificarsi molti problemi come la vulnerabilità X-Forwarded-For. Per questo, tutto dovrebbe essere considerato in anticipo e dovrebbe essere utilizzata la documentazione più completa possibile.

E ogni unità in questo grande sistema deve adottare e implementare framework di sicurezza informatica. Il tuo punto di partenza dovrebbe essere quello di ricercare e apprendere la logica di funzionamento di questi framework.