Peut la validation standard de JSF empêcher l'injection de code ?

Question

Dans mon projet, je fais une validation en double au niveau de la présentation ainsi qu'au niveau de la persistance avec l'espoir d'augmenter la sécurité. Donc ma question est : est-ce que la validation JSF standard peut prévenir les injections de code.

Ici je valide si le champ est vide, et je valide la longueur du champ. Je sais que la validation de la longueur du champ rendra plus difficile les injections de code, mais parfois vous avez besoin d'une longue longueur de champ, comme textArea. Et si cela est vulnérable, comment puis-je le réparer ? Merci beaucoup d'avance.

Answer 1

JSF par défaut empêche déjà les attaques XSS en échappant les entrées contrôlées par l'utilisateur dans les composants UIInput et UIOutput. Cela est contrôlable dans h:outputText en définissant l'attribut escape="false". Vous n'avez pas besoin de vous en soucier.

La prévention contre les attaques par injection SQL, d'autre part, n'est pas la responsabilité de JSF. Vous devez gérer cela dans la couche de persistance. Par exemple, JPA et/ou Hibernate, lorsque bien utilisés (c'est-à-dire ne pas concaténer les entrées contrôlées par l'utilisateur dans des chaînes SQL/requêtes nommées), empêchent également cela par défaut. En utilisant simplement JDBC, vous devez vous assurer d'utiliser un PreparedStatement au lieu d'un Statement pour inclure les entrées contrôlées par l'utilisateur dans une chaîne SQL. Lorsqu'ils sont bien utilisés, vous n'avez également pas besoin de vous en préoccuper du côté JSF.

Questions connexes :

• Comment fonctionnent réellement les attaques XSS ?
• Comment fonctionnent les attaques CSRF ?

Answer 2

Les attaques par injection ont un thème commun : les données d'entrée sont transformées et interprétées comme du code, à un moment donné en raison de diverses failles dans l'application. La faille la plus fréquemment observée est celle des données non désinfectées qui ne sont pas encodées ou échappées correctement. La seule présence ou absence de codage ne protège pas une application contre les attaques - les caractères qui permettent la transformation du code en données doivent être encodés de manière à ce qu'ils ne soient pas distingués comme du code.

Maintenant, du point de vue de JSF, les concepteurs ont été attentifs à inclure une protection contre certains types d'attaques. Comme il s'agit d'un cadre de présentation, la protection contre les attaques XSS (et les attaques CSRF, bien que cela ne soit pas lié à l'injection) est présente. Les mécanismes de protection et leur utilisation sécurisée sont détaillés dans les pages du cadre Seam sur Cross Site Scripting et Cross Site Request Forgery. Seam utilise JSF, il n'y a donc pas beaucoup de différence pour protéger une application JSF et une application Seam contre XSS et CSRF ; la plupart des conseils de ces pages sont susceptibles de s'appliquer à une application JSF.

Cependant, si vous avez besoin de vous protéger contre d'autres attaques par injection importantes, en particulier les injections SQL, vous devez examiner les fonctionnalités offertes par votre cadre de persistance (en supposant que vous en utiliserez un). Si vous écrivez manuellement des requêtes SQL et les exécutez directement dans votre code, utilisez des objets PreparedStatement pour vous protéger contre les variétés les plus courantes d'injections SQL. Si vous utilisez JPA, JDO, etc., vous devrez envisager d'utiliser ces cadres de manière sécurisée - la plupart d'entre eux créent des objets PreparedStatement par défaut lorsqu'ils leur sont transmises des requêtes, il y a donc souvent peu de soucis à avoir.

Protection contre les attaques par injection SQL dans JPA

Les requêtes nommées et natives seront converties en interne en une instruction préparée qui utilise des requêtes paramétrées. C'est la responsabilité du fournisseur JPA. Il faudra se soucier des requêtes SQL qui sont construites avant d'être transmises au fournisseur. Fondamentalement, les chaînes transmises à EntityManager.createQuery() et EntityManager.createNativeQuery() ne doivent pas avoir des entrées utilisateur concaténées.

PS : La fonction de protection contre les attaques CSRF est présente dans JSF 2 et non dans JSF 1.x. Elle n'est également présente que dans certaines versions de Seam (à partir de la version 2.1.2).