8. Security Considerations (Considerazioni sulla sicurezza)

8. Security Considerations (Considerazioni sulla sicurezza)

Sebbene tecnicamente al di fuori dell'ambito di questa specifica, la Sezione 10 ("Considerazioni sulla sicurezza" (Security Considerations)) di RFC 3629 [STD63] si applica alle implementazioni. È necessario prestare particolare attenzione all'ultimo paragrafo della Sezione 3 ("Definizione UTF-8" (UTF-8 definition)) di RFC 3629 [STD63]. Un'implementazione I-Regexp potrebbe dover mitigare le limitazioni dell'implementazione della piattaforma a questo riguardo.

Come discusso nella Sezione 6, le librerie di espressioni regolari più complesse possono contenere bug sfruttabili (Exploitable Bugs), che possono portare a crash ed esecuzione di codice remoto (Remote Code Execution). C'è anche il problema che tali librerie hanno spesso caratteristiche di prestazioni (Performance Characteristics) difficili da prevedere, portando ad attacchi che sovraccaricano un'implementazione confrontando con un'espressione regolare costosa controllata dall'attaccante.

Gli I-Regexp sono stati progettati per consentire l'implementazione in un modo che sia resiliente a entrambe le minacce. Questo obiettivo deve essere affrontato durante tutto lo sforzo di implementazione. Le implementazioni senza controllo (vedere la Sezione 3.1) probabilmente esporranno le limitazioni di sicurezza di qualsiasi motore di espressioni regolari che utilizzano, che potrebbe essere meno problematico se quel motore è stato costruito tenendo conto delle considerazioni di sicurezza (ad esempio, [RE2]). In ogni caso, un'implementazione di controllo (Checking Implementation) è comunque RACCOMANDATА.

Le implementazioni che implementano specificamente il sottoinsieme I-Regexp possono, con attenzione, essere progettate per funzionare generalmente in tempo e spazio lineari (Linear Time and Space) nell'input e per rilevare quando ciò non sarebbe il caso (vedere sotto).

I motori di espressioni regolari esistenti dovrebbero essere in grado di gestire facilmente la maggior parte degli I-Regexp (dopo le regolazioni discusse nella Sezione 5), ma potrebbero consumare risorse eccessive per alcuni tipi di I-Regexp o rifiutarli del tutto perché non possono garantire un'esecuzione efficiente. (Si noti che diverse versioni della stessa libreria di espressioni regolari potrebbero essere più o meno vulnerabili al consumo eccessivo di risorse per questi casi.)

In particolare, i quantificatori di intervallo (Range Quantifiers) (come in a{2,4}) forniscono sfide particolari sia per le implementazioni esistenti che per quelle focalizzate su I-Regexp. Le implementazioni possono quindi limitare i quantificatori di intervallo nella componibilità (Composability) (vietando quantificatori di intervallo annidati come (a{2,4}){2,4}) o nell'intervallo (vietando intervalli molto grandi come a{20,200000}), o rilevare e rifiutare qualsiasi consumo eccessivo di risorse causato dai quantificatori di intervallo.

Le implementazioni I-Regexp che vengono utilizzate per valutare espressioni regolari da fonti non affidabili devono essere robuste (Robust) in questi casi. Gli implementatori che utilizzano librerie di espressioni regolari esistenti sono incoraggiati:

• a controllare la loro documentazione per vedere se le mitigazioni (Mitigations) sono configurabili, come i limiti nel consumo di risorse, e
• a documentare il proprio grado di robustezza risultante dall'impiego di tali mitigazioni.