Les 10 contrôles de sécurité les plus importants manquant dans Java EE

JavaEE possède de superbes mécanismes de sécurité intégrés, mais ils sont loin d'être à la hauteur. couverture Toutes les menaces auxquelles votre application est confrontée. De nombreuses attaques courantes telles que le Cross-Site Scripting (XSS), l'injection SQL, la falsification de requêtes intersites (CSRF) et le XMLEntités externes (XXE) ne sont pas couvertes. Il est possible d'empêcher les applications Web et les services Web d'être exposés à ces attaques, mais cela nécessite une certaine quantité de travail et de tests. Heureusement, l'Open Web Application Security Project (OWASP) a publié le document. Rapport "Top 10 des risques de sécurité des applications Web les plus critiques".

Voyons comment ces risques clés s'appliquent aux applications et services Web Java EE :

1. Injection

L'injection se produit lorsque le développeur obtient des informations non fiables, telles que request.getParameter(), request.getCookie() ou request.getHeader(). , et dans Utilisez-le à tout moment dans une interface de commande. Par exemple, injection SQL lorsque vous connectez des données non fiables à une requête SQL standard telle que "SELECT * FROM users WHERE username='" + request.getParameter("user") + "' AND. passw Se produit lorsque ord='" + request.getParameter("pass") = "'". Les développeurs doivent utiliser PreparedStatement pour empêcher les attaquants de modifier la signification de la requête et de prendre le contrôle de l'hôte de la base de données. Il existe de nombreux autres types d'injections tels que l'injection de commande, l'injection LDAP et l'injection d'expression Language (EL), qui sont toutes extrêmement dangereuses, alors soyez extrêmement prudent lorsque vous envoyez des données à ces interprètes

2. .Authentification cassée et gestion de session

JavaEE prend en charge l'authentification et la gestion de session, mais il y a beaucoup de choses qui peuvent mal se passer ici. Vous devez vous assurer que tout le trafic authentifié passe par SSL, sans exception si jamais. exposez JSESSIONID, il peut alors être utilisé pour détourner la session de l'utilisateur à votre insu. Vous devez faire pivoter le JSESSIONID lorsque l'utilisateur s'authentifie pour éviter les attaques de fixation de session. il ajoute le JSESSIONID de l'utilisateur à l'URL, ce qui le rend plus vulnérable à la divulgation ou au vol.

3. Cross-site scripting (XSS)

XSS se produit lorsque les développeurs JavaEE obtiennent des informations non fiables à partir de requêtes HTTP et les insèrent dans des réponses HTTP sans sortie de contexte appropriée lors de l'encodage. Les attaquants peuvent exploiter ce comportement pour injecter leurs scripts dans un site Web où ils peuvent ensuite détourner des sessions et voler des données. Pour empêcher ces attaques, les développeurs doivent effectuer un codage de sortie contextuelle sensible. Si vous convertissez des données en HTML, utilisez le format x; Assurez-vous de mettre entre crochets les attributs HTML car les attributs sans crochets seront terminés s'il y a de nombreux caractères différents. Si vous placez des données non fiables dans JavaScript, URL ou CSS, vous devez utiliser la méthode d'échappement appropriée pour chacune. Et soyez très prudent lorsque vous traitez un contexte imbriqué, tel qu'une URL écrite en Javascript dans un attribut HTML. Vous souhaiterez peut-être aider avec des bibliothèques de codage telles que OWASP ESAPI.

4. Références d'objet directes non sécurisées

Chaque fois qu'une application expose un identifiant interne, tel qu'une clé de base de données, un nom de fichier ou un hash carteindex, un attaquant peut tenter de manipuler ces identifiants pour accéder à des données non autorisées. Par exemple, si vous transmettez des données non fiables d'une requête HTTP à un constructeur de fichier Java, un attaquant peut utiliser des attaques "../" ou des octets nuls pour tromper votre validation. Vous devriez envisager d’utiliser des références indirectes à vos données pour empêcher ce type d’attaque. La bibliothèque ESAPI prend en charge les ReferenceMaps qui facilitent de telles références indirectes.

5. Mauvaise configuration de sécurité

Les applications JavaEE modernes et les frameworks tels que Struts et Spring disposent d'un grand nombre de paramètres de sécurité. Assurez-vous de parcourir les paramètres de sécurité et de les configurer comme vous le souhaitez. Par exemple, soyez prudent avec la balise dans . Cela indique que la contrainte de sécurité s'applique uniquement aux méthodes répertoriées, permettant à un attaquant d'utiliser d'autres méthodes HTTP, telles que HEAD et PUT, pour contourner l'intégralité de la contrainte de sécurité. Peut-être devriez-vous supprimer la balise dans web.xml.

6. Exposition des données sensibles

Java dispose d'un grand nombre de bibliothèques de chiffrement, mais elles ne sont pas faciles à utiliser correctement. Vous devriez trouver une bibliothèque construite sur JCE qui fournit des méthodes de chiffrement utiles de manière pratique et sécurisée. Par exemple, Jasypt et ESAPI sont de telles bibliothèques. Vous devez utiliser des algorithmes puissants tels que AES pour le cryptage et SHA256 pour les hachages. Mais soyez prudent avec les hachages de mots de passe car ils peuvent être déchiffrés à l'aide d'une Rainbow Table, utilisez donc un algorithme adaptatif tel que bcrypt ou PBKDF2.

7. Manque de niveau fonctionnel Contrôle d'accès

JavaEE prend en charge le contrôle d'accès déclaratif et programmatique, mais de nombreuses applications choisissent toujours de créer leurs propres solutions. Le framework Spring dispose également de primitives de contrôle d'accès basées sur l'annotation . Le plus important est de s’assurer que chaque port exposé dispose de contrôles d’accès appropriés, y compris les services Web. Ne présumez pas que le client peut tout contrôler, car les attaquants auront un accès direct à vos points de terminaison.

8. Falsification de demande intersite (CSRF)

Chaque point de terminaison qui modifie le statut doit vérifier si la demande a été falsifiée. Les développeurs doivent insérer un jeton aléatoire dans la session de chaque utilisateur, puis le valider lorsque la demande arrive. Dans le cas contraire, un attaquant pourrait créer une page « d'attaque » via une balise IMG, SCRIPT, FRAME ou FORM malveillante liée à une application non protégée. Lorsqu'une victime consulte une telle page, le navigateur génère une « fausse » requête HTTP vers l'URL spécifiée dans la balise, incluant automatiquement les informations d'authentification de la victime.

9. Utilisez des composants présentant des vulnérabilités connues.

Les applications JavaEE modernes disposent de centaines de bibliothèques. Les outils de résolution de dépendances, tels que Maven, ont fait exploser ce nombre au cours des cinq dernières années. De nombreuses bibliothèques Java largement utilisées présentent des vulnérabilités connues qui peuvent complètement subvertir les applications Web. La solution est de mettre à jour la bibliothèque à temps. Ne vous contentez pas d’effectuer une seule analyse, car de nouvelles vulnérabilités sont publiées chaque jour.

10. Redirection et transfert non vérifiés

Chaque fois que votre application utilise des données non fiables, telles que request.getParameter() ou request.getCookie(), lors de l'appel de la réponse .sendRedirect(), un attaquant peut forcer le navigateur de la victime à accéder à un site Web non fiable dans le but d'installer un malware. forward présente un problème similaire, sauf que les attaquants peuvent se rediriger vers des fonctionnalités non autorisées, telles que les pages d'administration. Assurez-vous de revérifier les redirections et les destinations de transfert.

Vous devez continuer à prêter attention à ces problèmes. De nouvelles attaques et vulnérabilités sont constamment découvertes. Idéalement, vous pouvez intégrer des contrôles de sécurité dans vos processus de construction, de test et de déploiement existants.

Pour vérifier ces problèmes dans votre application, vous pouvez essayer le plugin gratuit Contrast for Eclipse. Il ne s’agit pas d’un simple outil d’analyse statique. Au lieu de cela, C4E exploite les API d'instrumentation Java pour surveiller tout ce qui concerne la sécurité dans l'application. C4E peut même effectuer une analyse complète du flux de données en temps réel, ce qui lui permet de retracer les données d'une requête via une application complexe. Par exemple, supposons que votre code prenne une valeur de paramètre, la décode en base64, la stocke dans une carte, place la carte dans un bean de données et stocke le bean dans une propriété de session, dans JSP Obtenez le bean valeur et insérez cette valeur dans la page Web en utilisant EL. Contrast for Eclipse peut suivre ces données et signaler les vulnérabilités XSS. Même si vous utilisez des frameworks et des bibliothèques complexes. Aucun autre outil ne peut égaler sa rapidité, sa précision et sa facilité d'utilisation.

Vous pouvez trouver Contrast for Eclipse sur le marché Eclipse. Ensuite, allez simplement dans l'onglet du serveur "Démarrer avec Contraste" - il fera le reste.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!