OWASP ESAPI est-il toujours le moyen recommandé pour sécuriser les pages JSP
J'ai remarqué que OWASP ESAPI n'a pas été mis à jour depuis un certain temps ( mise à jour mineure en 2016 et avant 201 ). Existe-t-il de meilleures alternatives à son utilisation, c'est-à-dire en utilisant des utilitaires d'un cadre plus maintenu pour, par exemple, échapper et valider les entrées utilisateur en tant que prévention XSS. Pense <cout .../> ou Struts 2 ou tout autre framework propre à la sortie et à l'échappement du code. Ou est-il préférable, du point de vue de la sécurité, de toujours utiliser OWASP pour cela? Pensées?
L'OWASP ESAPI n'est plus considéré comme un projet phare ni même un projet actif. Kevin Wall, le propriétaire du projet pour la Java, lui-même en 2014 a concédé que le projet est en train de mourir et a déclaré:
Je ne le suis pas, car je ne peux pas. Pour ma part, je peux voir l'écriture sur le mur. (Pun jeu.) Toutes les allégations qui sont faites contre ESAPI sont sur le point:
· Une seule version mineure ponctuelle depuis juillet 2011.
· 164 problèmes en suspens, dont 4 marqués comme critiques et 11 marqués comme élevés.
· Beaucoup trop de dépendances, quelque chose qui n'a jamais été résolu malgré la promesse de près de 3 ans.
· La page Wiki est toujours dans l'ancien format OWASP.
· Signes de vie minimaux pour ESAPI 3.0 dans GitHub et ESAPI 2.x pour Java sur Google Code. Zéro signe de vie pour les implémentations dans d'autres langages de programmation. [Remarque: actualisation de SalesForce comme Je ne l'ai pas gardé.]
· Pour ESAPI pour Java, une architecture boogée où tout est un singleton rendant certaines choses telles que les simulations de tests presque impossibles. Couverture de code de test inférieure à 80%, en partie à cause de cela.
· Absence de toute documentation utilisateur importante en dehors de la documentation Javadoc et ESAPI crypto.
· Participation décevante au Hackathon ESAPI.
Un autre texte de Kevin Wall sur Dois-je utiliser ESAPI?
Si vous démarrez sur un nouveau projet ou essayez pour la première fois de sécuriser un projet existant, alors avant vous envisagez ESAPI, vous devriez envisager ces possibilités alternatives:
- Encodage de sortie: OWASP Java Encoder Project
- Purification HTML générale: OWASP Java HTML Sanitizer
- Validation: validation du bean JSR-303/JSR-349
- Cryptographie forte: Keyczar
- Authentification/autorisation: Apache Shiro
- Protection CSRF: projet OWASP CSRFGuard ou projet OWASP CSRFProtector
Notez que cela ne signifie pas qu'ESAPI est mort, mais plutôt pour reconnaître qu'il n'est pas aussi bien entretenu que la plupart des sociétés F500 le souhaiteraient pour leurs logiciels d'entreprise.
IMO si vous avez l'option, vous devez utiliser des cadres tels que Spring, qui dispose d'installations pour traiter de nombreux problèmes de sécurité (par exemple, Spring Security pour l'authentification, CSRF). Pour la sortie, encore une fois, de nombreux frameworks/bibliothèques modernes se chargent de l'encodage. Par exemple. avec JSP, puis utilisez JSTL - il a une bibliothèque de balises pour l'encodage HTML. Si vous développez des clients riches, les frameworks tels que React coderont HTML par défaut.
Un scénario où ESAPI reste utile est si vous modernisez une application héritée qui manque de sécurité. Même alors, ESAPI a suffisamment de problèmes/vulnérabilités ouverts qui devraient vous donner une pause. C'est une triste situation et Kevin Wall semble un peu amer:
La première question à se poser est la suivante: utilisez-vous déjà ESAPI dans votre projet, et si oui, avez-vous beaucoup à lui confier? Si oui, alors la réponse à "Dois-je utiliser ESAPI?" est probablement "oui". La deuxième question que vous devriez poser, si je l'utilise, pourquoi n'y contribue-t-elle pas d'une manière ou d'une autre? Mais nous n'irons pas là-bas.