Passa al contenuto principale

6. Security Considerations (Considerazioni sulla sicurezza)

Problemi di limite di dimensione​

La maggior parte dei tipi definiti dai campi strutturati non ha limiti di dimensione; pertanto, campi estremamente grandi possono essere un vettore di attacco (ad esempio, per attacchi di consumo di risorse).

Mitigazione​

La maggior parte delle implementazioni HTTP limita per mitigare tali attacchi:

  • Dimensione dei singoli campi
  • Dimensione dell'intera sezione di intestazione
  • Dimensione dell'intera sezione di coda

Pratiche raccomandate​

Le implementazioni dovrebbero (SHOULD):

  • Impostare limiti di dimensione dei campi ragionevoli
  • Monitorare la dimensione totale delle intestazioni
  • Registrare avvisi per valori di campo insolitamente grandi
  • Considerare di rifiutare richieste/risposte eccessivamente grandi

Attacchi di iniezione di campo​

Una parte in grado di iniettare nuovi campi HTTP può alterare il significato di un campo strutturato.

Rischio​

In alcuni casi, ciò porterà a un fallimento del parsing, ma non può fallire in modo affidabile in tutti i casi.

Strategie di difesa​

  1. Controllo degli accessi rigoroso: Limitare chi può impostare i campi HTTP
  2. Convalida dell'integrità del campo: Utilizzare firme o HMAC
  3. Principio del minimo privilegio: Limitare l'ambito semantico dei campi

Significato di sicurezza della rigorosità del parsing​

Perché il parsing rigoroso è una funzionalità di sicurezza​

Scenario: Valore di campo costruito in modo dannoso

Parser tollerante:
Input: key="value\x00hidden"
Può parsare: key="value" (ignora il contenuto dopo il byte null)
→ I dati nascosti possono aggirare i controlli di sicurezza

Parser rigoroso:
Input: key="value\x00hidden"
Risultato: Fallimento del parsing, ignora l'intero campo
→ Nessuna ambiguità, confini di sicurezza chiari

Vantaggi di sicurezza​

  1. Prevenzione dell'iniezione: La convalida rigorosa previene gli attacchi di iniezione
  2. Eliminazione dell'ambiguità: Tutte le implementazioni si comportano in modo coerente
  3. Fallimento precoce: Scopre problemi ai punti di controllo dei confini
  4. Prevedibilità: Gli attaccanti non possono sfruttare le differenze di parsing

Attacchi di confusione di tipo​

Le implementazioni devono (MUST) eseguire un controllo di tipo rigoroso e non tentare di convertire automaticamente i tipi.

// Controllo di tipo rigoroso corretto
const field = parseItem(fieldValue);
if (field.type !== 'integer') {
return null; // Ignora l'intero campo
}

Esempi di attacchi di consumo di risorse​

Attacco 1: Lista estremamente lunga​

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

Difesa:

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

Attacco 2: Stringhe estremamente lunghe​

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

Difesa: Limitare la lunghezza delle stringhe a un valore ragionevole (ad es. 8192 caratteri).


Inquinamento dei parametri​

Le chiavi dei parametri devono (MUST) essere univoche nel loro ambito. Le chiavi duplicate causano un fallimento del parsing.

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

Lista di controllo della sicurezza​

Quando si implementano campi strutturati, assicurarsi di:

  • Limitare la dimensione dei campi
  • Limitare il numero di membri List/Dictionary
  • Limitare la lunghezza di String/Token
  • Limitare la dimensione di Byte Sequence
  • Convalidare rigorosamente tutti i tipi
  • Rifiutare le chiavi duplicate
  • Registrare gli input anomali
  • Testare i casi limite
  • Non tentare di "riparare" gli input errati
  • Ignorare l'intero campo in caso di fallimento

Punti chiave​

  1. Limiti di dimensione: Le implementazioni devono (MUST) limitare la dimensione dei campi
  2. Rischio di iniezione: L'iniezione di campi può alterare la semantica
  3. Parsing rigoroso: La rigorosità è una funzionalità di sicurezza
  4. Sicurezza dei tipi: Il controllo di tipo rigoroso previene attacchi di confusione
  5. Responsabilità dell'implementazione: Aggiungere limiti di sicurezza ragionevoli
  6. Difesa in profondità: Combinare più meccanismi di sicurezza