Quelle est la qualité de votre sécurité AEM ? – Déni de service

Les violations de données à grande échelle et les failles de sécurité critiques poussent plus que jamais les entreprises à se préoccuper de la sécurité. De nombreux développeurs connaissent le top 10 OWASP (https://owasp.org/www-project-top-ten/) et il existe déjà de nombreuses ressources sur l’atténuation générique de ces vulnérabilités. Au lieu de cela, dans cette série, je couvre les problèmes de sécurité et les atténuations spécifiques à AEM. Le sujet d’aujourd’hui est les vulnérabilités de déni de service.

Articles précédents dans la série :

Vulnérabilités de déni de service

Avez-vous déjà visité un nouveau site Web populaire pour constater qu’il s’est écrasé ou qu’il génère des erreurs ? Les visiteurs du site peuvent avoir involontairement causé un problème de déni de service en surchargeant le processeur ou la mémoire du serveur. Des acteurs malveillants peuvent provoquer intentionnellement le même problème en envoyant un grand nombre d’actions à un serveur.

Création de nœuds JCR déclenchée par l’utilisateur

La prévention des attaques DoS commence par les besoins de l’entreprise et est renforcée par la conception technique. Soyez très prudent lors de la conception de tout service, même authentifié, qui crée de nouveaux nœuds JCR dans le cadre de son comportement. Des utilisateurs malveillants peuvent exploiter ce comportement en inondant le JCR d’écritures de nœud. Pire encore, ils peuvent être en mesure de réaliser l’exécution de code à distance en téléchargeant de nouveaux fichiers de servlet JSP, des configurations OSGI, des téléchargements de bundle OSGI ou du XSS persistant. Par conséquent, les applications ne doivent jamais créer par programmation de nouveaux nœuds JCR sous le chemin /apps. Il s’agit d’une bonne pratique pour travailler ultérieurement dans AEM en tant que service cloud, où /apps est complètement immuable après le déploiement.

Si tout cela n’est pas pris en compte dès la phase de conception, vous pourriez avoir des refactorisations massives et des réécritures d’accès aux données plus tard. Considérez cet exemple. Vous avez une API publique dans votre application qui écrit dans le JCR chaque fois qu’il reçoit une demande. Un utilisateur malveillant pourrait rapidement atteindre ce point de terminaison des milliers de fois, créant une file d’attente d’écriture massive dans votre système. Alors, comment y remédier ? Supprimez-vous tous les accès publics pendant que vous essayez de résoudre la vulnérabilité ? Cela peut créer une expérience frustrante pour les utilisateurs légitimes. Examinons plutôt quelques mesures pratiques de prévention.

1. Vérifiez vos listes de contrôle d’accès pour les utilisateurs anonymes en écriture sur /content/usergenerated ou d’autres chemins. Envisagez de supprimer l’accès non authentifié pour générer du contenu.
2. Utilisez la limitation de débit par adresse IP, utilisateur et/ou clé API. Les limites de débit IP peuvent être quelque peu contournées par des utilisateurs malveillants utilisant un botnet ou un VPN. Tandis que les limites de taux d’utilisateur et de clé d’API n’empêchent pas l’accès aux API publiques ou les chargements de page. Il est donc idéal de mettre en œuvre une combinaison d’entre eux pour une couverture complète.
3. Envisagez de mettre en place une journalisation d’audit et des alertes de taux pour toute action authentifiée. Cela vous permettra d’identifier et de révoquer rapidement l’accès de tous les utilisateurs devenus malveillants.
4. Évitez les écritures JCR et le traitement important de la mémoire. Définissez des restrictions sur la quantité et le type de contenu qu’un utilisateur peut télécharger.
5. Utilisez des outils d’analyse des vulnérabilités comme SonarQube et Checkmarx. Ils détecteront généralement les vulnérabilités où l’utilisateur est en mesure d’entrer des paramètres de taille arbitraire ou non validés dans votre application.
6. Effectuez des tests de charge pour les nouveaux services – un nombre élevé d’appels ne devrait pas dégrader de manière significative le reste de l’application.

Services / travaux de transformation lourde

De nombreux cas d’utilisation existent pour les tâches à exécuter sur les environnements AEM. Celles-ci sont généralement lancées via une page de contenu d’administration, un point de terminaison d’API, un planificateur Sling, des tâches planifiées Sling ou une combinaison des quatre. Ceux-ci démarrent idéalement de manière asynchrone traitées via Sling Jobs, un flux de travail AEM ou Adobe IO plutôt que d’utiliser une puissance de traitement immédiate. Si vous utilisez des travaux Sling et des workflows AEM, vous pouvez limiter l’instance pour qu’elle n’utilise qu’un certain nombre de cœurs de processeur, ce qui réduit la charge potentielle totale sur le serveur. La configuration par défaut est définie sur la moitié du nombre total de cœurs disponibles, il peut donc être utile de réduire ce nombre dans les applications avec un traitement asynchrone constant. En outre, il est important de noter qu’Adobe recommande ne jamais augmenter la configuration au-dessus de la moitié le nombre total de cœurs.

Dans tous les cas, je recommande vivement que les traitements lourds soient protégés par authentification + ACL et ne soient accessibles que depuis les environnements auteurs. Les données peuvent ensuite circuler vers un magasin de données commun ou dans des environnements non cloud, être répliquées vers les éditeurs selon les besoins. Mais de nos jours, la stratégie de réplication n’est pas aussi courante, car les écritures d’E/S volumineuses provoquent une rotation du processeur et une dette ultérieure dans le compactage JCR.

Restreindre les écritures JCR ou qui a accès à un service est généralement une conversation qui doit commencer dès les premières solutions et exigences commerciales. N’attendez pas la mise en œuvre technique pour avoir cette discussion ! Les parties prenantes peuvent avoir besoin de budgétiser des fonds supplémentaires pour un magasin de données partagé, ou de repenser entièrement la façon de fournir des services publics, ce qui entraînera des retards ou des échecs de projets. Établissez des relations avec les principales parties prenantes et anti-attaques dès le début. N’oubliez pas qu’une mise en œuvre parfaite ne peut à elle seule réparer une conception défectueuse.

Pour plus d’informations sur la façon dont Perficient peut vous aider à atteindre vos objectifs de sécurité AEM et à mettre en œuvre vos expériences numériques de rêve, nous aimerions avoir de vos nouvelles.

Ils compléteront le contact pour commencer votre voyage.