Je conseille d'utiliser une architecture de sécurité en couches. Je veux dire, il est possible de créer une application sécurisée à la main, mais c'est extrêmement difficile à implémenter. Certaines fonctionnalités de sécurité comme l'authentification et le contrôle d'accès de base (niveau URL ou niveau de composant GUI) sont relativement faciles à implémenter, mais les exigences telles que la sécurité des instances (particulièrement avec les bases de données existantes), Sql Injection et XSS sont plus difficiles.
Je recommande d'utiliser Spring Security et d'implémenter autant que possible les validations personnalisées. En plus de cela, je recommande d'utiliser HDIV afin d'ajouter une couche de sécurité supplémentaire qui pourrait aider à éviter l'exploitation des risques non couverts par des validations personnalisées. Plus précisément, les fonctionnalités offertes par HDIV sont:
Injection A1-: en ce qui concerne les valeurs et les urls des paramètres HTTP HdIV réduire le risque de cette vulnérabilité pour que les données qui proviennent de champs de texte dans les formulaires, l'application de validation d'intégrité (assure que la valeur reçue est la même que celle générée côté serveur) pour le reste des données provenant du côté client. Pour les champs de texte inclus dans les formulaires, HDIV propose des validations génériques (liste blanche et liste noire) afin d'éviter les attaques par injection.
authentification A2-Cassé et de gestion de session: HDIV ne propose pas de fonctionnalités pour ce risque web.
A3-XSS: identique à A1 mais dans ce cas pour éviter les risques XSS.
A4-Insecure Objet Direct Références: contrôle HDIV toutes les données générées à côté serveur assurant l'intégrité des données et éviter cette vulnérabilité.
A5-misconfiguration sécurité: HDIV ne comprend pas de fonctionnalités spécifiques pour cela, mais ne permet pas l'accès aux ressources non envoyées par le serveur précédemment, en évitant l'exploitation des comportements inattendus ou l'accès aux ressources privées.
A6-sensible Exposition de données: HDIV offre fonction de confidentialité pour cacher les valeurs des paramètres HTTP.
A7 manquantes Fonction Niveau de contrôle d'accès: grâce aux validations d'intégrité mis en œuvre par HDIV, évite l'exploitation de cette vulnérabilité et de limiter l'utilisateur d'exécuter des actions en justice et le maintien du contrat initial (GUI ou API) offert par l'application
.
A8-Cross-Site Request Forgery (CSRF): HDIV ajoute des jetons à éviter aléatoires cette vulnérabilité
A9-composants utilisant des vulnérabilités connues: HDIV ne comprend pas fonctionnalités spécifiques pour cela, mais grâce à l'interaction limitations appliquées à l'utilisateur dans de nombreux cas, il n'est pas possible de exploiter cette vulnérabilité.
redirections A10-non validée et vers l'avant: Cette vulnérabilité est principalement liée à la manipulation de données non modifiables ou des données générées précédemment à côté serveur. HDIV contrôle toutes les données envoyées par le serveur et ne permet pas la redirection vers des sites Web malveillants .
En plus de ces fonctionnalités pour protéger contre OWASP dix risques web, HDIV génère des journaux également liée à l'activité malveillante ou des attaques contre votre site Web, y compris toutes les informations sur l'attaque et le nom d'utilisateur dans les sites Web authentifiées .
Cordialement,
Roberto Velasco (équipe HDIV)
Spring Security gère uniquement sécurisation des URL et vous donne un cadre de connexion, si le mécanisme d'authentification sous-jacente est encore faible, vous aurez encore une violation potentielle de sécurité . Spring Security fournit un mécanisme pour forcer le SSL sur les URL, mais vous avez toujours besoin d'un certificat SSL.Bref, Spring Security ne suffit pas à satisfaire le top 10 d'OWASP. –