IP-Adresse aus einem Header vertraut

Nahezu jede Anwendung läuft heute hinter einem Lastverteiler, einem Reverse Proxy oder einem CDN. Dadurch sieht die Anwendung nicht mehr die Adresse des Besuchers, sondern die des Proxys, und die echte Adresse wird in einem Header mitgesendet. Diese Lösung funktioniert, bis jemand diesen Header selbst ausfüllt. Die Kunst besteht darin zu unterscheiden, wer ihn gesetzt hat.

Warum ist der Header nicht vertrauenswürdig?

Leitet ein Proxy eine Anfrage weiter, fügt er die Adresse des ursprünglichen Besuchers einem Header hinzu, meist X-Forwarded-For. Die Anwendung liest diesen Wert und weiß so, von wem die Anfrage kam. So ist es gedacht.

Der Punkt ist, dass ein Header Bestandteil der Anfrage ist. Ein Client kann ihn selbst mitsenden, und ein Proxy, der einen vorhandenen Wert antrifft, hängt meist seine eigenen Angaben an, statt ihn zu ersetzen. Der Header ist also eine Liste, deren Anfang der Client bestimmt hat und deren Ende Ihre eigene Infrastruktur.

Von einer aus einem Header vertrauten IP-Adresse spricht man, wenn eine Anwendung den ersten Wert dieser Liste nimmt oder den gesamten Wert unbesehen übernimmt, ohne zu wissen, welcher Teil von ihrem eigenen Proxy stammt. Vergleichen Sie es mit einem Paket, auf dem mehrere Absender gestempelt sind: dem des Verteilzentrums können Sie vertrauen, dem, den der Versender selbst daraufgeschrieben hat, nicht. Wer den obersten liest, liest das, was der Versender ihn lesen lassen wollte.

Wie missbraucht ein Angreifer X-Forwarded-For?

Verwundbar:

function ipVon(req) {
  // Der erste Wert: genau der, den der Client selbst bestimmen kann
  const kette = req.headers['x-forwarded-for'];
  return kette ? kette.split(',')[0].trim() : req.socket.remoteAddress;
}

app.post('/anmelden', async (req, res) => {
  const ip = ipVon(req);
  if (await zuVieleVersuche(ip)) return res.status(429).send('Zu viele Versuche');
  // ...
});

// Und eine Zugriffsregel auf Grundlage derselben Adresse
app.use('/verwaltung', (req, res, next) => {
  if (ipVon(req).startsWith('10.0.')) return next();     // "intern"
  res.sendStatus(403);
});

Zwei Maßnahmen, die beide auf derselben unzuverlässigen Quelle ruhen. Der Angreifer sendet schlicht selbst einen Header mit:

POST /anmelden HTTP/1.1
X-Forwarded-For: 203.0.113.7

Bei jedem Versuch eine andere Adresse, und die Ratenbegrenzung zählt nie über eins hinaus. Ein Passwortangriff, der nach fünf Versuchen hätte enden sollen, läuft ungehindert weiter. Und die Zugriffsregel für die Verwaltungsoberfläche ist noch unmittelbarer umgangen:

GET /verwaltung/nutzer HTTP/1.1
X-Forwarded-For: 10.0.4.12

HTTP/1.1 200 OK

Der Angreifer hat sich selbst zum internen System erklärt, und die Anwendung glaubt ihm.

Sicher:

// Die Zahl der Proxys vor der Anwendung ist bekannt und fest
app.set('trust proxy', 2);      // etwa: CDN plus eigener Lastverteiler

app.post('/anmelden', async (req, res) => {
  const ip = req.ip;            // zählt vom Ende der Liste zurück
  if (await zuVieleVersuche(ip)) return res.status(429).send('Zu viele Versuche');
  // ...
});

# Und der Proxy überschreibt, was der Client mitgesendet hat
location / {
    proxy_set_header X-Forwarded-For $remote_addr;   # ersetzen, nicht anhängen
    proxy_set_header X-Real-IP       $remote_addr;
    proxy_pass http://anwendung;
}

Die Anwendung zählt nun vom Ende der Liste die bekannte Zahl vertrauenswürdiger Proxys zurück und nimmt damit genau den Wert, den ihre eigene Infrastruktur hinzugefügt hat. Und der Proxy ersetzt den Header, statt ihn zu ergänzen, sodass das, was der Client mitgesendet hat, vollständig verschwindet.

Für die Zugriffsregel an der Verwaltungsoberfläche gilt zudem: Eine IP-Adresse ist ein Hinweis, kein Identitätsnachweis. Verwenden Sie sie allenfalls als ergänzende Bedingung zusätzlich zu echter Authentifizierung und Autorisierung.

Welche Auswirkungen hat ein vertrauter IP-Header?

Der Schweregrad reicht von mittel bis hoch, abhängig davon, wofür die Adresse verwendet wird. Dient sie nur der Statistik, bleibt der Schaden bei verfälschten Zahlen. Sobald Sicherheitsentscheidungen darauf ruhen, wird es ernst.

Die häufigsten Folgen sind das Umgehen von Ratenbegrenzungen und Sperren. Ein Angreifer, der seine Adresse je Anfrage wechselt, kann unbegrenzt Passwörter ausprobieren, Codes erraten oder Daten abrufen, ohne je an ein Limit zu stoßen. Die Maßnahme besteht, zählt aber nie durch.

Schwerwiegender ist das Umgehen von Zugriffsregeln. Systeme, die eine Verwaltungsoberfläche, eine Überwachungsseite oder eine interne API anhand eines IP-Bereichs abschirmen, geben diesen Zugang an jeden weiter, der den passenden Header mitsendet. Das ist ein unmittelbarer Weg zu Funktionen, die als abgeschirmt galten.

Schließlich gibt es die Protokollseite. Wird die Adresse aus einem unzuverlässigen Header festgehalten, kann ein Angreifer seine Spuren auf eine beliebige andere Adresse zeigen lassen. Bei einer Untersuchung eines Vorfalls führt das zur falschen Schlussfolgerung und mitunter zu einem unbeteiligten Dritten.

Wie spürt man einen vertrauten IP-Header auf?

Ein Tester sendet Anfragen mit einem selbst gewählten X-Forwarded-For und beobachtet, ob sich die Anwendung anders verhält: Wird die Ratenbegrenzung neu gezählt, ändert sich die Adresse in einer Rückmeldung oder Protokollzeile, oder wird eine abgeschirmte Route plötzlich zugänglich?

Zusätzlich werden die Varianten ausprobiert. Neben X-Forwarded-For gibt es X-Real-IP, X-Client-IP, X-Originating-IP, Forwarded und True-Client-IP; Anwendungen sehen häufig auf mehrere davon und vertrauen mitunter einem, den der Proxy überhaupt nicht setzt. Ebenso wird geprüft, was bei mehreren Werten in der Liste und bei einem erfundenen Wert an vorderster Stelle geschieht. Ferner wird betrachtet, ob der Proxy den Header ersetzt oder ergänzt und ob die Anwendung die richtige Zahl von Proxys verwendet. AssistSec widmet Zugriffsregeln, die auf einem IP-Bereich ruhen, besondere Aufmerksamkeit, denn dort liegt der Unterschied zwischen einem umgangenen Limit und einer umgangenen Autorisierung.

Wie verhindert man einen vertrauten IP-Header?

• Konfigurieren Sie Ihre Anwendung mit der genauen Zahl vertrauenswürdiger Proxys, die davorstehen.
• Lassen Sie Ihren eigenen Proxy den Weiterleitungsheader ersetzen, statt ihn zu ergänzen.
• Nehmen Sie nie den ersten Wert der Liste; zählen Sie vom Ende zurück.
• Ignorieren Sie den Header vollständig, wenn Ihre Anwendung unmittelbar am Internet hängt.
• Verwenden Sie eine IP-Adresse nie als alleinige Grundlage für Zugriff; sie ist ein Hinweis, keine Identität.
• Begrenzen Sie den Zugang zu internen Funktionen mit Netzwerksegmentierung, einem VPN oder gegenseitiger Authentifizierung.
• Achten Sie auf die alternativen Header, die Ihr Framework möglicherweise berücksichtigt.
• Stützen Sie Ratenbegrenzungen nach Möglichkeit auf das Konto und auf die IP-Adresse nur bei anonymen Anfragen.
• Halten Sie in Ihren Protokolldateien fest, welcher Wert verwendet wurde und woher er stammte.