Est-il sûr de laisser un utilisateur saisir une expression régulière comme entrée de recherche?
J'étais dans un centre commercial il y a quelques jours et j'ai cherché une boutique sur un panneau d'indication.
Par curiosité, j'ai tenté une recherche avec (.+) et j'ai été un peu surpris d'avoir la liste de tous les magasins du centre commercial.
J'ai lu un peu sur regexes diaboliques mais il semble que ce type d'attaque ne peut se produire que lorsque l'attaquant a à la fois le contrôle de l'entrée à rechercher et de l'entrée de recherche (l'expression régulière).
Pouvons-nous considérer le panneau d'indication du centre commercial à l'abri de DOS, étant donné que l'attaquant n'a que le contrôle de l'entrée de recherche? (Laissant de côté la possibilité qu'un magasin puisse s'appeler un nom étrange comme aaaaaaaaaaaa.)
Je comparerais l'acceptation d'expressions régulières fournies par l'utilisateur à l'analyse de la plupart des types d'entrées utilisateur structurées, telles que les chaînes de date ou la démarque, en termes de risque d'exécution de code. Les expressions régulières sont beaucoup plus complexes que les chaînes de date ou le démarquage (bien que la production en toute sécurité de code HTML à partir d'un démarquage non approuvé présente ses propres risques) et représente donc plus de marge pour l'exploitation, mais le principe de base est le même: l'exploitation implique de trouver des effets secondaires inattendus de l'analyse/processus de compilation/appariement.
La plupart des bibliothèques regex sont matures et font partie de la bibliothèque standard dans de nombreuses langues, ce qui est un indicateur assez bon (mais pas certain) qu'il est exempt de problèmes majeurs menant à l'exécution de code.
C'est-à-dire que cela augmente votre surface d'attaque, mais il n'est pas déraisonnable de prendre la décision mesurée d'accepter ce risque relativement mineur.
Les attaques par déni de service sont un peu plus délicates. Je pense que la plupart des bibliothèques d'expressions régulières sont conçues avec des performances à l'esprit, mais ne comptent pas l'atténuation de l'entrée intentionnellement lente parmi leurs principaux objectifs de conception. La pertinence d'accepter des expressions régulières fournies par l'utilisateur du point de vue DoS dépend davantage de la bibliothèque.
Par exemple, la bibliothèque d'expressions régulières .NET accepte un délai d'expiration qui pourrait être utilisée pour atténuer les attaques DoS.
RE2 garantit l'exécution en temps linéaire à la taille d'entrée qui peut être acceptable si vous savez que votre corpus de recherche se situe dans une limite de taille raisonnable.
Dans les situations où la disponibilité est absolument critique ou lorsque vous essayez de minimiser votre surface d'attaque autant que possible, il est logique d'éviter d'accepter l'expression régulière de l'utilisateur, mais je pense que c'est une pratique défendable.
La principale menace en acceptant des expressions régulières sera dans votre moteur d'exécution regex plutôt que d'accepter regex lui-même. Je m'attends à ce que la menace soit très, très faible dans tout moteur bien implémenté. Le moteur ne doit avoir besoin d'accéder à aucune ressource système privilégiée et ne doit exécuter la logique que sur les entrées fournies directement au moteur. Cela signifie que même si quelqu'un trouve un exploit dans l'interpréteur, les dommages qui peuvent être causés devraient être minimes.
Dans l'ensemble, tout regex est conçu pour rechercher des motifs dans une valeur. Tant que la sécurité appropriée est respectée sur les valeurs que vous comparez, il n'y a aucune raison pour que le moteur lui-même ait accès à la modification des valeurs. Je le classerais comme généralement assez sûr.
Cela dit, je ne le fournirais également que dans les situations où il était raisonnable de le faire. Regex est complexe, peut prendre du temps à s'exécuter et utilisé au mauvais endroit pourrait avoir des impacts indésirables sur une application en dehors d'un contexte de sécurité, mais dans le bon cas d'utilisation, ils sont extrêmement puissants et extrêmement précieux. (Je suis un architecte logiciel qui refaçonne régulièrement des centaines de milliers de lignes de code en utilisant regex.)
Comme les autres réponses l'ont souligné, le vecteur d'attaque serait très probablement le moteur d'expression régulière.
Alors que vous supposeriez que ces moteurs sont assez matures, robustes et soigneusement testés, cela s'est produit dans le passé:
CVE-2010-1792 Exécution de code arbitraire dans Apple Safari et iOS. Citation du Patch notes :
Un problème de corruption de mémoire existe dans la gestion des expressions régulières par WebKit. La visite d'un site Web conçu de manière malveillante peut entraîner la fermeture inattendue d'une application ou l'exécution de code arbitraire.
Mais bien sûr, l'argument d'une bibliothèque éventuellement défectueuse vaut pour tout - même fichiers JPEG fournis par l'utilisateur .
L'autre aspect, bien que non intrinsèquement technique, serait le (.+) cas que vous avez mentionné: le produit doit-il permettre la récupération arbitraire de données?
Le problème est que les moteurs regex "font marche arrière". Lorsque vous avez une opération de répétition (par exemple + ou *) dans votre expression régulière, le moteur d'expression régulière essayera de la faire correspondre avec autant de la chaîne d'entrée que possible. Si la correspondance échoue plus tard, elle reviendra en arrière et tentera de faire correspondre votre répétition avec une plus petite partie de la chaîne d'entrée.
Plusieurs opérations de répétition peuvent conduire à un retour en arrière imbriqué, ce qui peut entraîner le temps d'évaluer massivement l'expression régulière, en particulier si les opérateurs de répétition sont imbriqués.
Non, ReDoS ne nécessite pas que l'attaquant crée des résultats de recherche non naturels.
L'idée de base de ReDoS est que vous avez une sous-expression qui peut correspondre de plusieurs façons et correspond presque partout dans la chaîne recherchée sauf la fin, et vous itérez cette sous-expression pour obtenir un retour en arrière catastrophique. Par exemple, si la description de votre boutique est Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua., vous pouvez simplement utiliser quelque chose comme ([^q]|[^q][^q])+ (ou des constructions plus complexes avec par exemple des anticipations).
Que ce soit un problème dépend - comme d'autres réponses l'ont expliqué, vous pouvez simplement limiter le temps disponible pour le moteur regex.