8. Security Considerations (Considérations de sécurité)

8. Security Considerations (Considérations de sécurité)

Bien que techniquement hors du champ d'application de cette spécification, la section 10 ("Considérations de sécurité" (Security Considerations)) de RFC 3629 [STD63] s'applique aux implémentations. Une attention particulière doit être portée au dernier paragraphe de la section 3 ("Définition UTF-8" (UTF-8 definition)) de RFC 3629 [STD63]. Une implémentation I-Regexp peut avoir besoin d'atténuer les limitations de l'implémentation de la plateforme à cet égard.

Comme discuté dans la section 6, les bibliothèques d'expressions régulières plus complexes peuvent contenir des bogues exploitables (Exploitable Bugs), qui peuvent conduire à des plantages et à l'exécution de code à distance (Remote Code Execution). Il y a aussi le problème que de telles bibliothèques ont souvent des caractéristiques de performance (Performance Characteristics) difficiles à prévoir, conduisant à des attaques qui surchargent une implémentation en correspondant à une expression régulière coûteuse contrôlée par l'attaquant.

Les I-Regexp ont été conçus pour permettre une implémentation de manière résiliente aux deux menaces. Cet objectif doit être abordé tout au long de l'effort d'implémentation. Les implémentations sans vérification (voir la section 3.1) sont susceptibles d'exposer les limitations de sécurité de tout moteur d'expressions régulières qu'elles utilisent, ce qui peut être moins problématique si ce moteur a été construit avec des considérations de sécurité à l'esprit (par exemple, [RE2]). Dans tous les cas, une implémentation de vérification (Checking Implementation) est toujours RECOMMANDÉE.

Les implémentations qui implémentent spécifiquement le sous-ensemble I-Regexp peuvent, avec soin, être conçues pour s'exécuter généralement en temps et espace linéaires (Linear Time and Space) dans l'entrée et pour détecter quand ce ne serait pas le cas (voir ci-dessous).

Les moteurs d'expressions régulières existants devraient pouvoir gérer facilement la plupart des I-Regexp (après les ajustements discutés dans la section 5), mais peuvent consommer des ressources excessives pour certains types d'I-Regexp ou les rejeter complètement car ils ne peuvent pas garantir une exécution efficace. (Notez que différentes versions de la même bibliothèque d'expressions régulières peuvent être plus ou moins vulnérables à une consommation excessive de ressources pour ces cas.)

Plus précisément, les quantificateurs de plage (Range Quantifiers) (comme dans a{2,4}) posent des défis particuliers pour les implémentations existantes et celles axées sur I-Regexp. Les implémentations peuvent donc limiter les quantificateurs de plage en composabilité (Composability) (interdire les quantificateurs de plage imbriqués tels que (a{2,4}){2,4}) ou en plage (interdire les plages très grandes telles que a{20,200000}), ou détecter et rejeter toute consommation excessive de ressources causée par les quantificateurs de plage.

Les implémentations I-Regexp qui sont utilisées pour évaluer des expressions régulières provenant de sources non fiables doivent être robustes (Robust) dans ces cas. Les implémenteurs utilisant des bibliothèques d'expressions régulières existantes sont encouragés:

• à vérifier leur documentation pour voir si des atténuations (Mitigations) sont configurables, telles que des limites de consommation de ressources, et
• à documenter leur propre degré de robustesse résultant de l'emploi de telles atténuations.