Zum Hauptinhalt springen

6. Security Considerations (Sicherheitsüberlegungen)

Größenbeschränkungsprobleme​

Die meisten von strukturierten Feldern definierten Typen haben keine Größenbeschränkung; daher können extrem große Felder ein Angriffsvektor sein (z.B. für Ressourcenverbrauchsangriffe).

Abhilfemaßnahmen​

Die meisten HTTP-Implementierungen begrenzen zur Abwehr solcher Angriffe:

  • Größe einzelner Felder
  • Größe des gesamten Header-Abschnitts
  • Größe des gesamten Trailer-Abschnitts

Empfohlene Praktiken​

Implementierungen sollten (SHOULD):

  • Vernünftige Feldgrößenbeschränkungen festlegen
  • Gesamtkopfzeilengröße überwachen
  • Warnungen für ungewöhnlich große Feldwerte protokollieren
  • Übermäßig große Anfragen/Antworten ablehnen erwägen

Feldinjektionsangriffe​

Eine Partei, die neue HTTP-Felder injizieren kann, kann die Bedeutung eines strukturierten Felds ändern.

Risiko​

In einigen Fällen führt dies zu einem Parse-Fehler, kann aber nicht in allen Fällen zuverlässig fehlschlagen.

Verteidigungsstrategien​

  1. Strenge Zugriffskontrolle: Beschränken, wer HTTP-Felder setzen kann
  2. Feldintegritätsvalidierung: Signaturen oder HMAC verwenden
  3. Prinzip der geringsten Privilegien: Semantische Auswirkungen von Feldern beschränken

Sicherheitsbedeutung der Parse-Strenge​

Warum striktes Parsing eine Sicherheitsfunktion ist​

Szenario: Bösartig konstruierter Feldwert

Toleranter Parser:
Input: key="value\x00hidden"
Kann parsen: key="value"  (ignoriert Inhalt nach Null-Byte)
→ Versteckte Daten können Sicherheitsprüfungen umgehen

Strikter Parser:
Input: key="value\x00hidden"
Ergebnis: Parse-Fehler, ignoriert gesamtes Feld
→ Keine Mehrdeutigkeit, klare Sicherheitsgrenzen

Sicherheitsvorteile​

  1. Injektionsverhinderung: Strikte Validierung verhindert Injektionsangriffe
  2. Mehrdeutigkeitseliminierung: Alle Implementierungen verhalten sich konsistent
  3. Frühes Versagen: Entdeckt Probleme an Grenzprüfpunkten
  4. Vorhersagbarkeit: Angreifer können Parse-Unterschiede nicht ausnutzen

Typverwechslungsangriffe​

Implementierungen müssen (MUST) strikte Typprüfung durchführen und nicht versuchen, Typen automatisch zu konvertieren.

// Korrekte strikte Typprüfung
const field = parseItem(fieldValue);
if (field.type !== 'integer') {
  return null;  // Gesamtes Feld ignorieren
}

Beispiele für Ressourcenverbrauchsangriffe​

Angriff 1: Extrem lange Liste​

Example-List: 1, 2, 3, ..., 100000  # 100.000 Mitglieder

Verteidigung:

const MAX_LIST_SIZE = 1024;  // RFC-Mindestanforderung
if (list.length > MAX_LIST_SIZE) {
  throw new Error('List too large');
}

Angriff 2: Extrem lange Strings​

Example-String: "AAAA...AAAA"  (100MB)

Verteidigung: String-Länge auf vernünftigen Wert begrenzen (z.B. 8192 Zeichen).

Parameterverschmutzung​

Parameterschlüssel müssen (MUST) in ihrem Geltungsbereich eindeutig sein. Doppelte Schlüssel verursachen Parse-Fehler.

const params = new Map();
for (const [key, value] of parsedParams) {
  if (params.has(key)) {
    throw new Error('Duplicate parameter key');
  }
  params.set(key, value);
}

Sicherheitscheckliste​

Bei der Implementierung strukturierter Felder sicherstellen:

  • Feldgröße begrenzen
  • Anzahl der List/Dictionary-Mitglieder begrenzen
  • String/Token-Länge begrenzen
  • Byte-Sequence-Größe begrenzen
  • Alle Typen strikt validieren
  • Doppelte Schlüssel ablehnen
  • Abnormale Eingaben protokollieren
  • Grenzfälle testen
  • Nicht versuchen, fehlerhafte Eingaben zu "reparieren"
  • Bei Fehler gesamtes Feld ignorieren

Wichtige Punkte​

  1. Größenbeschränkungen: Implementierungen müssen (MUST) Feldgröße begrenzen
  2. Injektionsrisiko: Feldinjektionen können Semantik ändern
  3. Striktes Parsing: Strenge ist eine Sicherheitsfunktion
  4. Typsicherheit: Strikte Typprüfung verhindert Verwechslungsangriffe
  5. Implementierungsverantwortung: Vernünftige Sicherheitsbeschränkungen hinzufügen
  6. Tiefenverteidigung: Mehrere Sicherheitsmechanismen kombinieren
Letztes Update am