Timing‑Attacken in PHP: Ein praktisches Beispiel — warum `hash_equals()` zählt

Viele Entwickler vertrauen auf den einfachen Vergleich mittels === oder ==, wenn sie API‑Keys, Tokens oder andere geheime Strings prüfen. Auf den ersten Blick sieht das vernünftig aus — die Sache hat aber einen Haken: zeitliche Unterschiede beim Vergleich können von Angreifern ausgenutzt werden.

Dieser Beitrag beschreibt ein realistisches Beispiel wie eine Timing‑Attacke konzeptionell abläuft.

Das reale Szenario (vereinfachtes Beispiel)

Stell dir vor, ein interner Microservice akzeptiert Anfragen mit einem Query‑Parameter token und vergleicht diesen gegen einen in der Umgebung gespeicherten GitHub‑API‑Token.

Unsicherer Code (vereinfacht):

// unsicher.php (vereinfachtes Beispiel)
$expected = getenv('GITHUB_API_TOKEN');

// z. B. 'V1cHt2S67DADJIm9sX9yzCc272EkSC'
$provided = $_GET['token'] ?? '';
if ($provided === $expected) {
    // Zugriff gewähren
}
                              PHP
                            

Warum das problematisch ist, erkläre ich im nächsten Abschnitt.

Wie funktioniert eine Timing‑Attacke?

Wenn die Implementierung des Token-Vergleichs Zeichen‑für‑Zeichen vergleicht und beim ersten Fehler sofort abbricht, dann dauert eine Anfrage mit dem richtigen ersten Zeichen im Mittel etwas länger.

Ein korrektes erstes Zeichen führt also im Mittel zu einer minimal längeren Verarbeitungszeit als ein falsches erstes Zeichen. Das gleiche gilt für das zweite Zeichen usw.

Ein Angreifer macht sich das zunutze, indem er für jede Position alle möglichen Zeichen testet, die Antwortzeiten sehr oft misst und statistisch auswertet. Das Zeichen mit der jeweils größten mittleren/verhältnismäßig längeren Zeit ist wahrscheinlich korrekt. So wird das Token Schritt für Schritt rekonstruiert.

Warum hash_equals() die richtige Wahl ist

PHP liefert mit hash_equals() eine konstante‑zeit‑Stringvergleichsfunktion (constant‑time comparison). Sie stellt sicher, dass die Ausführungszeit des Vergleichs nicht von gemeinsamen Präfixen abhängt — solange beide Strings gleich lang sind.

Sichere Alternative (für Laravel, PHP, Wordpress):

// sicher.php
$expected = getenv('GITHUB_API_TOKEN');
$provided = $_GET['token'] ?? '';
if (hash_equals($expected, $provided)) {
    // Zugriff gewähren
}
                              PHP
                            

Hinweis: hash_equals() ist nur "zeitunabhängig" wenn die Längen gleich sind. Es ist gute Praxis, Tokens so zu gestalten, dass die Länge konstant ist (z. B. HMACs, UUIDs fester Länge oder zufällige Base64-Zeichenketten mit fester Länge).

Hast du gewusst? Nur UUID-V4 ist komplett zufällig erzeugt und wird deshalb häufig für Security Tokens genutzt. Weil sie keine zeit- oder gerätebezogenen Informationen enthält, bietet sie eine hohe Unvorhersagbarkeit und schützt so vor Angriffen, die auf Muster oder Vorhersagen basieren. Genau deshalb ist UUID-V4 die bevorzugte Wahl, wenn es um sichere, schwer zu erratende Identifikatoren geht.

Zusätzliche Abwehrmassnahmen — mehr als nur hash_equals()

1. Konstante Token‑Länge
   Verwende Tokens mit fester Länge, z.B. UUID-V4. Wenn ein Angreifer die Länge errät, ist das weniger hilfreich, solange die Zeichen selbst sicher sind.
2. Rate‑Limiting
   Beschränke Anfragen pro IP oder pro Account. Timing‑Angriffe benötigen viele Messungen; Rate‑Limiting erhöht Aufwand und Kosten für den Angreifer erheblich.
3. Logging und Monitoring
   Erkenne ungewöhnliche Muster (viele Token‑Versuche, systematische Variation an bestimmten Parametern) und reagiere automatisiert.
4. Salt / HMAC / Signaturen
   Verwende signierte Tokens (HMAC mit geheimer Schlüssel) oder OAuth‑Tokens, statt rohe statische Keys offen zu vergleichen.
5. TLS/HTTPS
   Verschlüsselung schützt die Kommunikationskanäle — sie verhindert zwar keine Timing‑Attacken auf Serverinternas, ist aber Grundvoraussetzung.
6. Token‑Rotation
   Geringe Lebensdauer für Tokens reduziert Nutzen eines kompromittierten Tokens.

Fazit

Timing‑Attacken sind kein rein theoretisches Problem — sie wurden in der Praxis untersucht und können, besonders bei öffentlich erreichbaren Endpunkten, ernsthafte Folgen haben. Die gute Nachricht: Für PHP/Laravel/Wordpress‑Entwickler ist die erste Gegenmassnahme denkbar einfach:

• Ersetze direkte Vergleiche sensibler Strings durch hash_equals().
• Sorge für konstante Token‑Längen, Rate‑Limiting, Logging und sichere Token‑Verwaltung.