Analyse

Un mécanisme de défense qui est essentiel pour le bon fonctionnement des applications est la validation des entrées. Dans l’abstrait, de validation d’en- trée est le processus d’attribution de la signification sémantique aux intrants non structurées et non fiable à une application, et veiller à ce que ces entrées de respecter un ensemble de contraintes décrivant une entrée bien formé. Pour les applications Web, les entrées prennent la forme de paires clé-valeur des ‘strings’. La validation de ces entrées peut être effectuée soit en le naviga- teur en utilisant Javascript, ou sur le serveur. Comme il n’existe actuellement aucune garantie de l’intégrité de calcul dans le navigateur, la validation des entrées relevant de la sécurité doit être effectuée sur le serveur, et, par consé- quent, nous limitons notre discussion sur la validation des entrées dans ce contexte.

Pour élucider le processus de validation d’entrée pour les applications web côté serveur, examiner la demande HTTP pédagogique illustré à la figure 8.6. Cette figure montre une structure typique pour une demande de soumission de paiement à une fiction application e-commerce. Dans le cadre de cette demande, il ya plusieurs paramètres d’entrée que la logique de commande pour /payment/submit doit gérer : cc, un numéro de carte de crédit ; month, un mois numérique ; year, une année numérique ; save, un indicateur indiquant si les informations de paiement doivent être enregistrés pour une utilisation future ; token, une token anti-CSRF ; et SESSION, un identificateur de session. Chacun de ces paramètres de la requête nécessite un autre type de validation d’entrée. Par exemple, le numéro de carte de crédit devrait être un certain nombre de caractères et de passer un test de Luhn. Le paramètre mois devrait être une valeur entière entre 1 et 12 in-

clus. Le paramètre année devrait aussi être une valeur entière, mais peut varier de l’année en cours à une année d’arbitraire dans un proche avenir. L’indicateur de sauvegarde doit être une valeur booléenne, mais comme il ya différentes représentations de la vraie logique et fausse, (par exemple, {true, false} , {1, 0} , {yes, no}), la demande doit toujours reconnaître un en- semble fixe de valeurs possibles.

La validation des entrées, en plus de son rôle dans la facilitation de la correction du programme, est un outil utile pour empêcher l’introduction de vulnérabilités dans les applications web. Y at-il un attaquant de fournir la valeur :

year=2012’; INSERT INTO admins(user, passwd) VALUES(’foo’, ’bar’);--

à notre fiction application e-commerce dans le cadre d’une vulnérabilité SQL injection pour élever ses privilèges, de validation d’entrée appropriée serait de reconnaître que la valeur malveillant n’était pas une année valide, avec le résultat que la demande serait refuser de traiter la demande.

La validation des entrées peut se produire de multiples façons. La va- lidation peut être effectuée implicitement — par exemple, par typecasting une ‘string’ à une type primitif, comme un booléen ou nombre entier. Pour l’attaque par exemple montré ci-dessus, un casting de la ‘input string’ à un nombre entier se traduirait par une erreur de cast de l’exécution, puisque la valeur malveillant n’est pas un entier bien formé. D’autre part, de validation d’entrée peut être exécutée de façon explicite, en invoquant des routines de validation fournis par le cadre. La validation explicite est généralement effec- tuée pour les valeurs d’entrée présentant la structure complexe, comme les adresses e-mail, URL, ou numéros de carte de crédit. à cet égard, le choix du langage de programmation et un cadre pour développer des applications Web joue un rôle important dans la sécurité de ces applications. Tout d’abord, si une langue dispose d’un système de type fort de telle sorte que transty- pages de valeurs d’entrée mal formées à certains types primitifs se traduira par des erreurs d’exécution, la langue peut constituer une défense implicite contre l’introduction de vulnérabilités comme cross-site scripting et SQL in- jection. Deuxièmement, si un cadre pour les langues fournit un ensemble complet de routines de validation d’entrée pour les données complexes telles que les adresses e-mail ou numéros de carte de crédit, l’invocation de ces routines peuvent en outre améliorer la résilience d’une application web à l’introduction de vulnérabilités courantes.

Typecasting comme une défense implicite

Afin de quantifier la mesure dans laquelle transtypage de valeurs d’entrée à des types primitifs pourraient servir comme une couche de défense contre les vulnérabilités cross-site scripting et SQL injection, nous avons effectué

une analyse sur les rapports de vulnérabilité pour un ensemble de test d’ap- plications web. Particulièrement, nous avons examiné le code source de ces applications afin de déterminer si l’entrée de la vulnérabilité a un type pri- mitif. Lorsque nous ne pouvions identifier directement le type, nous avons examiné les modifications apportées au code source pour résoudre la vulné- rabilité.

Nous avons extrait tous les paramètres d’entrée des applications grâce à l’approche décrit dans la section 8.4.1. We extracted all the input para- meters of the applications through the approach described in Section 8.4.1. Following this approach, we were able to link 270 parameters corresponding to cross-site scripting attack vectors, and 248 parameters corresponding to SQL injection vectors to the source of of the test set of applications.3

Figures 8.7a et 8.7b montrent un aperçu des types correspondant à des paramètres d’entrée vulnérables à cross-site scripting et SQL injection. La plupart des paramètres vulnérables était l’un des types suivants : boolean, numeric, structured text, free text, enumeration, ou union. Les Booleans peuvent prendre soit logiques valeurs vraies ou fausses. Des exemples de types numériques sont des nombres entiers ou à virgule flottante. Par “struc- tured text”, nous entendons que le paramètre est une chaîne et, en outre, il ya une structure attendue à la ‘string’. Un vrai nom, URL, adresse e-mail, ou un nom d’utilisateur dans un formulaire d’inscription sont des exemples de ce type. En revanche, le type “free text” texte désigne arbitraires, les ‘strings’ non structurées. Les paramètres d’entrée correspondant au type de recensement ne devrait accepter un ensemble fini de valeurs qui sont connus à l’avance. Les exemples sont les genres, les noms de pays, ou un champ de formulaire de sélection. Finalement, un type d’union indique une variable qui combine plusieurs types (par exemple, une valeur qui devrait être soit une valeur numérique ou une valeur booléenne).

Seulement environ 20% des vulnérabilités de validation d’entrée sont associés avec le type de texte libre. Cela signifie que dans ces cas, la demande devrait accepter une entrée de texte arbitraire. Ainsi, une vulnérabilité de validation d’entrée de ce type ne peut être empêchée par la désinfection de l’fourni par la validation d’entrée.

Intéressant de noter que 35% des paramètres d’entrée vulnérables aux attaques cross-site scripting sont en réalité numérique, le dénombrement, ou les types booléens (y compris les listes de valeurs de ces types), tandis que 68% des paramètres d’entrée vulnérables aux SQL injection correspondent à ces types de données simples. Ainsi, la majorité des vulnérabilités de valida- tion d’entrée pour ces applications auraient pu être évités par l’application de la validation de l’utilisateur fourni par l’entrée en fonction des types de données simples. Nous croyons que le grand nombre de paramètres vulné-

3

Many CVE reports do not mention any attack vectors. Hence, we excluded them for this analysis.

boolean 3% enumera on 12% number 15% structured text 43% freetext 21% list of structured text 0% list of freetext 1% list of number 1% list of boolean 3% list of enumera on 1% union types 0% _{list of union} 0%

(a) Vulnerabilités cross-site scripting

boolean 4% enumera on 10% number 45% structured text 24% freetext 7% list of structured text 1% list of freetext 1% list of number 7% union types 1% (b) Vulnerabilités SQL injection

Figure_{8.7: Les types de données correspondant à des paramètres d’entrée} vulnérables.

rables à SQL injection qui correspondent au type numérique est causée par le phénomène que beaucoup d’applications web utilisent des nombres entiers pour identifier les objets et utiliser ces valeurs dans la logique de l’application qui interagit avec la base de données back-end (par exemple pour identifier les utilisateurs, des messages ou blogs).

8.4.3 Discussion

Les résultats de notre étude suggèrent que la majorité des vulnérabilités cross-site scripting et SQL injection peut être prévenue par la validation implicite résultant d’incantation réduit à des types primitifs observés dans les applications écrites dans des langages fortement typés. En particulier, pour les vulnérabilités SQL injection, la distribution simple des paramètres à des nombres entiers et les booléens permettrait d’éliminer plus de la moitié des vulnérabilités existantes. Cela peut expliquer pourquoi les applications écrites en Java sont moins vulnérables à ces classes d’attaques.

Paramètres d’entrée vulnérables qui doivent accepter d’entrée arbitraire, et donc le cas doit être désinfecté par cas par le développeur, sont dans la pratique une large minorité. Par conséquent, nous préconisons que, ana- logue à l’affaire de cadre de soutien pour l’auto-assainissement, langages de développement web ou de cadres devraient soutenir la validation auto- matique des entrées de l’application Web en tant que mesure de sécurité. Une politique d’alimentation automatique de validation peut prendre plu- sieurs formes concrètes, telles que l’intégration dans le système de type de la langue, le cadre soutenu par l’annotation de paramètres d’entrée, ou une description de la politique centralisée appliquées au niveau du cadre.

Les résultats de notre étude empirique suggèrent que de nombreuses vul- nérabilités SQL injection et cross-site scripting pourraient facilement être évités si les langages du web et des cadres serait en mesure de valider auto- matiquement l’entrée en fonction des types de données courants tels que les numéros entiers, booléen, et certains types de ‘strings’ telles que e-mails et les URL.