efficacité des frameworks face aux attaques

Bonjour,

J'utilise JSF 1.1 et Hibernate 3 sur un serveur d'application Weblogic 8.1.6. qui utilise java 1.4

Actuellement, je me penche sur le problème de la robustesse de JSF et hibernate face aux attaques comme xss, injection, etc.

J'ai cherché sur le net de la doc pour savoir jusqu'à quel point ces 2 framework sont robuste sur ce point, mais j'ai pas trouvé grand chose :(

Alors, si vous avez des infos, des retours d'expériences, de la doc de références et autre je suis preneur :king:

En vous remerciant par avance de vos réponses ;)

pour gerer la securité de ton appli il sera mieux si tu utilise spring.


sinon si tu trouve autre chose informe moi stp car je veux savoir


merci.

Une simple recherche sur hibernate t aurais informer qu hibernate est protégé contre le sql injection ...

mais je doute que tu veuilles mettre en ligne une appli j2ee dédiée large scale utilisant spring hibernate et jsf par exemple

mise à part si tu es tres riche :aie:

Hello,

est-ce que tu peux me donner la ref du doc et où cela se trouve dans la doc ?

Je viens de faire une recherche dans la doc hibernate, j'ai pas trouvé :cry:

En tout cas, merci pour ta réponse et je te remercie pour ta future réponse :king:

hibernate est concu sérieusement, est en open source et fortement utilisé. Tu peux donc raisonnablement supposer que les requete construites par hibernate sont protégées. Bien sur, ca ne proteger pas les requetes hibernate (HQL) et SQL que tu construit toi même. C'est à toi de faire le boulot. Par contre, je pense pas que tu trouvera un audit du code qui te garantit le truc sql injection free.

Pour ce qui est de JSF, garde à l'esprit quelque chose d'important. En aucune manière JSF ne te dispense de vérifier la cohérence de tes données dans le bean avant de les stocker. C'est juste une aide à la gestion de la validation. Exemple le plus simple en hibernat, le required=true. Ca dit "si la valeur est soumise elle ne doit pas etre vide", ca ne dit pas "la valeur doit etre soumise" (contrairement à ce que beaucoup supposent au premier abord)